Estrategias Multi-Cloud

Overview

Multi-cloud es el uso deliberado de servicios de dos o mas proveedores cloud para ejecutar las cargas de trabajo de una organizacion. A diferencia del cloud hibrido (on-prem + cloud), multi-cloud significa AWS, Azure y/o GCP operando juntos. Las motivaciones incluyen evitar vendor lock-in, acceder a servicios best-of-breed, cumplir requerimientos regulatorios de residencia de datos y mejorar resiliencia. Sin embargo, multi-cloud aumenta considerablemente la complejidad operacional, costo y requerimientos de skills. No deberia ser el default.

When to Use

• For alternatives, see Complete Guide to GitOps in Production.

• Un solo proveedor no puede cumplir todos los requerimientos regulatorios o de residencia de datos

• Necesitas servicios best-of-breed (ej. BigQuery para analytics, AWS para compute)

• La continuidad de negocio demanda tolerancia a fallos a nivel de proveedor

• Has adquirido companias corriendo en clouds diferentes y la consolidacion no es factible

• El poder de negociacion con vendors es una prioridad estrategica

When NOT to Use

• Eres una startup o equipo pequeno — la complejidad overhead matara la velocidad
• Tu objetivo principal es ahorro de costos — transferencia de datos y overhead operacional usualmente hacen multi-cloud mas caro
• No has agotado opciones de resiliencia single-cloud (multi-region, multi-AZ)
• Tu equipo carece de expertise incluso en un proveedor cloud
• Lo estas haciendo porque “suena bien en un pitch deck”

Estrategias de Placement de Cargas

Estrategia	Descripcion	Ejemplo
Best-of-breed	Usar cada cloud por sus fortalezas	ML training en GCP (TPU), produccion en AWS
Failover	Primario en uno, DR en otro	Produccion en AWS us-east-1, DR en Azure East US
Split funcional	Diferentes cargas en diferentes clouds	Pagos en AWS, analytics en BigQuery
Split regional	Geografia dicta proveedor	Cargas EU en Azure (GDPR), APAC en AWS
Portabilidad completa	Misma carga desplegable en cualquier lado	Kubernetes multi-cloud

El Problema de la Gravedad de Datos

Los datos tienen gravedad: cuantos mas datos tienes en un proveedor, mas dificil es moverlos o replicarlos.

Ubicacion de datos	Implicacion
Base de datos primaria en AWS	Queries de analytics desde GCP pagan costos de egress
Blob storage en Azure	ML training en GCP requiere migracion de datos
Replicacion multi-master	Resolucion de conflictos, latencia, trade-offs de consistencia

Mitigacion:

• Usar formatos de datos cloud-agnostic (Parquet, ORC, Delta Lake)
• Replicar datasets criticos entre proveedores
• Colocar compute cerca de datos; no mover datos al compute

Portabilidad vs Optimizacion

Enfoque	Portabilidad	Optimizacion	Complejidad
Kubernetes en todas partes	Alta	Media	Media
Cloud-native por proveedor	Baja	Alta	Alta
Capa de abstraccion (Crossplane, Terraform)	Media	Media	Media
Serverless (Lambda + Functions + Cloud Functions)	Baja	Alta	Muy alta

Terraform para Multi-Cloud

# Abstract cloud provider via workspaces
variable "cloud_provider" {
  description = "aws, azure, o gcp"
}

module "compute" {
  source = "./modules/${var.cloud_provider}/compute"
  instance_type = var.instance_type
  region        = var.region
}

# Misma interfaz, diferente implementacion por proveedor

Networking e Identidad

Desafio	Solucion
Conectividad cross-cloud	VPN, Direct Connect + ExpressRoute, o Aviatrix/Alkira
Federacion de identidad	Okta/ADFS con SAML/OIDC a todos los proveedores
Gestion de secretos	HashiCorp Vault o soluciones cloud-agnostic
DNS	Route 53 / Cloudflare con health checks para failover

Common Mistakes

• Comenzar multi-cloud antes de madurez single-cloud — domina un proveedor primero
• Subestimar costos de transferencia de datos — egress cross-cloud puede exceder costos de compute
• Postura de seguridad inconsistente — cada proveedor tiene diferentes modelos IAM; unificar con policy-as-code
• Sin single pane of glass — equipos de ops necesitan observabilidad unificada entre clouds
• Tratar todos los clouds igual — no lo son. Cada uno tiene diferentes primitivas, limites y modos de fallo.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Temas Avanzados

Escenario: Arquitectura Multi-Cloud Activa-Activa

Sistema: Plataforma SaaS, 99.99% disponibilidad
Clouds: AWS (us-east, eu-west) + GCP (asia-southeast)
Estrategia: Active-active con DNS failover

Topologia:
  Route53 (DNS) -> Geo-routing
    US/EU users -> AWS (EKS + RDS)
    APAC users -> GCP (GKE + Cloud SQL)

  Latencia: < 50ms para cada region
  Failover: Route53 health checks -> reroute en 60s

Servicios equivalentes:
  | Capa | AWS | GCP |
  |------|-----|-----|
  | Compute | EKS | GKE |
  | DB (relacional) | RDS PostgreSQL | Cloud SQL PostgreSQL |
  | Cache | ElastiCache Redis | Memorystore Redis |
  | Storage | S3 | Cloud Storage |
  | CDN | CloudFront | Cloud CDN |
  | Queue | SQS | Pub/Sub |
  | Search | OpenSearch | Cloud Search |

Replicacion de datos:
  PostgreSQL: replicacion logica cross-cloud
    AWS RDS (primary) -> GCP Cloud SQL (replica)
    Direccion: us-east -> asia-southeast
    Lag: < 5 segundos (aceptable para reads)

  Redis: replicacion async con Redis Sentinel
    Cada cloud tiene su propio cluster
    Sincronizacion via application-level cache invalidation

  S3 -> Cloud Storage: replicacion via gsutil o S3 Transfer
    Para assets estaticos y backups

Abstraccion de infraestructura (Terraform):
  module "app" {
    source = "./modules/app"
    cloud = var.cloud_provider
    region = var.region
    instance_count = 3
  }
  // Modulos cloud-agnostic con providers condicionales
  // Misma logica, diferentes recursos por cloud

CI/CD unificado:
  GitHub Actions -> build container -> push a ambos registries
  Deploy: ArgoCD en EKS y GKE simultaneamente
  Rollout: canary 5% -> 25% -> 100% en cada cloud

Desafios operativos:
  | Desafio | Mitigacion |
  |----------|------------|
  | IAM diferente por cloud | SPIFFE/SPIR para identidad federada |
  | Networking cross-cloud | Transit Gateway + VPC Peering |
  | Costos duplicados | FinOps dashboard unificado |
  | Consistencia de datos | Replicacion logica + reconciliacion |
  | Compliance cross-region | Data residency por region |

Lecciones:
  - Active-active es caro pero da 99.99%+
  - La abstraccion de infraestructura (Terraform) es obligatoria
  - La replicacion cross-cloud agrega latencia y costo
  - IAM federada (SPIFFE) simplifica auth cross-cloud
  - Monitorea costos de ambos clouds en un solo dashboard

Como manejo el data residency en multi-cloud?

Usa geo-routing en DNS para enviar usuarios a la region mas cercana. Almacena datos personales en la region del usuario (GDPR: datos EU en region EU). Replica solo datos no-sensibles cross-region. Para datos sensibles, usa encryption con KMS region-specific. Documenta el flujo de datos para auditorias de compliance.

End of document. Review and update quarterly.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de cloud y vendor-lock-in para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica estrategias multi-cloud cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.