5 ms·

Infrastructure as code. Terraform using AMIs plus chef recipes that work in the cloud and bare metal. Dont use AWS specific services. This would allow you to

• xchaotic 8y ago
  I think you are downplaying minimal
  • Twirrim 8y ago
    I don't think OP was intending "minimal" to mean it would be easy to get to the stage where it's possible, just that once you've got all your infrastructure-as-code stuff set up correctly, you ought to be able to just be pressing buttons / running scripts and have your infrastructure up and running in another cloud provider. Even when working in small companies with small infrastructure, I've kept recreation of infrastructure as one of my high priorities (one reason it really bugged me in one job to have to depend on Oracle Databases that I couldn't automate to the same degree.) In my mind, it's not different from the importance of having, and testing restoration of, backups. If your infrastructure gets compromised somehow, or you find yourself up the creek with your provider, you've got to be able to rebuild everything from scratch.
    • user5994461 8y ago
      The infrastructure has always been the easy part, as long as the company is willing to pay for multiple datacenters. Then you realize a lot of software and databases can only run from a single instance, zero support for multi regions, and you're not gonna to rewrite everything and resiliency just can't happen.
  • geggam 8y ago
    No, with over 20 years experience and having done exactly this for several different companies and startups I pretty much have this process down.
• cloakandswagger 8y ago
  Totally impractical for any small business and of questionable usefulness for large ones. You'd be giving up the largest benefit of platforms like AWS--ready to use services for common tasks--to avoid the infinitesimally small chance of AWS having some doomsday global outage. To answer the original question: It looks like this issue was just a UI bug that affected the console, the service itself wasn't impacted. Events that do impact the service will be contained to a region, meaning you can mitigate it with proper redundancy across regions, no zany multi-cloud solution required.
  • geggam 8y ago
    Evidently you dont know how to do this well
• scarface74 8y ago
  That’s not how Terraform works. Each provisioner has separate syntax depending on the cloud provider. The template for AWS wouldn’t work on GCP or Azure.
  • geggam 8y ago
    Correct. However written properly you get 90% of the way there. Disaster recovery by switching to another provider is simple when minimal centos/rhel images are used.
    • edoceo 8y ago
      Then struggle like hell for the other 90%
    • scarejunba 8y ago
      Assume I’m not fully informed here. What does “written properly” mean? Sure I can move over route53 to cloud DNS easily but Firehose to PubSub? Lambda to Cloud Functions? DynamoDB to BigTable and moving the data? The syntax for provisioning these doesn’t work that well for some find and replace to work. Are you using a templater to generate cloud-specific HCL from a template or something? Sounds like a pretty big problem to solve to me and not just something where you can win via discipline.
      • geggam 8y ago
        Quit using vendor lock in resources then asking why its hard to leave that vendor.
        • scarface74 8y ago
          You’re always “locked in” to your infrastructure. People have this brilliant strategy of thinking they have this brilliant strategy of avoiding “lock in” and again they get the worse of both worlds. They end up spending more to avoid lock-in and they aren’t taking advantage of what thier provider has to offer. At the end of the day, changing your underlying infrastructure is so risky and usually not worth the cost benefit analysis, it’s rarely done.
• scarface74 8y ago
  And this is the reason that people end up spending so much more in the cloud - treating AWS like a glorified colo.