14.5.2: Multi-Cloud and Federated Cloud Strategies

Gone are the days when an enterprise would place all bets on a single cloud provider. Today, multi-cloud strategies – using two or more public clouds, or hybrid clouds mixing on-prem and public – are extremely common. In 2024, Gartner reported over 92% of large enterprises operate in a multi-cloud environment. Similarly, a Virtana survey found 80% of organizations use multiple public or private clouds. The motivations include avoiding vendor lock-in, optimizing costs (playing providers against each other or using each for what they’re best at), and resilience (able to failover if one cloud has an outage).

However, multi-cloud brings complexity – each platform has its own services, APIs, and nuances. The emerging trend to manage this is using abstraction and orchestration layers: - Tools like Terraform and Crossplane allow defining infrastructure in a cloud-agnostic way. - Kubernetes has become a de facto multi-cloud runtime – you can deploy a Kubernetes cluster on AWS, Azure, or GCP (or use their managed k8s services) and run containerized apps similarly across them. This gives a layer of consistency. - Service meshes (like Istio, Linkerd) and API gateways can span clouds, providing unified control over microservices communication across environments.

Some organizations adopt a “best-of-breed” multi-cloud approach: e.g., use Google Cloud’s BigQuery for analytics (because of its advanced capability), but use AWS for core compute and Azure for some specific .NET-based workloads. The challenge then is integrating data and identity across these.

We also see interest in federated cloud or cloud burst scenarios – e.g., a company with its own private cloud might burst to public cloud for extra capacity when needed. Technologies like VMware Cloud on AWS, Azure Arc, or Google Anthos aim to blur the line between on-prem and public, letting workloads move freely. For instance, Azure Arc allows deploying Azure-managed databases inside one’s own data center but managed through Azure’s interface, effectively extending Azure into the private environment.

A likely future development is standardized multi-cloud APIs. The Open Service Broker API is one attempt that allows cloud services (databases, messaging) to be offered in a platform-neutral way to applications. The CNCF’s work on CloudEvents standard (for event messaging across clouds) is another helpful piece. In practice, complete cloud-agnosticism is hard (because each provider innovates unique services), but at least for core services (VMs, containers, storage, basic databases) multi-cloud abstractions are maturing.

From an organizational perspective, many enterprises have formed Cloud Centers of Excellence (CCoE) or central cloud teams that govern usage across multiple clouds, set policies, and share best practices. This helps avoid siloed cloud efforts and ensures security and compliance uniformly.

One thing to note: multi-cloud strategies emphasize portability. Projects like Docker and Kubernetes were actually key enablers of multi-cloud, by providing a uniform container runtime. Newer projects like Knative (for serverless portability) also target this, as mentioned in Section 14.1. We might foresee a future where a function or container can dynamically move to whichever cloud has the best price/performance at that moment, potentially brokered by an AI system that optimizes cloud usage in real-time – “spot market multi-cloud deployment”. While ambitious, pieces of this exist (e.g., Spot instancing services, multi-cloud cost managers).

The reality is, according to Flexera’s State of Cloud report, 89% of companies have a multi-cloud or hybrid strategy. So any cloud professional must consider how to design systems that can span clouds or easily migrate if needed. This also affects procurement – companies negotiate with multiple vendors and may prefer open technologies to avoid getting stuck.

---