Multi-cloud (the concept of running the same workload across multiple cloud providers in a completely agnostic way) is absolutely something you should focus on, at least according to two groups:
-
Declining vendors who realize that if you don't go multi-cloud, they will have nothing left to sell you. AWS is not going to build a multi-cloud dashboard, so some on-premise tooling vendor that hasn't been able to compete in the cloud will definitely build one and try to sell it to you.
-
"Niche players" who realize that if you commit to just one cloud provider, it definitely won't be them.
Since I don't belong to either of those two groups, I'll offer some recommendations on best practices (based on my experience) that should be considered the default guideline. Maybe some recommendations don't apply to your situation and you'll surely be right, with reasons like:
The customer demands it!
People will die if this service goes down!
The company will go bankrupt if we're down for 5 minutes!
These are the reasons why multi-cloud is the worst practice and should be avoided by default.
What is NOT multi-cloud?
Every company is multi-cloud if you try hard enough — we're all platypuses — by using different providers for different use cases:
-
Microsoft 365 for collaboration
-
AWS for infrastructure
-
GitHub for our code repositories
-
Azure DevOps for pipelines
-
Salesforce for CRM
This is in no way what I'm talking about. That's simply good business sense. If someone suggests going all-in on AWS and implies that this means using Amazon Chime, WorkDocs, CodeCommit, CodePipeline, etc., that person is actively trying to sabotage your company's growth — you should fire them immediately.
What is multi-cloud?
What I'm referring to is the idea of building workloads that can run seamlessly on any cloud provider or your own datacenter alike. (Note that there are also on-premise datacenters connected to a public cloud provider to balance workloads — this is called "hybrid"). The vision is quite good, compelling, and something I would very much enjoy seeing.
However, it's about as practical as telling your developers to "just write bug-free code," or actually trying to find the spherical cow that physics exercises say should exist. It's much harder than it looks.
Yes, every cloud provider can run containers. This is the promise that Kubernetes (an open source project from Google named after the Greek god of spending money on cloud services) has brought to life.
The lowest common denominator
The problem is that a cloud provider gets reduced to "a bunch of disks, some networking, and a pile of servers to run containers." Those basic primitives exist everywhere: AWS, Azure, GCP, Oracle Cloud, IBM "Cloud", and on premise.
If you treat all of those environments as if they were the same thing, it means you can't and shouldn't use any additional service that is of any higher order than these primitives.
Load balancers work differently on every cloud platform, so being multi-cloud means you have to maintain your own with nginx, HAProxy, Traefik, etc. The same story applies to databases, monitoring systems, security permission models, anything event-driven, service mesh, NoSQL — and what are we going to do about regulatory compliance?
Yes, I know what you're about to say: the industry as a whole has been doing this for a long time; we haven't magically forgotten how to run all of these things ourselves.
My point is that while you're spending time configuring HAProxy to route requests to the right containers when the right conditions are met, one of your competitors has set up an Application Load Balancer to do this with three lines of YAML and is now moving forward building the thing that actually matters for their business goals. We'll completely ignore the fact that the managed version of the load balancer has far better availability, durability, reliability, and resilience than the thing you'll build with your architects and developers.
You are not "getting the best of both worlds." You are improving your datacenter at the expense of your cloud environment.
What about vendor lock-in?
Another common justification for multi-cloud is avoiding lock-in to a single provider.
I have bad news for you: you're already locked in.
You have lock-in whether it's in technology selections (databases are a killer here), or "soft" lock-in in things that don't adapt well, such as identity and access management, which is not consistent from provider to provider.
"Soft" lock-in
Of these, "soft" lock-in is the only true killer and, coincidentally, the one nobody outside of Engineering thinks about.
In other words, what happens when you announce a global migration from AWS to Google Cloud? Well, for starters, at least a third of your engineering staff will stop building their professional career on their existing skills in a platform that other companies are using more deeply.
It is hard to learn how a new provider will fail. It is much easier to go deeper into the existing ecosystem you're already familiar with. It's also much more valuable from the employee's perspective. Companies don't want to hire generalists with shallow knowledge across multiple providers; they lean toward specialists who are good at one particular platform. This may not seem intuitively true if you look at job postings; but it becomes much more understandable if you filter for the jobs that pay high salaries.
As a direct result of this, virtually all the growth that cloud providers demonstrate in their quarterly earnings does not come from convincing customers of other cloud providers to switch; it's a combination of people migrating from datacenters, plus net-new workloads.
It is extremely difficult to migrate from a datacenter to a cloud provider when you (at least in theory) already know all the knobs and tricks of your environment. Going from cloud to cloud is at least ten times more complicated, and neither companies nor employees are particularly enthusiastic about wanting to do it.
Negotiating power
"Ah!" you may wisely interrupt. "If I have two cloud providers, I can use one to beat the other into offering better terms and discounts!"
Every cloud provider negotiates percentage-based discounts based on your share of spend. Cutting your spend in half reduces your negotiating base.
But let's assume for a second that you're a company with incredibly portable workloads (they do exist!) that can in fact move workloads to other providers seamlessly.
Every time I've seen this happen in my experience, the discount achieved with that threat is smaller than the discount the customer would get simply by committing to higher spend levels.
To give an example: 3 million a year across three providers yields remarkably different results even before you consider the costly management and operational overhead of making those systems work well together — and now you're negotiating discounts based on $3 million a year... and you're doing it three times.
Also, regardless of which provider you choose, once a cloud provider runs your production infrastructure, they stop being your vendor and become your partner, whether you like it or not. Adversarial relationships are not as productive as collaborative ones.
Multi-cloud does not protect you from price changes
In practice, the unwritten rule of the cloud is that things get less expensive over time. We've seen every price change from every provider support this rule, with the sole exception of Google Cloud, which completely betrayed its customers — three times.
The first time was its 14x increase for access to the Google Maps API. The second was when they started charging for previously free GKE cluster management. The third time was when it decided to raise prices for load balancers, storage, etc.
Therefore, I can declare that GCP is a special case for which you really do want to have an exit plan in case you need it.
Multi-cloud does not exist in reality
In practice, every "we're multi-cloud" story I've seen actually means "we're more than 80% on our primary provider, then we have a handful of workloads on others."
Any choice you make constrains your options. Multi-cloud is the embodiment of the ideal that "indecision is the key to flexibility." The problem is that you'll spend so much time avoiding commitment to a provider that you'll spend an ever-increasing amount of operational work keeping your environment functional at a relatively basic level, and you'll struggle to truly innovate as a company.
As Ben Kehoe puts it, multi-cloud is like cow tipping: we know it doesn't exist because there are no cow tipping videos on YouTube. In this case, there are no articles or conference talks from companies talking about how their successful multi-cloud strategies are paying off.
My suggestion
If you're anything like me, you're going to read this, believe you're a special case to which none of the warnings above apply, and try multi-cloud anyway.
Go for it.
I have just one suggestion: before going all-in on a second cloud provider, first spin up an active-active environment across two regions of your current provider, where you have full compatibility of all services and APIs between those regions — it should be a piece of cake. ;)