
Ask HN: How to avoid cloud lock-in? - IceandFire
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?
======
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.

------
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...](https://blog.fauna.com/survive-cloud-vendor-crashes-with-netlify-
and-faunadb)

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.

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

