Multi-cloud gets talked about constantly and misunderstood almost as much. The real use cases are narrower than vendors claim, but the operational complexity is broader. Let me separate the hype from what actually makes sense.
The portability myth
The pitch sounds clean: spread across multiple clouds to avoid vendor lock-in. If one provider raises prices or goes down, you can switch. In practice, this strategy requires you to avoid all the specialized services that make cloud providers valuable. You're stuck with the lowest common denominator: basic VMs, object storage, and generic Kubernetes. You give up Azure Cosmos DB, AWS Aurora, BigQuery. These managed services give you real productivity gains and operational advantages. The cost of achieving true portability exceeds the lock-in risk it supposedly prevents. It's a deal you don't actually want.
Best-of-breed works differently
The legitimate multi-cloud argument is simpler: use the best tool from each provider. Azure for .NET workloads, AWS SageMaker for machine learning, BigQuery for data analytics. This works but requires your team to maintain expertise across three platforms. You need to understand three separate IAM models, three billing systems, three security governance models. The teams that pull off best-of-breed multi-cloud successfully have dedicated cloud engineers for each platform. It's not a cost-saving strategy. It's a strategy for teams with the depth to handle it.
Kubernetes doesn't solve portability
Kubernetes does give you application portability across clouds, but with a major caveat. An app running on AKS can run on EKS with configuration changes and no code changes. That matters for compute workloads. But this doesn't extend to managed services. Your databases, message queues, and object storage stay provider-specific. Kubernetes portability is real and useful. It's also narrower than most people think.
When you actually need multi-cloud
Financial regulation in some jurisdictions requires you to avoid single-cloud dependency for critical systems. That's a real driver. Disaster recovery across geographic boundaries makes sense: Azure as your primary, AWS as your DR target with data replication running constantly. Acquisition integration is real too. You buy a company using GCP, you're using Azure. Now you have to make them work together. These are legitimate reasons to go multi-cloud. "Vendor lock-in is bad in theory" is not one of them.