Multi-Cloud Strategy

Multi-cloud means running workloads across two or more cloud providers: AWS, Google Cloud, Azure, or others. It promises vendor independence, compliance flexibility, and best-of-breed service selection. But it also multiplies complexity, costs, and the operational surface area. Multi-cloud is a strategy that should be chosen deliberately, not accidental.

---

When Multi-Cloud Makes Sense

Good Reasons:
  ☐ Regulatory requirement (data sovereignty in specific regions)
  ☐ Acquisition: Acquired company uses different cloud
  ☐ Best-of-breed: BigQuery for analytics, AWS for compute
  ☐ Disaster recovery: Cloud-level redundancy
  ☐ Customer requirement: Deploy in customer's cloud

Bad Reasons:
  "Avoid vendor lock-in" (often costs more than lock-in)
  "Negotiate better pricing" (volume discounts work better)
  "Spread risk" (cloud outages are rare, complexity is constant)
  "Because we can" (complexity without benefit)

---

Abstraction Strategies

Level 1: Infrastructure Abstraction (Terraform)
  Use Terraform with provider-agnostic modules
  Trade-off: Limited to common denominator features
  
  resource "kubernetes_deployment" "app" {
    # Same Terraform code deploys to EKS, GKE, or AKS
  }

Level 2: Container Orchestration (Kubernetes)
  Run Kubernetes on every cloud
  Trade-off: Kubernetes everywhere, but managed services differ
  
  Same manifests, different clusters:
  EKS (AWS), GKE (Google), AKS (Azure)

Level 3: Application Abstraction (Dapr, Knative)
  Application code unaware of cloud provider
  Trade-off: Additional layer, not all features available
  
  Dapr sidecar handles: state, pub/sub, secrets, bindings
  Application talks to Dapr, Dapr talks to cloud services

Level 4: Fully Portable (Cloud-agnostic services only)
  Only use open-source: PostgreSQL, Redis, Kafka, MinIO
  Trade-off: Miss cloud-native benefits (managed services)

---

Data Strategy

Data is the hardest part of multi-cloud:
  
  Replication:
    Sync data between clouds (cross-cloud latency: 10-50ms)
    Cost: Egress charges ($0.08-0.12/GB)
    Consistency: Eventual (or expensive cross-cloud transactions)
  
  Data Sovereignty:
    EU data stays in EU cloud regions
    US data stays in US cloud regions
    Some countries require in-country hosting
  
  Patterns:
  
  Active-Passive:
    Cloud A: Primary (all writes)
    Cloud B: Read replica (disaster recovery)
    RPO: Minutes to hours
    
  Active-Active:
    Cloud A: Serves region 1
    Cloud B: Serves region 2
    Sync: Bidirectional replication
    Conflict: Last-writer-wins or application-level merge
    
  Data Gravity:
    Keep data where it's processed
    Move compute to data, not data to compute
    If analytics is on BigQuery, keep analytical data on GCS

---

Anti-Patterns

Anti-Pattern	Consequence	Fix
Accidental multi-cloud	Complexity without strategy	Deliberate decision with clear benefits
Lowest common denominator	Lose cloud-native advantages	Use cloud-native where it matters, abstract where portable
Same app on every cloud	Double the ops work	Primary cloud + DR or regional deployment
Ignore egress costs	Data transfer bills explode	Minimize cross-cloud data movement
Separate teams per cloud	Silos, inconsistent practices	Platform team that spans clouds

Multi-cloud should be a response to a specific need — not a default architecture. Most organizations benefit from being cloud-native on one provider and having a clear strategy for the specific scenarios that require a second.