Every enterprise technology strategy deck I’ve reviewed in the last five years includes some version of “multi-cloud.” It’s become dogma: use multiple cloud providers to avoid lock-in, increase resilience, and leverage best-of-breed services.
The problem? For most organizations, multi-cloud as currently practiced delivers the opposite of what it promises.
The Promise vs. Reality
Promise: Avoid vendor lock-in. Reality: You’re now locked into three vendors instead of one, with three different IAM models, three different networking stacks, three different monitoring tools, and a team that’s shallow on all of them instead of deep on one.
Promise: Increase resilience. Reality: Cross-cloud failover is extraordinarily hard to implement correctly. Most organizations that claim multi-cloud resilience actually have workloads that run in one cloud and would take days or weeks to move.
Promise: Best-of-breed services. Reality: True, but the integration overhead of stitching together services across cloud boundaries often exceeds the benefit of using the marginally better service.
When Multi-Cloud Actually Makes Sense
Multi-cloud isn’t always wrong. It makes sense when:
- You have genuine regulatory requirements, such as healthcare data in one region, financial data in another, with different compliance frameworks that align with different cloud capabilities.
- You’ve acquired companies that run on different clouds, and migration would be more disruptive than federation.
- Specific workloads have clear best-fit providers (ML training on GCP’s TPUs, enterprise integration on Azure, infrastructure automation on AWS), and you have the team depth to support all of them.
The Architecture That Works
When multi-cloud is the right answer, the architecture that succeeds has these characteristics:
Abstract at the Right Layer
Don’t try to make everything cloud-agnostic. That path leads to lowest-common-denominator architecture that leverages none of the clouds well. Instead, abstract at the application and data layer using containers, service mesh, and cloud-agnostic data formats. Let infrastructure be cloud-specific.
Invest in Platform Engineering
Multi-cloud without a strong platform engineering team is a recipe for chaos. You need a team that owns the developer experience across clouds, provides golden paths, and ensures security and compliance are consistent regardless of where workloads run.
Accept Asymmetry
Not every cloud needs to run every workload. Designate a primary cloud for most workloads and use secondary clouds for specific, well-justified purposes. This asymmetric approach is cheaper, simpler, and more maintainable than trying to distribute everything evenly.
The Question to Ask
Before adopting multi-cloud, ask this: “What specific problem does this solve that a well-architected single-cloud strategy doesn’t?”
If the answer is “vendor lock-in,” dig deeper. Lock-in is real, but the cost of multi-cloud complexity is also real. The winning strategy is the one that honestly weighs both.