HN Explorer

Ask HN: How to avoid cloud lock-in?

3 points by IceandFire ↗ HN
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.

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?

5 comments

[ 4.9 ms ] story [ 25.6 ms ] thread
enz
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.)

Typically, I organize my layers of code as such:

Business Logic, Core < Handlers < Front (HTTP routing, sessions/token stuff, ...).

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.

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.

Of course, this is pure theory. In practice, some cases may require you to break this one-way chain for performance or scalability reasons...

IceandFire
> Business Logic, Core < Handlers < Front (HTTP routing, sessions/token stuff, ...). I use the similar logic. But you have presented it perfectly. In one of the project we had to use NoSQL database in crunch time situation so had to go with Dynamo.
QuinnyPig
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.

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.

jchanimal
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.

I wrote a blog post about how easy it is to get multi-cloud robustness for single page apps here: https://blog.fauna.com/survive-cloud-vendor-crashes-with-net...

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.

IceandFire
True, databases have the most gravity and tedious to migrate when switching to different cloud. Thanks for your suggestions. I will definitely give Netlify and Fauna a try.