Diseño multinube AWS + Google Cloud: patrones, portabilidad y runbook

Esta lección junta todo en un diseño: una plataforma SaaS con web y APIs, microservicios en contenedores, procesos transaccionales y asíncronos, una base relacional y almacenamiento de documentos, operando 7x24, con recuperación ante la falla de un proveedor completo. No hay una sola respuesta correcta; hay decisiones explícitas, con su costo y su prueba.

Nube primaria y secundaria

Antes de dibujar, decide cuál es la primaria. Los criterios, en orden de peso habitual:

• Habilidades del equipo: la nube que tu equipo opera mejor a las 3 de la mañana.
• Servicios administrados que de verdad usas: si dependes de un servicio que solo existe en un proveedor, ese proveedor es primario para esa capacidad.
• Gravedad de los datos: donde viven hoy los terabytes, y donde están los sistemas que los consumen.
• Contratos: compromisos de gasto, descuentos y requisitos regulatorios de salida.
• Regiones cercanas a tus usuarios y a sus leyes de residencia de datos.

En América Latina, las regiones de cada proveedor son:

Un dilema de diseño: emparejar regiones en la misma área metropolitana (São Paulo con São Paulo, Querétaro con Querétaro) da poca latencia y un retraso de replicación bajo, pero comparte riesgos físicos y regulatorios de la ciudad. Emparejar ciudades distintas reduce ese riesgo compartido a cambio de más retraso. El proveedor protege de fallas del proveedor; la distancia protege de fallas de la geografía. Decide cuál de los dos te preocupa más.

Tres dominios de falla, un patrón por nivel

Cada nivel resuelve sus propias fallas. Si un pod que se cae termina en un failover entre proveedores, el diseño está mal escalonado. Las bases están en multirregión y multinube.

Un patrón por componente

Ejemplo con AWS como primaria. Los estados de la secundaria son: activa (atiende tráfico), tibia (desplegada a escala mínima), piloto encendido (datos al día, cómputo definido pero apagado) y solo respaldo.

Matriz de portabilidad con costo de salida

Cada componente cae en una de tres canastas. Portable: se lleva con cambios de configuración. Con equivalente: hay un servicio parecido del otro lado, pero hay que traducir y probar. Dependencia elegida: aceptas el amarre porque te da algo que vale más que la salida. La versión general está en portabilidad y lock-in; aquí va el par concreto:

Kubernetes solo no hace portable la solución

Un Deployment corre igual en EKS y en GKE. Lo que lo rodea, no:

• Identidad del pod: EKS Pod Identity o IRSA hacia roles de IAM; en GKE, Workload Identity Federation for GKE hacia permisos de Google.
• Entrada: anotaciones del AWS Load Balancer Controller contra clases de Gateway o Ingress de GKE.
• Almacenamiento: StorageClass con el driver de EBS contra el de Persistent Disk.
• Red: la VPC CNI da a cada pod una IP de la VPC; GKE usa rangos secundarios de la subred.
• Lo de afuera: secretos, DNS, certificados y, sobre todo, los datos.

Kubernetes te da un lenguaje común para describir cargas. Mantén una base común de manifiestos y una capa delgada por proveedor (overlays de Kustomize o valores de Helm), y despliega a las dos con el mismo pipeline. El escalado de cada lado está en contenedores a escala y en cómputo en Google Cloud.

La secuencia de failover entre proveedores

Cada paso deja evidencia. Sin evidencia no hay reconciliación ni postmortem honesto.

1. 1

   Detectar · automático

   Chequeos sintéticos externos y SLO del backend neutral fallan desde varias ubicaciones. Evidencia: alertas con hora y recorridos afectados.
2. 2

   Evaluar · humano con datos

   ¿Es todo el proveedor, una región o un servicio? ¿Cuánto lleva? Revisas AWS Health y el panel neutral. Evidencia: alcance escrito y retraso de replicación del momento.
3. 3

   Decidir y declarar · humano

   La persona con autoridad aplica el criterio escrito, por ejemplo: «más de 30 minutos sin el recorrido de pago y sin fecha de recuperación». Evidencia: declaración con hora, quién y por qué.
4. 4

   Proteger los datos y aislar · automático con aprobación

   Congelar escrituras, revocar credenciales de la base en AWS, escalar a cero los escritores, sacar los registros del primario. Evidencia: cada acción con hora y resultado.
5. 5

   Promover · automático

   Registrar el último punto aplicado, cortar la suscripción, ajustar secuencias, abrir escrituras en Cloud SQL. Evidencia: LSN, último latido y RPO real.
6. 6

   Redirigir el tráfico · automático

   Cambiar los registros en el DNS externo, escalar GKE y los workers, reproducir la outbox. Evidencia: tráfico creciente en Google y decreciente en AWS.
7. 7

   Validar · automático y humano

   Transacciones sintéticas de punta a punta, conteos por tabla, colas que se vacían, pagos que pasan. Evidencia: resultados de las pruebas.
8. 8

   Operar en la secundaria · humano

   Guardia en modo Google, cuotas vigiladas, comunicación a clientes, cambios congelados. Evidencia: SLO de la secundaria.
9. 9

   Failback · proyecto planeado

   Base nueva en AWS suscrita a Cloud SQL, reconciliación, switchover en ventana. Evidencia: conteos y sumas de control iguales antes de cambiar.

Los criterios de declaración, los roles y los simulacros están en runbooks y simulacros.

Niveles de RTO y RPO ante la pérdida de un proveedor

Estos valores son un ejemplo. Los objetivos ante la pérdida de un proveedor suelen ser más holgados que ante la pérdida de una región, porque el evento es más raro y el cambio, más caro:

Las piezas de este diseño están en conectar AWS y Google Cloud, replicar datos entre nubes y operación y resiliencia en Google Cloud. El cambio entre regiones dentro de AWS, en failover y failback.