Multi-Cloud is BS

It’s not that there’s no such thing as companies that are “doing” multi-cloud, using some combination of AWS/Azure/GCP/OCI/… -- of course they are, but by far it’s departments/divisions/subsidiaries/acquisitions that have chosen one cloud provider and organically end up under that one (usually very large) company’s multi-cloud umbrella, rather than anyone (with any sane mind) trying to write applications multi-cloud.  I think I’ve seen a handful of good examples and they are attempting something so very specific and cunning you could put a tail on them and ‘um a fox.

Why isn’t multi-cloud a “thing”? Let’s shoot down some myths (sorry, this one is quite a bit longer).

Increased reliability — maybe back in the days when a AWS/Azure/GCP region was a single datacenter that might have been true, but today most regions have many datacenters, each with many fault-separated availability zones. Yes, datacenters can have outages, and very rarely are there regional outages, but there’s not been (never say never) an entire cloud provider outage to say that one needs “multi-cloud” for reliability. You are much more likely to get BGP/routing/TLS failures between cloud providers that negate the even tiny risk reduction of being multi-cloud -- just make use of multi-region/multi-datacenter/multi-availability-zone in a single cloud.

Lock-in — all cloud providers support Docker, Kubernetes, and whatever VM image you want to throw at them if you don’t want to be containerized. So, the argument that you can’t pick up and move applications between providers to avoid lock-in is BS. Maybe if you write an application or your infrastructure-as-code scripts for one cloud provider but want to move to another, there’s the lock-in danger of needing to rewrite, but there’s all kinds of abstraction libraries out there. However, even after saying that, lock-in is very real but it goes by the name of “data gravity”.  Your “lock-in” is wherever your data is as getting data out of a cloud provider, or accessing it outside of that provider, is often so prohibitively expensive (although props to Cloudflare’s R2) it ain't going anywhere, so you are already locked-in!

Cost — the argument is that being multi-cloud allows companies to go where the cheapest price is, or use it to negotiate with each of their cloud providers. Have you even tried understanding, at scale, what the projected costs will be in a single cloud provider, let alone multiple? It’s such a dark art that people dedicate their careers to it and form companies to help others, making “good bank” in the process. Additionally, if you did want to save on cost you actually get better negotiating and pricing by using more and not less. Back in the early days of the cloud AWS and Azure got into a price dropping war which ceased after a few rounds because both realized it was lose-lose, so cross-cloud costs aren’t going to be that different (macro, not micro - some provider’s individual services are obscenely expensive for what they are compared to others), and no-one actually pays list price.

Security — some will say monocultures are bad and enable internet-scale failures. Ok, this was more to do with software (specifically operating systems, way back in 2014) than cloud providers, but what is a cloud other than a lot of software -- surely using multiple cloud providers means a vulnerability in one place doesn’t put everything at risk. I counter with the ask to try and understand identity and access management - IAM - in a multi-cloud way. Not the general principle of it, but AWS’s flavor, GCP’s flavor, and Azure’s flavor of AAD. Their policies, rules, and how they work are all *entirely different*, each one practically a turing-complete language of their own.  They aren’t compatible at all, so one ends up falling back to some lowest common denominator, generally OAuth2. You are much more likely to introduce a security vulnerability being multi-cloud than reducing the impact of one.

Agile — Some cloud providers have “better” software/services than others, and people (mostly junior software developers -- those with some “gray hairs” know better) want to use the “new and shiny”, “best of breed”, or “something I already know”, with the argument that they will be quicker and full of features. Thing is, for each one of these choices there’s DevOps/SRE/compliance overhead. Those few weeks saved because the combination of GKE and CosmosDB is “so cool” has meant that SOC2 has just taken twice as long.

There’s plenty more, but I think that will do -- multi-cloud is BS.