Topología multi-nube

1) Cuando la multi-nube está justificada

• Confiabilidad/disponibilidad: zonas de falla independientes a nivel de proveedor.
• Soberanía/cumplimiento: almacenamiento/procesamiento por jurisdicciones (residencia de datos).
• Gestión de riesgos: reducción del vendedor-locín, apalancamiento de compras/precios.
• Geografía/rendimiento: más cercano al usuario y a las fuentes de datos.
• Servicios especiales: acceso a las mejores capacidades de «nicho» de diferentes nubes.

• Complejidad sustancial de SDLC/observación/operaciones.
• Aumento del costo de egress y latencia entre los proveedores.
• Diferentes IAM/modelos de red/cuotas/límites → más riesgos operativos.

2) Patrones topológicos

3) Capa de red y enrutamiento

3. 1 Entrada global

GSLB/DNS-ruling: latency-/health--based; TTL cortas en las ventanas de migración.
Anycast + L7-proxy: IP única, enrutamiento de salud regional.
Políticas por jurisdicciones: geo-blocking/geo-pinning de tráfico.

python def pick_cluster(client, intent):
вход: ip, geo, tenant, feature allowed = filter_by_compliance(client. geo) # sovereignty healthy = [c for c in allowed if sdo (c). ok and slo(c). ok]
return argmin(healthy, key=lambda c: latency_estimate(client, c))

3. 2 Conectividad entre nubes

Canales privados/peering donde sea posible; de lo contrario, TLS + mTLS a través de Internet.
Control Egress: agregación/compresión, cachés/agregadores locales.
Redes como código: Terraform/Blueprints, políticas CIDR, rutas y gateways egress.

4) Datos y consistencia

4. 1 Modelos

La consistencia globalmente fuerte entre nubes rara vez es realista (latencia/cuadrícula/costo).
Pragmatic eventual: CDC bidireccional (change data capture) con resolución de conflictos.
CRDT/idempotencia: para contadores/redes/registros - estructuras conmutativas.

4. 2 Patrones

Dual-write c outbox: registro transaccional del evento → broker → replicación a la nube vecina.
Read-local/Write-home: las entradas están en la región/nube «home», las lecturas son locales (con versiones y políticas de stale).
Split-brain protección: niño divergente, «compensación» (saga), arbitraje manual para invariantes monetarios.

DB → Debezium/stream → Events(topic@vN) → Cross-cloud relay → Apply w/ resolver resolver: prefer_higher_version          prefer_home          business_rule()

4. 3 Almacenamiento de objetos

Replicación asíncrona de baquetas, hashi/manifiestos, dedoop.
Las políticas de ILM (hot/warm/cold) son independientes por nubes.
Reglas de soberanía: «PII no abandona la UA/AEE» - validado como código.

5) Identidad, secretos y claves

Federación de Identidad: IdP unificado, tokens de vida corta, OIDC-trust en pipelines.
Secretos: KMS/HSM de cada nube + abstracción Vault-class; dual-key para rotaciones/conmutaciones.
PoLP/ABAC: derechos basados en atributos (cloud, region, env, data_class).
Dominios Crypto: diferentes claves raíz para jurisdicciones → crypto-erasure por área.

6) Entorno ejecutivo: clústeres y meshi

Multiclaster (K8s): un clúster por nube/región; control fleet a través de GitOps (ArgoCD/Fleet).
Сервис-меш: mTLS, retries, circuit-breakers, failover policies cross-cluster.

• Servicios estáticos → por ubicación de datos.
• Las API interactivas → en cada nube (Active/Active).
• Batch/ETL → ventanas «verdes »/región barata (aware de carbono/costo).

rego package placement

allow[cloud] {
input. service. pii == false cloud:= input. clouds[_]
cloud. features. contains("cheap_gpu")
}

deny["PII outside allowed region"] {
input. service. pii == true not input. target_region in {"eu-central","eu-north","eu-west"}
}

7) Observabilidad y SLO en multi-nube

Etiquetas de varios almacenes: 'cloud', 'region', 'tenant', 'data _ domain'.
SLI/SLO per-cloud y globalmente: «disponible globalmente si hay ≥1 cloud disponible».
Recogida de telemetría: local + agregación con control de egresos.
Tracks: trace-id global, propagación de contexto, sampling tail-based por «colas».
Comparaciones de dashboards: A vs B per endpoint/p99/error-budget burn.

8) SDLC/IaC y «políticas como código»

Directorio mono único IaC: proveedor-módulos/stacks, invariantes (etiquetas, redes, cifrado).
GitOps: manifiestos declarativos, drift-detect, ambientes promocionales.
Pruebas de conformación: contratos API/eventos, Canarios en ambas nubes.
Release Gates: bloque en riesgo de violar el SLO en una sola nube (pronóstico de la tasa burn), en ausencia de conformidad con la soberanía.

yaml gate: multi-cloud-slo-and-compliance checks:
- slo_burn_rate(global) < 1. 0
- slo_burn_rate(cloud:A) < 2. 0
- compliance_rule("pii_in_region") == pass
- egress_forecast < budget on_fail: block_release

9) Costo y carbono (FinOps/GreenOps)

Métricas unitarias: '$/req', '$/GB-egress',' gCO₂e/req '.
Routing por valor/carbono para batch no crítico: barato/« verde »relojes/regiones.
Egress-cap: presupuesto para el tráfico interurbano; caché/agregación/compresión/TTL.
RI/SP/Uso combinado en cada nube + «capa elástica» en spot/preemptible.

10) Pruebas y ejercicios de falsificación

Días de juego: «apagar la nube A», «ralentizar la DB», «romper los límites del egreso».
Check points: RTO/RPO, tiempo de convergencia DNS, racat de flag ficha, comportamiento de caché.
Chaos-smoke en los lanzamientos: la degradación de las dependencias no debe conducir a una cascada de retraídos.

11) Seguridad, privacidad, cumplimiento

Zero-Trust: mTLS entre servicios/nubes, firma de artefactos, SBOM.
DPA/soberanía: directorios de conjuntos de datos, reglas de localización, Legal Hold sobre ILM.
Secretos y claves: registro de rotación, playbucks de compromiso/kill-switch.
Webhooks e integraciones externas: firma, anti-replay, endpoints regionales.

12) Plantillas de integración de datos/eventos

12. 1 Puente bidireccional Kafka (idea):

cloudA. topicX ⇄ relayA→B ⇄ cloudB. topicX cleanup. policy=compact,delete  key-based routing  idempotent producer

12. 2 Tabla de Outbox y retransmisión:

sql
-- outbox id uuid pk, aggregate_id, type, payload jsonb, version int, created_at timestamptz
-- transactional insertion with domain table change

A continuación, el conector lee outbox y publica el evento en el corredor local + retransmisión.

12. 3 Estrategia de conflicto (pseudo):

python def resolve(local, remote):
if local. version > remote. version: return local if remote. version > local. version: return remote equal versions: domain rules return business_tiebreak (local, remote)

13) Anti-patrones

«Arrastrando todo como está en dos nubes». Doble dificultad sin ganar.
Transacciones síncronas entre nubes en la ruta de acceso.
Clave de cifrado global única para todas las nubes/regiones.
Logs/tracks con PII sin enmascarar y sin reglas de localización.
No hay mediciones externas (la disponibilidad real sólo es visible a través de la página de estado del proveedor).
No hay libros de reproducción/enseñanzas - DR no funciona en el momento X.
Cascada de retraídos en la degradación de una sola nube (sin limitadores/shading/breakers).
Egresos no contabilizados - cuentas inesperadas.

14) Check-list del arquitecto

1. ¿Están formulados los controladores multi-nube (SLO/DR/soberanía/costo)?
2. ¿Ha seleccionado un patrón (AA/AP/DR-Only/Poly-Service) y ha fijado RTO/RPO?
3. Plan de red: GSLB/Anycast, muestras de salud, egress-cap, canales privados?
4. Datos: CDC/CRDT/dual-write, reglas de resolución de conflictos, outbox?
5. Soberanía: mapa de datos/regiones, ¿políticas como código y sus gates?
6. IAM/secretos: ¿federación, fichas de breve vida, KMS por dominios?
7. Cluster/mesh: ¿estrategia de failover, limites/breaks/timeouts?
8. Observabilidad: ¿etiquetas 'cloud/region', SLO per-cloud y globalmente, sintética externa?
9. SDLC/IaC/GitOps: ¿un solo directorio, pruebas de conformación, juegos de lanzamiento?
10. FinOps/GreenOps: unit-métricas, presupuesto egress, «verde» ventanas de batch?
11. Enseñanzas: ¿días de juego regulares, protocolos y retestas?
12. Plan de salida: exportar datos/formatos/plazos, second-source para servicios clave?

15) Mini ejemplos de configuraciones

15. 1 Política de enrutamiento por jurisdicción (pseudo-YAML):

yaml route:
pii:
allowed_regions: ["eu-central","eu-north","eu-west"]
deny_cross_cloud: false analytics:
allowed_regions: ["eu-","us-"]
prefer_low_carbon: true weights:
eu-central@cloudA: 60 eu-central@cloudB: 40

15. 2 Muestra de salud para GSLB:

http
GET /healthz
200 OK x-region: eu-central x-slo: ok    at-risk    breach

15. 3 Failover-ficha-bandera (pseudocódigo):

python if slo_at_risk("cloudA", "payments"):
route. weight["cloudA"] -= 20 route. weight["cloudB"] += 20 enable_stale_rates(ttl=1560)

Conclusión

La multi-nube es una disciplina de ingeniería, no una etiqueta. Requiere motivos claros, una elección consciente de la topología, un trabajo cuidadoso con los datos, una automatización fuerte y políticas estrictas. Si usted mide los riesgos y el costo, construir redes y datos «por tutorial», entrenar a los failover y mantener el curso en la simplicidad, la plataforma multi-nube le dará sostenibilidad, flexibilidad y libertad - sin sorpresas en las cuentas y sin comprometer la experiencia del usuario.