The Dead Dream of Cloud Portability

Why can't we just switch clouds vendors?

Nov 24, 2023

Between approximately 2015 and 2019 I remember often having the “cloud agnostic” chat with various software leaders, summed up as:

“What is the cost / benefit tradeoff for building a truly cloud-portable product?”

In other words:

“If I spend x developer cycles to build and deploy y product on AWS, how many additional cycles would it take now or later to migrate to Azure / GCP / Oracle / OpenStack etc at any time in the future?”

It’s a complicated question which requires some unpacking and clarification.

“it depends”.

Leaders want to ensure they don’t put all their proverbial eggs in one basket. We all know how the vendor-lock-in game works… (but we still fall for it). Nevertheless, It’s prudent to understand what our upfront and ongoing costs would be to mitigate any surprises.

The naive yet probably accurate answer is x*2 (where x is the component of work related to cloud deployment and configuration, outside of software architecture and development)

This is not the answer anyone wants to hear. It means that you’d double the engineering effort to work something which may never be used. (This may make sense if the goal is to have total cloud fail-over, or a split-cloud solution) Otherwise it’s hard to justify essentially wasted spend.

Working For You By Working Against You

Free market capitalism gives us a plethora of clouds to choose from, each competing for customers (you) who make choices based on primarily two things; cost & features. This tends to hold true, assuming mostly everything else like reliability, distribution and security remain equivalent.

Prices tend to stabilize over time when customers have the freedom to jump between vendors with equivalent features.

Until then the feature gold-rush engaged in by cloud vendors means that customers get more and more locked-in to the features, bells and whistles offered by AWS and (not yet) offered by Azure or GCP (Not to mention Ali-Baba, Tencent and other emergent international players).

Lock er In, Jerry

The lock-in doesn’t stop there though. I talked about Terraform being a “cloud agnostic” solution in a previous story. The platform, language, design and concepts remain the same but the provider API’s are so different that anything but the simplest codebase just won’t easily port from A to B.

EVEN IF we have feature-parity across our vendors AND we use the best-in-class language for deployment, It’s likely we’re looking at a complete re-work of the code which interacts with our cloud layer.

Let’s not forget testing the functionality, scalability, availability and performance in the other cloud.

Abstract It!

This sounds a bit like the ORM middleware layer trying to solve the database vendor lock-in issue. Well there is a stalemate situation that front.

It’s very difficult to reason abstractly about underlying systems seeking to differentiate themselves from each other, the race for new fancy features is always on.

Some fundamental resources, like load-balancers, volumes and compute are mature & relatively unchanging. These can be grouped into common interfaces which only diverge in behaviour when they call their parent API, which is transparent to the caller.

Enter k8s

One of the fabled promises of Kubernetes was a neat, standard and open source cloud-abstraction layer for any kind of deployment.

This is an exciting prospect. We could point our deployments at API-A or API-B and we’d get the same result! (in theory)

The reality:

k8s is a container platform, first and foremost It’s designed to work with containers. If you’ve got a database or a tightly-coupled messaging queue, AWS might do a better job managing that.
Compatible abstractions always lead to a reduced feature set. If you want a feature which is not common you instantly break cross-vendor compatibility.
IP’s & DNS is sticky. Most orgs don’t have the time or need to manage their own DNS and BGP Anycast their IP’s across clouds.

So what now?

The industry has settled into an ease and trust with cloud vendors. They aren’t going anywhere and they’re too big to be allowed to fail. Vendors are obsessively customer focused and work hard to ensure satisfaction.

So long as costs don’t suddenly bloat, there’s no longer a need for cross-vendor redundancy and the time for a “quick exit” bargaining-chip seems to have passed.

So is the dream of the cloud-vendor-hop is a thing of the past?

The ability to easily jump between cloud vendors could be an industry game-changer, and the next generation of infra tooling could make this a reality.

Check out this article: