Between around 2015 and 2019 I remember having the “cloud agnostic” chat with my bosses and 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”.
It’s understandable that leaders would 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 — prices & 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 — in features and in their interface — that anything but the simplest codebase simply 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 very likely we’re looking at a complete re-work of the code which interacts with our cloud layer.
The rest of this article is FREE on Substack
Your support is greatly appreciated.
