AWS is really great, but I don’t want to be locked into a single cloud. I am heavily using the AWS compute resources i.e. EC2 and Lambda.<p>What are you doing to keep your business “cloud-neutral” at the technical level? Are you writing cloud abstraction layers in your code? Writing Terraform for various clouds? Any good ideas, assuming a containerized application? What about portability of your serverless code?
As long as the business logic remains agnostic, the most essential part is okay (for a lot of projects, at least). You talk only about EC2 and Lambda, so I assume you use a "standard" database and you are not using a proprietary one such as Dynamo. (So you are able to change from AWS RDS PostgreSQL to Heroku PostgreSQL for example.)<p>Typically, I organize my layers of code as such:<p>Business Logic, Core < Handlers < Front (HTTP routing, sessions/token stuff, ...).<p>The dependency can only go from the right to the left, so the BL code never gets touched when I decide to add/replace a handler or a frontend.<p>When you are on AWS Lambda, you code the Front: a glue between your Handlers and the AWS Lambda platform. So the rest of the project can be updated as-is in an ideal case. When you change your cloud provider, you have to rewrite the Front part again. But the layers underneath will be unchanged.<p>Of course, this is pure theory. In practice, some cases may require you to break this one-way chain for performance or scalability reasons...
I wrote a blog post about a simple multi-cloud stack. There are a bunch of vendors who are doing the work in their layer of the stack, so you can use a multi-cloud web host, and a multi-cloud database, and you'll be most of the way there.<p>I wrote a blog post about how easy it is to get multi-cloud robustness for single page apps here: <a href="https://blog.fauna.com/survive-cloud-vendor-crashes-with-netlify-and-faunadb" rel="nofollow">https://blog.fauna.com/survive-cloud-vendor-crashes-with-net...</a><p>Of course it becomes more complex as the app becomes more complex. But more and more of the AWS/GCP/Azure services have multi-cloud equivalents, so this architecture only gets easier to implement.
If you avoid all lock-in, you pay for the optionality with feature velocity. It’s often far cheaper to go all-in, and then migrate down the road if it becomes strategically viable.<p>To that end, I don’t use things with no equivalent anywhere else (Google’s Cloud Spanner), but I also don’t avoid things like RDS, load balancers, API Gateway, etc.