Multi-Cloud - Learning Module

Loading content...

0/273

Abstraction Layers: Patterns for Multi-Cloud Portability

Taming Multi-Cloud Complexity Through Abstraction

The previous pages established why organizations pursue multi-cloud and the significant challenges this entails. Now we address the fundamental question: How do organizations actually operate across multiple clouds without being overwhelmed by complexity?

The answer lies in abstraction—creating layers that shield developers and operators from cloud-specific details while preserving the ability to leverage each cloud's strengths. Like all abstractions, these layers involve trade-offs: they reduce complexity at the cost of losing some provider-specific capabilities.

This page examines the primary abstraction patterns used in production multi-cloud environments, evaluating when to use each and understanding their limitations.

Learning Objectives

After completing this page, you will understand: (1) Kubernetes as a compute abstraction layer, (2) Infrastructure as Code tools like Terraform for infrastructure portability, (3) Service mesh for network abstraction, (4) Application-level abstraction patterns, and (5) The trade-offs inherent in each approach.

The Abstraction Spectrum

Before examining specific technologies, let's understand the spectrum of abstraction approaches:

No Abstraction (Cloud-Native)

Use each cloud's native services directly
Deepest integration, best performance
Maximum vendor lock-in
Highest operational complexity in multi-cloud

Selective Abstraction

Abstract what benefits from portability (compute, basic storage)
Use cloud-native for differentiated services (ML, analytics)
Balanced approach; requires deliberate design

Full Abstraction (Cloud-Agnostic)

Abstract everything; treat clouds as commoditized compute
Maximum portability
Lose competitive advantages of each cloud
Often more expensive operationally

The right choice depends on your organization's priorities. Most successful multi-cloud implementations fall in the selective abstraction camp—abstracting compute and networking while leveraging specific cloud strengths.

Abstraction Trade-offs by Layer
Layer	Abstraction Options	Trade-off
Compute	Kubernetes, VMs, Containers	K8s provides good portability but not all workloads fit container model
Storage	S3-compatible APIs, CSI drivers	Object storage portable; managed databases are not
Networking	Service mesh, SDN overlays	Adds latency and complexity; powerful security benefits
Identity	External IdP, Workload Identity	Single IdP simplifies; cross-cloud federation is complex
Databases	PostgreSQL, MySQL (portable)	Managed services (Aurora, Spanner) faster but locked in
ML/AI	Minimal practical abstraction	Cloud-specific platforms dominate; MLOps tooling helps
Analytics	Presto/Trino, Spark	Query federation possible; data gravity limits mobility

The 80/20 Rule of Abstraction

In practice, organizations can abstract about 80% of their workloads with moderate effort (standardized compute, storage, networking). The remaining 20% (specialized services, ML platforms, high-performance databases) often aren't worth abstracting. Accept some cloud-specific dependencies for substantial capability gains.

Kubernetes as Compute Abstraction

Kubernetes has become the de facto standard for multi-cloud compute abstraction. Its declarative API, portable workload definitions, and ecosystem of cloud-agnostic tools make it the foundation of most multi-cloud strategies.

2.1 Why Kubernetes Works for Multi-Cloud

The Portable API:

A Kubernetes Deployment manifest runs identically on:

AWS EKS (Elastic Kubernetes Service)
Google GKE (Google Kubernetes Engine)
Azure AKS (Azure Kubernetes Service)
Self-managed clusters on any infrastructure

This portability isn't theoretical—organizations regularly migrate workloads between managed Kubernetes services.

portable-deployment.yaml
Kubernetes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
# This manifest runs unchanged on EKS, GKE, or AKS
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app: order-service
    environment: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: registry.example.com/order-service:v2.3.1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: order-service-secrets
                  key: database-url
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

2.2 Managed Kubernetes Across Clouds

All major cloud providers offer managed Kubernetes services that handle control plane operations:

Managed Kubernetes Services Comparison
Feature	AWS EKS	Google GKE	Azure AKS
Control Plane Cost	$0.10/hour (~$73/month)	Free (Autopilot: per-pod)	Free
Max Nodes	5,000	15,000	5,000
Auto-Updates	Manual or managed	Release channels	Auto-upgrade option
Node Autoscaling	Cluster Autoscaler, Karpenter	Node Auto-provisioning	Cluster Autoscaler
Serverless Option	Fargate	Autopilot	Virtual Nodes (ACI)
GPU Support	P4, P5 instances	T4, A100, L4	NC, ND series
Windows Nodes	Supported	Supported	Supported
Policy Engine	Gatekeeper, Kyverno	Policy Controller	Azure Policy

2.3 Multi-Cluster Management

The Challenge: Running Kubernetes on multiple clouds means managing multiple clusters. How do you deploy consistently, manage configurations, and maintain operational visibility?

Solutions:

GitOps with Cluster Fleet Management:

Argo CD — Deploys to multiple clusters from Git repositories
Flux — CNCF GitOps project with multi-cluster support
Rancher Fleet — Built specifically for managing fleets of clusters

Cluster API (CAPI):

Kubernetes-native approach to cluster lifecycle management
Define clusters as Kubernetes resources
Providers for AWS, GCP, Azure, and more
Enables consistent cluster provisioning across clouds

Commercial Platforms:

Google Anthos — GKE-based multi-cloud Kubernetes management
Azure Arc — Extends Azure control plane to any Kubernetes
Rancher — Open-source multi-cluster Kubernetes management
Red Hat OpenShift — Enterprise Kubernetes with multi-cloud support

argocd-multi-cluster.yaml
Argo CD ApplicationSet
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# Deploy an application to multiple clusters using Argo CD ApplicationSet
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: order-service
  namespace: argocd
spec:
  generators:
    # Generate applications for each cluster
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: 'order-service-{{name}}'
    spec:
      project: production
      source:
        repoURL: https://github.com/org/order-service
        targetRevision: main
        path: k8s/overlays/{{metadata.labels.cloud}}
      destination:
        server: '{{server}}'
        namespace: order-service
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true
          - ApplyOutOfSyncOnly=true
 
---
# Cluster secrets define target clusters
# Each cluster registered as a secret in argocd namespace
apiVersion: v1
kind: Secret
metadata:
  name: prod-aws-us-east-1
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
    environment: production
    cloud: aws
    region: us-east-1
type: Opaque
stringData:
  name: prod-aws-us-east-1
  server: https://eks.us-east-1.example.com
  config: |
    {
      "execProviderConfig": {
        "command": "aws",
        "args": ["eks", "get-token", "--cluster-name", "prod-cluster"],
        "env": {
          "AWS_REGION": "us-east-1"
        }
      },
      "tlsClientConfig": {
        "insecure": false,
        "caData": "<base64-ca-cert>"
      }
    }

2.4 The Limits of Kubernetes Abstraction

What Kubernetes Doesn't Abstract:

Node Infrastructure — Underlying VMs differ in capabilities (network performance, GPU types, local storage)
Load Balancer Behavior — Service type LoadBalancer creates cloud-specific resources with different features
Storage Classes — PersistentVolume provisioners are cloud-specific
Node Scaling — Autoscaler behavior, spot/preemptible instance handling differs
Networking — CNI plugins, ingress controllers, and network policies vary
Identity — Workload identity, IRSA (EKS), Workload Identity (GKE), Pod Identity (AKS) all work differently

Kubernetes Is Not Enough

Kubernetes provides a portable compute API, but production deployments require storage, networking, identity, and security configurations that remain cloud-specific. Teams that assume 'we use Kubernetes so we're portable' often discover significant cloud coupling in their actual deployments.

Infrastructure as Code for Multi-Cloud

Infrastructure as Code tools provide abstraction at the infrastructure provisioning layer, allowing engineers to define resources that span multiple clouds using consistent languages and workflows.

3.1 Terraform as Multi-Cloud IaC

Why Terraform Dominates Multi-Cloud:

Provider Ecosystem — Providers for AWS, GCP, Azure, and hundreds of other services
Consistent Language — HCL (HashiCorp Configuration Language) across all providers
State Management — Tracks resource state centrally
Module Reuse — Abstract common patterns into reusable modules
Open Source with Enterprise Options — Flexibility for organizations of all sizes

multi-cloud-terraform.tf

Terraform

# Multi-cloud Kubernetes cluster provisioning
# Demonstrates unified approach with cloud-specific implementations
 
# Provider configurations
provider "aws" {
  region = var.aws_region
  alias  = "aws"
}
 
provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
  alias   = "gcp"
}
 
provider "azurerm" {
  features {}
  alias = "azure"
}
 
# Variable to select which cloud to deploy to
variable "cloud_provider" {
  type        = string
  description = "Target cloud provider: aws, gcp, or azure"
  validation {
    condition     = contains(["aws", "gcp", "azure"], var.cloud_provider)
    error_message = "cloud_provider must be aws, gcp, or azure."
  }
}
 
# Locals for cloud-specific configuration
locals {
  is_aws   = var.cloud_provider == "aws"
  is_gcp   = var.cloud_provider == "gcp"
  is_azure = var.cloud_provider == "azure"
}
 
# AWS EKS Cluster
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 19.0"
  count   = local.is_aws ? 1 : 0
  
  providers = {
    aws = aws.aws
  }
 
  cluster_name    = var.cluster_name
  cluster_version = "1.28"
 
  vpc_id     = module.aws_vpc[0].vpc_id
  subnet_ids = module.aws_vpc[0].private_subnets
 
  eks_managed_node_groups = {
    primary = {
      instance_types = ["m6i.large"]
      min_size       = 2
      max_size       = 10
      desired_size   = 3
    }
  }
 
  tags = local.common_tags
}
 
# GCP GKE Cluster
resource "google_container_cluster" "gke" {
  provider = google.gcp
  count    = local.is_gcp ? 1 : 0
 
  name     = var.cluster_name
  location = var.gcp_region
 
  # Enable Autopilot for managed node management
  enable_autopilot = true
 
  network    = google_compute_network.vpc[0].name
  subnetwork = google_compute_subnetwork.subnet[0].name
 
  # Workload Identity for pod authentication
  workload_identity_config {
    workload_pool = "${var.gcp_project}.svc.id.goog"
  }
 
  # Private cluster configuration
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
}
 
# Azure AKS Cluster
resource "azurerm_kubernetes_cluster" "aks" {
  provider            = azurerm.azure
  count               = local.is_azure ? 1 : 0
  
  name                = var.cluster_name
  location            = var.azure_region
  resource_group_name = azurerm_resource_group.rg[0].name
  dns_prefix          = var.cluster_name
 
  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_D2_v2"
    vnet_subnet_id = azurerm_subnet.aks[0].id
  }
 
  identity {
    type = "SystemAssigned"
  }
 
  network_profile {
    network_plugin = "azure"
    network_policy = "calico"
  }
 
  tags = local.common_tags
}
 
# Unified output regardless of cloud
output "cluster_endpoint" {
  description = "Kubernetes cluster API endpoint"
  value = coalesce(
    try(module.eks[0].cluster_endpoint, null),
    try(google_container_cluster.gke[0].endpoint, null),
    try(azurerm_kubernetes_cluster.aks[0].kube_config[0].host, null)
  )
}

3.2 Pulumi and CDK Alternatives

Pulumi:

Infrastructure as Code using real programming languages (TypeScript, Python, Go, C#)
Multi-cloud providers similar to Terraform
Logic and conditionals are first-class citizens
Stronger typing and IDE support

AWS CDK / GCP DM / Azure Bicep:

Cloud-specific but more integrated with provider features
Not suitable for multi-cloud by themselves
CDK for Terraform (CDKTF) bridges this gap

Crossplane:

Kubernetes-native infrastructure management
Define cloud resources as Kubernetes custom resources
GitOps-compatible, reconciliation-based
Growing multi-cloud provider support

crossplane-composition.yaml
Crossplane
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
# Crossplane Composition: Abstract 'Database' that maps to cloud-specific implementations
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xdatabases.example.org
spec:
  group: example.org
  names:
    kind: XDatabase
    plural: xdatabases
  claimNames:
    kind: Database
    plural: databases
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                parameters:
                  type: object
                  properties:
                    size:
                      type: string
                      enum: [small, medium, large]
                    engine:
                      type: string
                      enum: [postgres, mysql]
                    cloud:
                      type: string
                      enum: [aws, gcp, azure]
                  required:
                    - size
                    - engine
                    - cloud
 
---
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xdatabases-aws
  labels:
    crossplane.io/xrd: xdatabases.example.org
    cloud: aws
spec:
  compositeTypeRef:
    apiVersion: example.org/v1alpha1
    kind: XDatabase
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.crossplane.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            region: us-west-2
            dbInstanceClass: db.t3.medium
            allocatedStorage: 20
            engine: postgres
            engineVersion: "14"
            masterUsername: admin
            skipFinalSnapshotBeforeDeletion: true
          providerConfigRef:
            name: aws-provider
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.parameters.size
          toFieldPath: spec.forProvider.dbInstanceClass
          transforms:
            - type: map
              map:
                small: db.t3.micro
                medium: db.t3.medium
                large: db.r6g.large
 
---
# Users request a database without knowing cloud specifics
apiVersion: example.org/v1alpha1
kind: Database
metadata:
  name: orders-db
  namespace: production
spec:
  parameters:
    size: medium
    engine: postgres
    cloud: aws

IaC Doesn't Equal Portability

Using Terraform doesn't automatically make infrastructure portable. If you're using AWS-specific resources (Aurora, DynamoDB, Kinesis), they're written in Terraform but cannot be deployed to GCP. IaC provides consistency and automation, not automatic abstraction.

Service Mesh for Network Abstraction

Service mesh provides network abstraction that's particularly valuable in multi-cloud environments, enabling consistent security, observability, and traffic management regardless of where services run.

4.1 Why Service Mesh for Multi-Cloud

Core Capabilities:

Mutual TLS (mTLS) — All service-to-service communication encrypted and authenticated, including cross-cloud
Unified Traffic Policy — Rate limiting, retries, timeouts defined once, enforced everywhere
Observability — Distributed tracing, metrics, and access logs across all services
Traffic Splitting — Canary deployments, A/B testing across clouds
Service Discovery — Services find each other regardless of cloud location

Service Mesh Options for Multi-Cloud
Mesh	Multi-Cluster	Control Plane	Key Strengths
Istio	Native multi-cluster	Istiod	Feature-rich, large community, complex
Linkerd	Multi-cluster extension	Control plane per cluster	Lightweight, simple, Rust data plane
Consul Connect	Native WAN federation	Consul servers	HashiCorp ecosystem, VM support
Cilium	Cluster Mesh feature	Cluster per cluster	eBPF-based, high performance
AWS App Mesh	Limited to AWS	Managed	AWS-native, Envoy-based

4.2 Multi-Cluster Service Mesh Architecture

Istio Multi-Primary:

Each cluster runs its own Istiod control plane
Clusters share a trust domain for mTLS
Service discovery spans clusters
Traffic can flow seamlessly between clusters

Key Configuration:

istio-multi-cluster.yaml
Istio
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
# Istio multi-cluster configuration
# Cluster 1 (AWS EKS) - Primary with shared control plane identity
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-control-plane
  namespace: istio-system
spec:
  profile: default
  
  values:
    global:
      meshID: multi-cloud-mesh
      multiCluster:
        clusterName: cluster-aws-east
      network: network-aws
      
    pilot:
      env:
        # Enable endpoint discovery across clusters
        PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY: "true"
  
  components:
    ingressGateways:
      - name: istio-eastwestgateway
        label:
          istio: eastwestgateway
          app: istio-eastwestgateway
        enabled: true
        k8s:
          env:
            - name: ISTIO_META_REQUESTED_NETWORK_VIEW
              value: network-aws
          service:
            ports:
              - name: status-port
                port: 15021
                targetPort: 15021
              - name: tls
                port: 15443
                targetPort: 15443
              - name: tls-istiod
                port: 15012
                targetPort: 15012
              - name: tls-webhook
                port: 15017
                targetPort: 15017
 
---
# ServiceEntry to expose remote cluster services
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: gcp-services
  namespace: istio-system
spec:
  hosts:
    - "*.cluster-gcp-west.global"
  location: MESH_INTERNAL
  ports:
    - name: http
      number: 80
      protocol: HTTP
    - name: grpc
      number: 443
      protocol: GRPC
  resolution: DNS
  endpoints:
    - address: istio-eastwestgateway.istio-system.svc.cluster.local
      network: network-gcp
      ports:
        http: 15443
 
---
# Virtual Service for cross-cluster traffic splitting
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: order-service
  namespace: production
spec:
  hosts:
    - order-service
  http:
    - route:
        # 80% to local (AWS) cluster
        - destination:
            host: order-service
            subset: aws
          weight: 80
        # 20% to GCP cluster for canary
        - destination:
            host: order-service.cluster-gcp-west.global
            subset: gcp
          weight: 20

4.3 Cross-Cloud mTLS and Trust

The Trust Problem:

For mTLS to work across clouds, services must share a common Certificate Authority (CA) so they can verify each other's identities.

Solutions:

Shared Istio Root CA — All clusters use the same root CA (stored in Vault or generated at install)
SPIFFE/SPIRE — Open standard for workload identity; works across clouds and non-Kubernetes
External CA Integration — Istio integrates with external CAs (cert-manager, Vault)

Trust Domain:

All clusters should share a trust domain (e.g., cluster.local or a custom domain like mesh.example.com). This allows the identity spiffe://mesh.example.com/ns/production/sa/order-service to be verified in any cluster.

Service Mesh Complexity

Service mesh adds operational complexity: sidecar injection, proxy configuration, debugging failures through proxies. Multi-cluster mesh multiplies this complexity. Start with single-cluster mesh, gain operational maturity, then expand to multi-cluster.

Application-Level Abstraction Patterns

Beyond infrastructure abstraction, applications themselves can be designed for multi-cloud portability through careful architectural patterns.

5.1 The Twelve-Factor App for Multi-Cloud

The Twelve-Factor methodology, originally designed for PaaS portability, translates directly to multi-cloud:

Config in Environment — No cloud-specific config in code; inject via environment variables
Stateless Processes — Enable horizontal scaling and cloud-agnostic deployment
Port Binding — Self-contained services; no reliance on cloud-specific runtime features
Concurrency — Scale via process model, not cloud-specific scaling primitives
Disposability — Fast startup and graceful shutdown enable rapid scheduling changes
Dev/Prod Parity — Consistent environments reduce cloud-specific bugs

5.2 Cloud SDK Abstraction

The Problem: Applications often use cloud-specific SDKs directly:

// Tightly coupled to AWS
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client({ region: 'us-east-1' });
await s3.send(new PutObjectCommand({ Bucket, Key, Body }));

The Solution: Abstract storage operations behind an interface:

// Cloud-agnostic storage interface
interface ObjectStorage {
  put(bucket: string, key: string, data: Buffer): Promise<void>;
  get(bucket: string, key: string): Promise<Buffer>;
  delete(bucket: string, key: string): Promise<void>;
}

// Implementation provided at runtime based on configuration
const storage: ObjectStorage = createStorageClient(process.env.CLOUD_PROVIDER);

Libraries that help:

Apache Libcloud (Python) — Unified API for cloud services
Multi-Cloud SDK patterns — Build your own adapter pattern
Dapr — Portable runtime with pluggable components for state, pubsub, etc.

dapr-components.yaml
Dapr (Multi-Cloud)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
# Dapr provides cloud-agnostic building blocks
# Applications call Dapr APIs; Dapr handles cloud-specific integration
 
# State Store component - AWS DynamoDB
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  namespace: production
spec:
  type: state.aws.dynamodb
  version: v1
  metadata:
    - name: region
      value: "us-east-1"
    - name: table
      value: "app-state"
    - name: accessKey
      secretKeyRef:
        name: aws-credentials
        key: access-key
    - name: secretKey
      secretKeyRef:
        name: aws-credentials
        key: secret-key
 
---
# Same application code works with GCP Firestore
# by swapping the component configuration
 
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  namespace: production
spec:
  type: state.gcp.firestore
  version: v1
  metadata:
    - name: project_id
      value: "my-gcp-project"
    - name: type
      value: "service_account"
    - name: private_key_id
      secretKeyRef:
        name: gcp-credentials
        key: private-key-id
 
---
# Pub/Sub component - abstracted from cloud specifics
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
  namespace: production
spec:
  type: pubsub.kafka  # Or pubsub.aws.snssqs, pubsub.gcp.pubsub
  version: v1
  metadata:
    - name: brokers
      value: "kafka-cluster.production.svc:9092"
    - name: consumerGroup
      value: "order-service"
 
---
# Application code is cloud-agnostic
# Just calls Dapr sidecar HTTP/gRPC API
 
# curl http://localhost:3500/v1.0/state/statestore -X POST -d '[{"key":"id","value":"data"}]'
# curl http://localhost:3500/v1.0/publish/pubsub/orders -X POST -d '{"orderId":"123"}'

5.3 Database Portability Patterns

Challenge: Managed databases are powerful but non-portable.

Strategies:

Use Portable Database Engines
- PostgreSQL, MySQL work on all clouds
- Managed services (RDS, Cloud SQL, Azure Database) use same engine
- Application code unchanged; only connection string differs
Abstract Database Access
- Use ORMs (Prisma, SQLAlchemy, Hibernate) that abstract SQL dialects
- Avoid cloud-specific SQL extensions
Accept Strategic Lock-in
- Sometimes, DynamoDB or Spanner capabilities are worth lock-in
- Make conscious choices about what's portable vs. optimized
Event Sourcing / CQRS
- Store events in portable format (Kafka, PostgreSQL)
- Rebuild read models in any cloud from events

Interface Segregation

The key to application portability is interface segregation: define abstract interfaces for cloud interactions (storage, queues, databases), implement them per cloud, and inject the appropriate implementation at runtime. This is dependency injection applied to cloud services.

Summary: Choosing Your Abstraction Strategy

Abstraction layers are the tools that make multi-cloud manageable. Let's consolidate the key patterns:

Key Abstraction Patterns

•Kubernetes — Primary compute abstraction; workload definitions are portable, but infrastructure integration (storage, networking, identity) remains cloud-specific.
•Terraform/IaC — Provides consistent provisioning workflow and language across clouds; doesn't automatically make resources portable.
•Service Mesh — Abstracts networking, security, and observability; enables seamless cross-cloud service communication with mTLS.
•Application Patterns — Interface abstraction, Dapr, and portable database engines enable cloud-agnostic application code.
•Selective Abstraction — Abstract commodity services; accept lock-in for differentiated capabilities. This is the practical path.

The Abstraction Mindset:

Successful multi-cloud abstraction requires thinking in layers:

What MUST be portable? — Core business logic, critical data stores
What SHOULD be portable? — Commodity compute, object storage, basic networking
What CAN be cloud-specific? — ML platforms, specialized analytics, managed services that dramatically accelerate development

What's Next:

With abstraction patterns understood, the next page examines data portability—one of the most challenging aspects of multi-cloud. We'll explore data synchronization strategies, format standards, and the realities of moving data between clouds.

Page Complete

You now understand the primary abstraction layers used in multi-cloud architectures. These patterns—Kubernetes, IaC, service mesh, and application abstractions—form the foundation of practical multi-cloud implementation.

Abstraction Layers: Patterns for Multi-Cloud Portability

Taming Multi-Cloud Complexity Through Abstraction

This page examines the primary abstraction patterns used in production multi-cloud environments, evaluating when to use each and understanding their limitations.

Learning Objectives

The Abstraction Spectrum

Before examining specific technologies, let's understand the spectrum of abstraction approaches:

No Abstraction (Cloud-Native)

Use each cloud's native services directly
Deepest integration, best performance
Maximum vendor lock-in
Highest operational complexity in multi-cloud

Selective Abstraction

Abstract what benefits from portability (compute, basic storage)
Use cloud-native for differentiated services (ML, analytics)
Balanced approach; requires deliberate design

Full Abstraction (Cloud-Agnostic)

Abstract everything; treat clouds as commoditized compute
Maximum portability
Lose competitive advantages of each cloud
Often more expensive operationally

Abstraction Trade-offs by Layer
Layer	Abstraction Options	Trade-off
Compute	Kubernetes, VMs, Containers	K8s provides good portability but not all workloads fit container model
Storage	S3-compatible APIs, CSI drivers	Object storage portable; managed databases are not
Networking	Service mesh, SDN overlays	Adds latency and complexity; powerful security benefits
Identity	External IdP, Workload Identity	Single IdP simplifies; cross-cloud federation is complex
Databases	PostgreSQL, MySQL (portable)	Managed services (Aurora, Spanner) faster but locked in
ML/AI	Minimal practical abstraction	Cloud-specific platforms dominate; MLOps tooling helps
Analytics	Presto/Trino, Spark	Query federation possible; data gravity limits mobility

The 80/20 Rule of Abstraction

Kubernetes as Compute Abstraction

2.1 Why Kubernetes Works for Multi-Cloud

The Portable API:

A Kubernetes Deployment manifest runs identically on:

AWS EKS (Elastic Kubernetes Service)
Google GKE (Google Kubernetes Engine)
Azure AKS (Azure Kubernetes Service)
Self-managed clusters on any infrastructure

This portability isn't theoretical—organizations regularly migrate workloads between managed Kubernetes services.

portable-deployment.yaml
Kubernetes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
# This manifest runs unchanged on EKS, GKE, or AKS
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app: order-service
    environment: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: registry.example.com/order-service:v2.3.1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: order-service-secrets
                  key: database-url
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

2.2 Managed Kubernetes Across Clouds

All major cloud providers offer managed Kubernetes services that handle control plane operations:

Managed Kubernetes Services Comparison
Feature	AWS EKS	Google GKE	Azure AKS
Control Plane Cost	$0.10/hour (~$73/month)	Free (Autopilot: per-pod)	Free
Max Nodes	5,000	15,000	5,000
Auto-Updates	Manual or managed	Release channels	Auto-upgrade option
Node Autoscaling	Cluster Autoscaler, Karpenter	Node Auto-provisioning	Cluster Autoscaler
Serverless Option	Fargate	Autopilot	Virtual Nodes (ACI)
GPU Support	P4, P5 instances	T4, A100, L4	NC, ND series
Windows Nodes	Supported	Supported	Supported
Policy Engine	Gatekeeper, Kyverno	Policy Controller	Azure Policy

2.3 Multi-Cluster Management

The Challenge: Running Kubernetes on multiple clouds means managing multiple clusters. How do you deploy consistently, manage configurations, and maintain operational visibility?

Solutions:

GitOps with Cluster Fleet Management:

Argo CD — Deploys to multiple clusters from Git repositories
Flux — CNCF GitOps project with multi-cluster support
Rancher Fleet — Built specifically for managing fleets of clusters

Cluster API (CAPI):

Kubernetes-native approach to cluster lifecycle management
Define clusters as Kubernetes resources
Providers for AWS, GCP, Azure, and more
Enables consistent cluster provisioning across clouds

Commercial Platforms:

Google Anthos — GKE-based multi-cloud Kubernetes management
Azure Arc — Extends Azure control plane to any Kubernetes
Rancher — Open-source multi-cluster Kubernetes management
Red Hat OpenShift — Enterprise Kubernetes with multi-cloud support

argocd-multi-cluster.yaml
Argo CD ApplicationSet
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# Deploy an application to multiple clusters using Argo CD ApplicationSet
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: order-service
  namespace: argocd
spec:
  generators:
    # Generate applications for each cluster
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: 'order-service-{{name}}'
    spec:
      project: production
      source:
        repoURL: https://github.com/org/order-service
        targetRevision: main
        path: k8s/overlays/{{metadata.labels.cloud}}
      destination:
        server: '{{server}}'
        namespace: order-service
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true
          - ApplyOutOfSyncOnly=true
 
---
# Cluster secrets define target clusters
# Each cluster registered as a secret in argocd namespace
apiVersion: v1
kind: Secret
metadata:
  name: prod-aws-us-east-1
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
    environment: production
    cloud: aws
    region: us-east-1
type: Opaque
stringData:
  name: prod-aws-us-east-1
  server: https://eks.us-east-1.example.com
  config: |
    {
      "execProviderConfig": {
        "command": "aws",
        "args": ["eks", "get-token", "--cluster-name", "prod-cluster"],
        "env": {
          "AWS_REGION": "us-east-1"
        }
      },
      "tlsClientConfig": {
        "insecure": false,
        "caData": "<base64-ca-cert>"
      }
    }

2.4 The Limits of Kubernetes Abstraction

What Kubernetes Doesn't Abstract:

Node Infrastructure — Underlying VMs differ in capabilities (network performance, GPU types, local storage)
Load Balancer Behavior — Service type LoadBalancer creates cloud-specific resources with different features
Storage Classes — PersistentVolume provisioners are cloud-specific
Node Scaling — Autoscaler behavior, spot/preemptible instance handling differs
Networking — CNI plugins, ingress controllers, and network policies vary
Identity — Workload identity, IRSA (EKS), Workload Identity (GKE), Pod Identity (AKS) all work differently

Kubernetes Is Not Enough

Infrastructure as Code for Multi-Cloud

Infrastructure as Code tools provide abstraction at the infrastructure provisioning layer, allowing engineers to define resources that span multiple clouds using consistent languages and workflows.

3.1 Terraform as Multi-Cloud IaC

Why Terraform Dominates Multi-Cloud:

Provider Ecosystem — Providers for AWS, GCP, Azure, and hundreds of other services
Consistent Language — HCL (HashiCorp Configuration Language) across all providers
State Management — Tracks resource state centrally
Module Reuse — Abstract common patterns into reusable modules
Open Source with Enterprise Options — Flexibility for organizations of all sizes

multi-cloud-terraform.tf

Terraform

# Multi-cloud Kubernetes cluster provisioning
# Demonstrates unified approach with cloud-specific implementations
 
# Provider configurations
provider "aws" {
  region = var.aws_region
  alias  = "aws"
}
 
provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
  alias   = "gcp"
}
 
provider "azurerm" {
  features {}
  alias = "azure"
}
 
# Variable to select which cloud to deploy to
variable "cloud_provider" {
  type        = string
  description = "Target cloud provider: aws, gcp, or azure"
  validation {
    condition     = contains(["aws", "gcp", "azure"], var.cloud_provider)
    error_message = "cloud_provider must be aws, gcp, or azure."
  }
}
 
# Locals for cloud-specific configuration
locals {
  is_aws   = var.cloud_provider == "aws"
  is_gcp   = var.cloud_provider == "gcp"
  is_azure = var.cloud_provider == "azure"
}
 
# AWS EKS Cluster
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 19.0"
  count   = local.is_aws ? 1 : 0
  
  providers = {
    aws = aws.aws
  }
 
  cluster_name    = var.cluster_name
  cluster_version = "1.28"
 
  vpc_id     = module.aws_vpc[0].vpc_id
  subnet_ids = module.aws_vpc[0].private_subnets
 
  eks_managed_node_groups = {
    primary = {
      instance_types = ["m6i.large"]
      min_size       = 2
      max_size       = 10
      desired_size   = 3
    }
  }
 
  tags = local.common_tags
}
 
# GCP GKE Cluster
resource "google_container_cluster" "gke" {
  provider = google.gcp
  count    = local.is_gcp ? 1 : 0
 
  name     = var.cluster_name
  location = var.gcp_region
 
  # Enable Autopilot for managed node management
  enable_autopilot = true
 
  network    = google_compute_network.vpc[0].name
  subnetwork = google_compute_subnetwork.subnet[0].name
 
  # Workload Identity for pod authentication
  workload_identity_config {
    workload_pool = "${var.gcp_project}.svc.id.goog"
  }
 
  # Private cluster configuration
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
}
 
# Azure AKS Cluster
resource "azurerm_kubernetes_cluster" "aks" {
  provider            = azurerm.azure
  count               = local.is_azure ? 1 : 0
  
  name                = var.cluster_name
  location            = var.azure_region
  resource_group_name = azurerm_resource_group.rg[0].name
  dns_prefix          = var.cluster_name
 
  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_D2_v2"
    vnet_subnet_id = azurerm_subnet.aks[0].id
  }
 
  identity {
    type = "SystemAssigned"
  }
 
  network_profile {
    network_plugin = "azure"
    network_policy = "calico"
  }
 
  tags = local.common_tags
}
 
# Unified output regardless of cloud
output "cluster_endpoint" {
  description = "Kubernetes cluster API endpoint"
  value = coalesce(
    try(module.eks[0].cluster_endpoint, null),
    try(google_container_cluster.gke[0].endpoint, null),
    try(azurerm_kubernetes_cluster.aks[0].kube_config[0].host, null)
  )
}

3.2 Pulumi and CDK Alternatives

Pulumi:

Infrastructure as Code using real programming languages (TypeScript, Python, Go, C#)
Multi-cloud providers similar to Terraform
Logic and conditionals are first-class citizens
Stronger typing and IDE support

AWS CDK / GCP DM / Azure Bicep:

Cloud-specific but more integrated with provider features
Not suitable for multi-cloud by themselves
CDK for Terraform (CDKTF) bridges this gap

Crossplane:

Kubernetes-native infrastructure management
Define cloud resources as Kubernetes custom resources
GitOps-compatible, reconciliation-based
Growing multi-cloud provider support

crossplane-composition.yaml
Crossplane
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
# Crossplane Composition: Abstract 'Database' that maps to cloud-specific implementations
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xdatabases.example.org
spec:
  group: example.org
  names:
    kind: XDatabase
    plural: xdatabases
  claimNames:
    kind: Database
    plural: databases
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                parameters:
                  type: object
                  properties:
                    size:
                      type: string
                      enum: [small, medium, large]
                    engine:
                      type: string
                      enum: [postgres, mysql]
                    cloud:
                      type: string
                      enum: [aws, gcp, azure]
                  required:
                    - size
                    - engine
                    - cloud
 
---
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xdatabases-aws
  labels:
    crossplane.io/xrd: xdatabases.example.org
    cloud: aws
spec:
  compositeTypeRef:
    apiVersion: example.org/v1alpha1
    kind: XDatabase
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.crossplane.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            region: us-west-2
            dbInstanceClass: db.t3.medium
            allocatedStorage: 20
            engine: postgres
            engineVersion: "14"
            masterUsername: admin
            skipFinalSnapshotBeforeDeletion: true
          providerConfigRef:
            name: aws-provider
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.parameters.size
          toFieldPath: spec.forProvider.dbInstanceClass
          transforms:
            - type: map
              map:
                small: db.t3.micro
                medium: db.t3.medium
                large: db.r6g.large
 
---
# Users request a database without knowing cloud specifics
apiVersion: example.org/v1alpha1
kind: Database
metadata:
  name: orders-db
  namespace: production
spec:
  parameters:
    size: medium
    engine: postgres
    cloud: aws

IaC Doesn't Equal Portability

Service Mesh for Network Abstraction

4.1 Why Service Mesh for Multi-Cloud

Core Capabilities:

Mutual TLS (mTLS) — All service-to-service communication encrypted and authenticated, including cross-cloud
Unified Traffic Policy — Rate limiting, retries, timeouts defined once, enforced everywhere
Observability — Distributed tracing, metrics, and access logs across all services
Traffic Splitting — Canary deployments, A/B testing across clouds
Service Discovery — Services find each other regardless of cloud location

Service Mesh Options for Multi-Cloud
Mesh	Multi-Cluster	Control Plane	Key Strengths
Istio	Native multi-cluster	Istiod	Feature-rich, large community, complex
Linkerd	Multi-cluster extension	Control plane per cluster	Lightweight, simple, Rust data plane
Consul Connect	Native WAN federation	Consul servers	HashiCorp ecosystem, VM support
Cilium	Cluster Mesh feature	Cluster per cluster	eBPF-based, high performance
AWS App Mesh	Limited to AWS	Managed	AWS-native, Envoy-based

4.2 Multi-Cluster Service Mesh Architecture

Istio Multi-Primary:

Each cluster runs its own Istiod control plane
Clusters share a trust domain for mTLS
Service discovery spans clusters
Traffic can flow seamlessly between clusters

Key Configuration:

istio-multi-cluster.yaml
Istio
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
# Istio multi-cluster configuration
# Cluster 1 (AWS EKS) - Primary with shared control plane identity
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-control-plane
  namespace: istio-system
spec:
  profile: default
  
  values:
    global:
      meshID: multi-cloud-mesh
      multiCluster:
        clusterName: cluster-aws-east
      network: network-aws
      
    pilot:
      env:
        # Enable endpoint discovery across clusters
        PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY: "true"
  
  components:
    ingressGateways:
      - name: istio-eastwestgateway
        label:
          istio: eastwestgateway
          app: istio-eastwestgateway
        enabled: true
        k8s:
          env:
            - name: ISTIO_META_REQUESTED_NETWORK_VIEW
              value: network-aws
          service:
            ports:
              - name: status-port
                port: 15021
                targetPort: 15021
              - name: tls
                port: 15443
                targetPort: 15443
              - name: tls-istiod
                port: 15012
                targetPort: 15012
              - name: tls-webhook
                port: 15017
                targetPort: 15017
 
---
# ServiceEntry to expose remote cluster services
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: gcp-services
  namespace: istio-system
spec:
  hosts:
    - "*.cluster-gcp-west.global"
  location: MESH_INTERNAL
  ports:
    - name: http
      number: 80
      protocol: HTTP
    - name: grpc
      number: 443
      protocol: GRPC
  resolution: DNS
  endpoints:
    - address: istio-eastwestgateway.istio-system.svc.cluster.local
      network: network-gcp
      ports:
        http: 15443
 
---
# Virtual Service for cross-cluster traffic splitting
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: order-service
  namespace: production
spec:
  hosts:
    - order-service
  http:
    - route:
        # 80% to local (AWS) cluster
        - destination:
            host: order-service
            subset: aws
          weight: 80
        # 20% to GCP cluster for canary
        - destination:
            host: order-service.cluster-gcp-west.global
            subset: gcp
          weight: 20

4.3 Cross-Cloud mTLS and Trust

The Trust Problem:

For mTLS to work across clouds, services must share a common Certificate Authority (CA) so they can verify each other's identities.

Solutions:

Shared Istio Root CA — All clusters use the same root CA (stored in Vault or generated at install)
SPIFFE/SPIRE — Open standard for workload identity; works across clouds and non-Kubernetes
External CA Integration — Istio integrates with external CAs (cert-manager, Vault)

Trust Domain:

Service Mesh Complexity

Application-Level Abstraction Patterns

Beyond infrastructure abstraction, applications themselves can be designed for multi-cloud portability through careful architectural patterns.

5.1 The Twelve-Factor App for Multi-Cloud

The Twelve-Factor methodology, originally designed for PaaS portability, translates directly to multi-cloud:

Config in Environment — No cloud-specific config in code; inject via environment variables
Stateless Processes — Enable horizontal scaling and cloud-agnostic deployment
Port Binding — Self-contained services; no reliance on cloud-specific runtime features
Concurrency — Scale via process model, not cloud-specific scaling primitives
Disposability — Fast startup and graceful shutdown enable rapid scheduling changes
Dev/Prod Parity — Consistent environments reduce cloud-specific bugs

5.2 Cloud SDK Abstraction

The Problem: Applications often use cloud-specific SDKs directly:

// Tightly coupled to AWS
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client({ region: 'us-east-1' });
await s3.send(new PutObjectCommand({ Bucket, Key, Body }));

The Solution: Abstract storage operations behind an interface:

// Cloud-agnostic storage interface
interface ObjectStorage {
  put(bucket: string, key: string, data: Buffer): Promise<void>;
  get(bucket: string, key: string): Promise<Buffer>;
  delete(bucket: string, key: string): Promise<void>;
}

// Implementation provided at runtime based on configuration
const storage: ObjectStorage = createStorageClient(process.env.CLOUD_PROVIDER);

Libraries that help:

Apache Libcloud (Python) — Unified API for cloud services
Multi-Cloud SDK patterns — Build your own adapter pattern
Dapr — Portable runtime with pluggable components for state, pubsub, etc.

dapr-components.yaml
Dapr (Multi-Cloud)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
# Dapr provides cloud-agnostic building blocks
# Applications call Dapr APIs; Dapr handles cloud-specific integration
 
# State Store component - AWS DynamoDB
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  namespace: production
spec:
  type: state.aws.dynamodb
  version: v1
  metadata:
    - name: region
      value: "us-east-1"
    - name: table
      value: "app-state"
    - name: accessKey
      secretKeyRef:
        name: aws-credentials
        key: access-key
    - name: secretKey
      secretKeyRef:
        name: aws-credentials
        key: secret-key
 
---
# Same application code works with GCP Firestore
# by swapping the component configuration
 
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  namespace: production
spec:
  type: state.gcp.firestore
  version: v1
  metadata:
    - name: project_id
      value: "my-gcp-project"
    - name: type
      value: "service_account"
    - name: private_key_id
      secretKeyRef:
        name: gcp-credentials
        key: private-key-id
 
---
# Pub/Sub component - abstracted from cloud specifics
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
  namespace: production
spec:
  type: pubsub.kafka  # Or pubsub.aws.snssqs, pubsub.gcp.pubsub
  version: v1
  metadata:
    - name: brokers
      value: "kafka-cluster.production.svc:9092"
    - name: consumerGroup
      value: "order-service"
 
---
# Application code is cloud-agnostic
# Just calls Dapr sidecar HTTP/gRPC API
 
# curl http://localhost:3500/v1.0/state/statestore -X POST -d '[{"key":"id","value":"data"}]'
# curl http://localhost:3500/v1.0/publish/pubsub/orders -X POST -d '{"orderId":"123"}'

5.3 Database Portability Patterns

Challenge: Managed databases are powerful but non-portable.

Strategies:

Use Portable Database Engines
- PostgreSQL, MySQL work on all clouds
- Managed services (RDS, Cloud SQL, Azure Database) use same engine
- Application code unchanged; only connection string differs
Abstract Database Access
- Use ORMs (Prisma, SQLAlchemy, Hibernate) that abstract SQL dialects
- Avoid cloud-specific SQL extensions
Accept Strategic Lock-in
- Sometimes, DynamoDB or Spanner capabilities are worth lock-in
- Make conscious choices about what's portable vs. optimized
Event Sourcing / CQRS
- Store events in portable format (Kafka, PostgreSQL)
- Rebuild read models in any cloud from events

Interface Segregation

Summary: Choosing Your Abstraction Strategy

Abstraction layers are the tools that make multi-cloud manageable. Let's consolidate the key patterns:

Key Abstraction Patterns

•Kubernetes — Primary compute abstraction; workload definitions are portable, but infrastructure integration (storage, networking, identity) remains cloud-specific.
•Terraform/IaC — Provides consistent provisioning workflow and language across clouds; doesn't automatically make resources portable.
•Service Mesh — Abstracts networking, security, and observability; enables seamless cross-cloud service communication with mTLS.
•Application Patterns — Interface abstraction, Dapr, and portable database engines enable cloud-agnostic application code.
•Selective Abstraction — Abstract commodity services; accept lock-in for differentiated capabilities. This is the practical path.

The Abstraction Mindset:

Successful multi-cloud abstraction requires thinking in layers:

What MUST be portable? — Core business logic, critical data stores
What SHOULD be portable? — Commodity compute, object storage, basic networking
What CAN be cloud-specific? — ML platforms, specialized analytics, managed services that dramatically accelerate development

What's Next:

Page Complete