Multi-cloud: an honest look

"We should be multi-cloud" is one of those statements that sounds smart in a strategy meeting. Avoid lock-in! Better negotiating power! Resilience if a provider goes down! Who could argue with that?

In practice, multi-cloud is often more expensive, more complex and less resilient than people expect. Sometimes it's exactly the right choice. Often it isn't. Here's how I think about it.

What people mean by "multi-cloud"

The term covers very different setups:

1. Different workloads on different clouds: the data team uses Google Cloud for BigQuery, the main app runs on AWS, Microsoft 365 and some Azure services for IT. This is the most common, and usually happens naturally.
2. The same application deployable to multiple clouds: portable, but only running on one at a time.
3. The same application running actively on multiple clouds at once: true multi-cloud active-active. Rare, hard and expensive.

Most companies are in the first category, whether they planned it or not. The debate is usually about the second and third.

Good reasons

• Regulation and sovereignty: some customers or countries require specific providers, or a European alternative.
• Mergers and acquisitions: you bought a company that runs on another cloud. Migrating isn't always worth it.
• Best-of-breed services: a particular provider is clearly better for one need (AI hardware, analytics, a specific managed service).
• Customer requirements: if you sell software that runs in customers' accounts, you need to support the clouds they use.
• Commercial leverage: credible ability to move gives you a better position in price negotiations. But this only works if moving is actually realistic.

Weaker reasons

• "Avoiding lock-in" in general. Every choice locks you into something: a database, a language, Kubernetes, Terraform. The question isn't whether you're locked in, but whether the cost of leaving is acceptable.
• "Resilience against a provider outage." Large provider-wide outages do happen, but they're rare. Well-designed multi-region on one provider gives most of the resilience at a fraction of the complexity.

Multi-cloud doesn't remove lock-in. It replaces dependency on one provider with dependency on your own team's ability to run several.

The hidden costs

• Lowest common denominator. To stay portable, you avoid each provider's best managed services. You run your own databases, queues and tooling instead.
• Data transfer. Moving data between clouds is expensive (egress charges) and slow.
• Skills. Your team needs deep knowledge of several providers' networking, IAM, security and quirks. That's much harder than mastering one.
• Tooling. Security, monitoring, cost management and compliance must work everywhere.
• Lost discounts. Splitting spend reduces the volume discounts and commitments you can negotiate with each provider.
• More things to secure. Every additional cloud is another set of accounts, identities and configurations to get right.

What helps portability

If you do need portability, a few tools make it more realistic:

• Kubernetes: a consistent runtime across clouds and on-premises. The managed services differ in details, but workloads move fairly easily.
• Terraform or OpenTofu: one tool for infrastructure across providers. The code is still provider-specific, but the workflow and skills transfer.
• Crossplane: a Kubernetes-based control plane that can offer the same internal APIs backed by different clouds.
• OpenTelemetry: vendor-neutral observability.
• Open-source data stores (PostgreSQL, Kafka, Redis/Valkey) available as managed services on every major cloud.
• Standard identity (OIDC, SAML) and a cloud-neutral secret manager.

How I'd decide

Ask these questions:

1. Is there a concrete business, legal or customer requirement for a second cloud? If yes, plan for it properly.
2. What would leaving our main provider actually cost in time and money? Is that risk acceptable? Write down an exit plan, even if you never use it. Regulators, especially in financial services, increasingly expect this.
3. Can we get the resilience we need with multiple regions on one provider?
4. Do we have the people to run several clouds well?

For most companies, my recommendation is: go deep on one primary cloud, use other providers deliberately for specific needs, keep your architecture reasonably portable with Kubernetes, Terraform and open standards, and maintain a realistic exit plan.

My take: multi-cloud is a tool, not a strategy. Use it when you have a reason, not because it sounds safe.

— Desly