· Charlie Holland · Architecture · 8 min read
Multi-Cloud Is a Lie You Tell the Board
Nobody is running workloads portably across clouds. They're running different things on different clouds and calling it a strategy. Multi-cloud is what happens when nobody's in charge.
I’ve just spent the best part of two years at an AI consultancy running workloads across AWS, Azure, and GCP. Different clients, different projects, different clouds. You know what that makes us? Multi-cloud. At least, that’s what the pitch deck says.
Here’s what it doesn’t say: at no point did we move a workload from one cloud to another. At no point did we design something to be portable across providers. At no point did anyone look at a running system on Azure and say “let’s shift that to GCP next quarter.” We ran different things on different clouds because different clients had different preferences. That’s not a strategy. That’s logistics.
And yet “multi-cloud strategy” is the phrase I keep hearing in boardrooms, vendor pitches, and analyst reports like it’s some kind of enlightened architectural position. It’s not. It’s a lie you tell the board to make an accident look deliberate.
The Gartner effect
Let’s be honest about where this hype comes from. Gartner has been banging the multi-cloud drum for years. Their 2020 cloud strategy report found that 81% of public cloud users were working with two or more providers. The implication was clear: multi-cloud is the future, get on board or get left behind.
What they didn’t emphasise quite so loudly was why those organisations ended up multi-cloud. It wasn’t because a chief architect sat down and designed a beautiful multi-cloud strategy on a whiteboard. It was because:
Different teams made different decisions. The data science team picked GCP because of BigQuery and TensorFlow. The enterprise apps team picked Azure because they were already neck-deep in Active Directory and Office 365. The startup acquisition the company bought last year was all-in on AWS. Nobody coordinated. Nobody needed to — until the CTO asked for a “unified cloud strategy” and everyone scrambled to pretend this was intentional.
Acquisitions brought their own baggage. Company A is on AWS. Company A buys Company B, which is on Azure. Congratulations, you’re multi-cloud. This isn’t a strategy. This is the M&A team creating work for the infrastructure team.
A vendor convinced someone senior. A slick demo from a cloud provider’s sales team convinced a VP that their platform was the future. A proof of concept was built. It went live. Now you’ve got workloads on two clouds, neither of which talks to the other properly. The VP moved on. The workload remained.
None of these are strategies. They’re outcomes. Multi-cloud, in practice, is what happens when nobody’s in charge.
The “avoid vendor lock-in” fantasy
The most common justification I hear for multi-cloud is avoiding vendor lock-in. On the surface, it sounds reasonable. If you spread your workloads across providers, no single vendor can hold you hostage. If AWS jacks up their prices, you can move to Azure. If Google decides to kill another product (and they will), you’re not exposed.
In theory, this is compelling. In practice, it’s rubbish.
Here’s why: the moment you use a managed service, you’re locked in. And you should use managed services — that’s the entire point of cloud. Nobody moves to AWS to run EC2 instances and pretend they’re in a colo. You move to AWS for RDS, Lambda, SQS, DynamoDB, Kinesis, S3 event triggers, IAM policies that integrate with everything, CloudWatch metrics that feed into CloudWatch alarms that trigger SNS topics that invoke Lambda functions. That’s the value. That’s also the lock-in.
The same applies to Azure: App Service, Azure Functions, Cosmos DB, Azure AD integration, Logic Apps, Event Grid. And GCP: Cloud Run, BigQuery, Pub/Sub, Firestore, Vertex AI. These services are not interchangeable. They have different APIs, different operational characteristics, different failure modes, different billing models, and different levels of maturity.
To actually avoid lock-in, you’d need to abstract away all of these platform-specific services behind some kind of portable layer. You’d write everything to run on Kubernetes (because that’s the one thing all three clouds share). You’d avoid managed databases in favour of self-hosted PostgreSQL. You’d skip serverless functions entirely. You’d build your own message queues.
In other words, to avoid vendor lock-in, you’d throw away all the benefits of using a cloud provider in the first place. You’d be paying cloud prices for on-premises complexity. I’ve seen this. It’s miserable for everyone involved.
The organisations I’ve worked with that actually tried to build “cloud-portable” applications ended up with a lowest-common-denominator architecture that was slower to build, harder to operate, and more expensive to run than just picking one cloud and going deep. They traded theoretical flexibility for concrete pain.
Triple the complexity, triple the skills gap
Let’s talk about what multi-cloud actually costs you in practice, beyond the obvious infrastructure bills.
Skills. Each cloud provider is its own universe. AWS alone has over 200 services. The networking model is different. The identity model is different. The deployment tooling is different. The monitoring is different. The way you debug a failing deployment is different. An engineer who’s deeply competent on AWS is not automatically competent on Azure or GCP. The concepts overlap, but the details — the details that matter at 3am when production is down — are completely different.
If you’re genuinely running workloads across three clouds, you need engineers who are deeply competent on three clouds. Or, more realistically, you need three teams. Which means three times the hiring challenge in a market that’s already short on experienced cloud engineers.
I’ve watched this play out firsthand. At the AI consultancy, we had people who were brilliant on GCP and passable on AWS. We had people who knew Azure inside out but had never touched GCP’s IAM model. Every cross-cloud project involved a learning curve, and that learning curve had a cost: slower delivery, more mistakes, more incidents.
Operations. Monitoring, alerting, incident response, cost management, security posture, compliance auditing — all of these need to work across providers. The tooling exists (Datadog, Grafana Cloud, Terraform, Pulumi), but it adds layers of abstraction, and every layer of abstraction is a place where things go wrong and where understanding gets harder.
I’ve sat in incident calls where the root cause was a misconfigured network peering between AWS and Azure, and nobody in the room fully understood both sides of the connection. That’s not a tooling problem. That’s a complexity problem. Multi-cloud creates failure modes that don’t exist in single-cloud environments.
Cost. Egress charges between clouds are eye-watering. AWS charges you to send data out. Azure charges you to send data out. If your “multi-cloud strategy” involves services on different clouds talking to each other, you’re paying a tax on every API call, every data sync, every event. The cloud providers love multi-cloud. It’s brilliant for their bottom line.
What actually works
Here’s what I’ve seen work, across nearly 25 years of doing this:
Pick one cloud. Go deep. Choose the cloud provider that best fits your primary use case, your team’s existing skills, and your commercial relationship. Use their managed services aggressively. Build expertise. Invest in the ecosystem. You’ll deliver faster, operate more reliably, and spend less.
Accept that you might end up on multiple clouds. Not as a strategy — as a reality. The acquisition will happen. The data science team will want GCP for BigQuery. The legacy SAP system will stay on Azure. Fine. Manage those as separate estates with clear ownership, not as one unified multi-cloud platform.
Don’t confuse multi-cloud with hybrid cloud. Running some workloads on-premises and some in the cloud is a legitimate transitional architecture. Running workloads across multiple cloud providers because someone said “avoid lock-in” at a conference is not.
If someone in your organisation is pitching a multi-cloud strategy, ask them three questions: What workload are we going to move between clouds, and when? Who has the skills to operate across all the clouds we’re proposing? What’s the actual cost of running this way versus going deep on one provider? If they can’t give you concrete answers, what they’re pitching isn’t a strategy. It’s a PowerPoint slide.
The uncomfortable truth
Multi-cloud is a narrative that serves vendors, analysts, and consultancies — not engineering teams. Vendors love it because it means you’re buying from all of them. Analysts love it because it generates reports and advisory fees. Consultancies love it because it creates complexity, and complexity creates billable hours.
The people who don’t love it are the engineers who have to make it work. The ones who maintain the cross-cloud networking. The ones who troubleshoot IAM issues across three different identity systems. The ones who get paged when the data replication between AWS and Azure falls over at 2am.
I’m not saying multi-cloud never makes sense. There are genuine cases — regulatory requirements that mandate data residency, best-of-breed scenarios where one provider is genuinely, measurably better at a specific workload, or M&A situations where you inherit infrastructure and need to operate it while you plan a migration.
But those are specific, justified, bounded decisions. They’re not a strategy. And they’re definitely not what most organisations mean when they put “multi-cloud” on a slide.
What most organisations mean is: “We ended up on multiple clouds by accident, and we’d like that to sound intentional.”
It doesn’t. Not to anyone who’s been in the room.
