08 - Multi-Cloud Platform Engineering: Portabilità e Vendor Lock-in

Multi-Cloud: Strategia e Realta

Il multi-cloud e la strategia di utilizzare servizi da due o più cloud provider (AWS, Azure, GCP) per distribuire i workload, ridurre il rischio di vendor lock-in e ottimizzare i costi. Per un platform team, progettare una IDP multi-cloud significa costruire abstrazioni che nascondano le differenze tra i provider, permettendo agli sviluppatori di deployare senza preoccuparsi del cloud sottostante.

Tuttavia, il multi-cloud non e una bacchetta magica. Introduce complessità significativa nella gestione dell'infrastruttura, nel networking, nella sicurezza e nel monitoring. In questo articolo analizzeremo quando il multi-cloud ha senso, quali pattern adottare e come mitigare il vendor lock-in senza cadere nella trappola della complessità eccessiva.

Strategie Multi-Cloud

Non esiste un'unica strategia multi-cloud. Le organizzazioni adottano approcci diversi in base alle proprie esigenze:

• Active-Active: workload distribuiti attivamente su più cloud provider. Massima resilienza ma massima complessità
• Active-Passive: un cloud provider primario con failover su un secondo provider. Buon bilanciamento tra resilienza e complessità
• Best-of-Breed: utilizzo del miglior servizio di ciascun provider (es. AWS per compute, GCP per ML, Azure per enterprise). Ottimizza le capability ma complica la governance
• Hybrid: combinazione di cloud pubblico e infrastruttura on-premise. Comune in settori regolamentati (finanza, sanita)

# Multi-cloud strategy: active-passive con failover
multi-cloud-architecture:
  primary: AWS (eu-west-1)
  secondary: GCP (europe-west1)
  strategy: active-passive

  workload-distribution:
    primary-aws:
      services:
        - all production workloads
        - primary databases (RDS PostgreSQL)
        - primary cache (ElastiCache Redis)
        - primary message queue (MSK Kafka)
      traffic: 100% (normal operations)

    secondary-gcp:
      services:
        - read replicas (Cloud SQL)
        - DR databases (standby)
        - static assets (Cloud CDN)
        - batch processing (BigQuery)
      traffic: 0% (failover only)

  failover:
    trigger: "Primary region unavailable for > 5 minutes"
    rto: "15 minutes"
    rpo: "5 minutes"
    steps:
      1: "DNS failover (Route53 health check)"
      2: "Promote GCP read replicas to primary"
      3: "Scale up GCP compute"
      4: "Verify service health"
      5: "Notify teams"

  data-replication:
    databases: "Async replication, 5-minute lag"
    object-storage: "Cross-cloud sync (rclone)"
    secrets: "Vault replication"
      

Kubernetes come Layer di Astrazione

Kubernetes e il layer di astrazione più efficace per la portabilita multi-cloud. Un'applicazione containerizzata che gira su Kubernetes può essere deployata su EKS (AWS), GKE (GCP), AKS (Azure) o qualsiasi cluster Kubernetes con modifiche minime.

Tuttavia, la portabilita non e automatica. Le aree dove la secificità del cloud emerge sono:

• Storage: StorageClass e PersistentVolume sono diversi per ogni provider
• Networking: LoadBalancer, Ingress Controller e DNS hanno implementazioni provider-specific
• IAM: IRSA (AWS), Workload Identity (GCP), Pod Identity (Azure) per l'autenticazione dei pod
• Managed services: database, cache e message queue managed sono il principale vettore di lock-in

Gestione Secrets Cross-Cloud

La gestione dei secrets in un ambiente multi-cloud e particolarmente critica. Ogni cloud provider ha il proprio servizio di secret management (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault), e gli sviluppatori non dovrebbero dover interagire con ciascuno separatamente.

HashiCorp Vault e la soluzione più adottata per centralizzare la gestione dei secrets in ambienti multi-cloud:

• Centralizzazione: un unico punto di gestione per tutti i secrets, indipendentemente dal cloud
• Dynamic secrets: generazione on-demand di credenziali temporanee (database, AWS IAM, certificates)
• Auto-rotation: rotazione automatica dei secrets senza downtime applicativo
• Audit: log completo di ogni accesso ai secrets per compliance

# Vault: configurazione multi-cloud secrets
vault:
  storage:
    type: raft
    ha_enabled: true
    nodes:
      - vault-0.vault.svc (primary)
      - vault-1.vault.svc (follower)
      - vault-2.vault.svc (follower)

  auth-methods:
    # AWS authentication
    aws:
      path: auth/aws
      config:
        access_key: ${VAULT_AWS_ACCESS_KEY}
        secret_key: ${VAULT_AWS_SECRET_KEY}
      roles:
        - name: eks-pods
          bound_iam_principal_arn: "arn:aws:iam::*:role/eks-pod-*"
          policies: [app-secrets]

    # GCP authentication
    gcp:
      path: auth/gcp
      config:
        credentials: ${VAULT_GCP_CREDENTIALS}
      roles:
        - name: gke-pods
          type: iam
          bound_service_accounts: ["*@project.iam.gserviceaccount.com"]
          policies: [app-secrets]

    # Kubernetes authentication (works on any cluster)
    kubernetes:
      path: auth/kubernetes
      roles:
        - name: app-role
          bound_service_account_names: ["app-sa"]
          bound_service_account_namespaces: ["*"]
          policies: [app-secrets]
          ttl: 1h

  secret-engines:
    - path: secret/data/apps
      type: kv-v2
      description: "Application secrets"

    - path: database/
      type: database
      description: "Dynamic database credentials"
      config:
        - name: checkout-db
          plugin: postgresql-database-plugin
          connection_url: "postgresql://{{username}}:{{password}}@checkout-db:5432/checkout"
      

Cost Optimization Multi-Cloud

Uno dei vantaggi dichiarati del multi-cloud e l'ottimizzazione dei costi attraverso la scelta del provider più economico per ogni workload. Nella pratica, questo richiede strumenti sofisticati di cost management:

• Cost visibility: dashboard unificata che mostra i costi per team, servizio e cloud provider
• Rightsizing: identificazione di risorse over-provisioned e raccomandazioni di ridimensionamento
• Reserved capacity: gestione di reserved instances, savings plans e committed use discounts
• Spot/Preemptible: utilizzo di istanze spot per workload tolleranti alle interruzioni
• Tagging policy: tag obbligatori per allocare i costi ai team responsabili

Service Mesh per Networking Cross-Cloud

Il service mesh e essenziale per il networking in ambienti multi-cloud. Istio, in particolare, supporta configurazioni multi-cluster che permettono ai servizi di comunicare trasparentemente attraverso cloud provider diversi:

• Multi-cluster mesh: un unico mesh che copre cluster su AWS, GCP e Azure
• Traffic routing: routing intelligente basato su latency, locality e health status
• Failover automatico: se un servizio su un cloud e degradato, il traffico viene reindirizzato
• mTLS cross-cloud: crittografia end-to-end anche per comunicazioni tra cloud diversi

# Istio: multi-cluster service mesh configuration
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: checkout-service-dr
spec:
  host: checkout-service.checkout.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
          - from: eu-west-1    # AWS primary
            to: europe-west1   # GCP failover
        distribute:
          - from: eu-west-1/*
            to:
              "eu-west-1/*": 90
              "europe-west1/*": 10