Nube híbrida: on-prem + cloud

1) Por qué un híbrido y cuándo está justificado

Impulsores: requisitos reguladores (data residency/PII), inversión on-prem existente, latencia a sistemas «propios», control de costos, acceso a servicios gestionados en la nube.
Compromisos: complejidad de redes y seguridad, duplicación de competencias, sincronización de datos y confecciones, riesgos operativos.

Motto: portable donde es crítico; cloud-native donde es rentable.

2) Modelos híbridos

Extensión on-prem: nube como extensión del centro de datos (nuevos microservicios/análisis, frentes).
Cloud-first con anclajes locales: núcleo en la nube, on-prem - sistemas de contabilidad/pasarelas de pago/almacenamiento PII.
Cloud-bursting: picos elásticos de carga en la nube (batch, promo-pics), volumen base - localmente.
DR to Cloud: reserva caliente/caliente en la nube para on-prem (RTO/RPO manejables).
Edge + Core: nodos PoP/edge más cercanos al usuario, datos raíz/ML - en la nube.

3) Red y conectividad

3. 1 Canales

Site-to-Site VPN (IPsec/SSL) - iniciar rápidamente, por encima de la latencia, jitter.
Líneas rectas (DC/ER/IC, MPLS) - SLA predecibles, por debajo de la latencia, más caro.
Dual-link + BGP - Tolerancia a fallas y control de enrutamiento.

3. 2 Direcciones y rutas

Circuito RFC1918 único sin intersecciones; Plan CIDR para los próximos años.
NAT-domes sólo en los límites; east-west sin NAT.
Segment/VRF para el aislamiento de entornos (dev/stage/prod), tenantes, proveedores.

3. 3 Políticas de tiempo y DNS

NTP único (reloj = destino para criptografía/firmas).
Split-horizon DNS: zonas interiores (svc. cluster. local, corp.local), externo - público.
GSLB basado en la salud para el tráfico entrante.

4) Identidad y acceso

Federación SSO: OIDC/SAML, IdP on-prem ↔ IdP en la nube; SCIM-providencia.
Roles basados en el principio de privilegio least; cuentas break-glass con MFA.
Identidad de máquina: SPIFFE/SPIRE o mesh-PKI para mTLS.
RBAC «de extremo a extremo»: Git/CI/CD → cluster/mesh → brokers/DB → logs.

5) Plataforma: Kubernetes + GitOps

5. 1 Capa única de ejecución

Clústeres on-prem y cloud con las mismas versiones/CRD.
GitOps (Argo CD/Flux): listas únicas/overlays, control de deriva, hilos promocionales.

5. 2 Servicio de Mesh

Istio/Linkerd: mTLS por defecto, equilibrio local-aware, failover entre clústeres.
Políticas L7 (JWT, headers, rate limits, retry/circuit/timeout) - en el código de manifiesto.

5. 3 Ejemplo (K8s topología & mesh)

yaml anti-affinity and distribution by zones on-prem cluster spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }
Istio DestinationRule: local cluster priority, then trafficPolicy cloud:
outlierDetection: { consecutive5xx: 5, interval: 5s, baseEjectionTime: 30s }

6) Datos y almacenamiento

6. 1 Bases

On-prem master, cloud read-replica (analítica/catálogos).
Cloud master + on-prem cache (baja latencia para integraciones locales).
Distribuido SQL/NoSQL (Cockroach/Cassandra) con quórums locales.
Replicación de registros/CDC (Debezium) entre contornos; la idempotencia de los manejadores.

6. 2 Objetos/Archivos/Bloques

S3-compatible (on-prem MinIO + cloud S3/GCS) con replicación/verificación; WORM para auditoría.
Backups: 3-2-1 (3 copias, 2 medios, 1 offsite), verificación de recuperación regular.

6. 3 Caché y colas

Redis/KeyDB del clúster per-site; caché global - sólo a través de eventos/TTL.
Kafka/Pulsar: MirrorMaker 2/replicator; la clave es el dedoup/idempotencia de los consumers.

7) Seguridad y cumplimiento (Fideicomiso cero)

mTLS en todas partes (mesh), TLS 1. 2 + en el perímetro; prohibición de canales no encriptados.
Secretos: HashiCorp Vault/ESO; tokens de vida corta; rotación automática.
KMS/HSM: claves segmentadas por jurisdicción/tenant; cripto-rotación en el horario.
Segmentación: NetworkPolicies, micro-segmentación (NSX/Calico), ZTNA para acceso de administración.
Registros: inmutable (Object Lock), 'trace _ id' de extremo a extremo, máscara PII/PAN.

8) Vigilancia, SLO y gestión de incidentes

OpenTelemetry SDK está en todas partes; Coleccionista sobre-prem y en la nube.
Tail-sampling: 100% ошибок и p99, labels `site=onprem|cloud`, `region`, `tenant`.
SLO y Error Budgets por lotes (ruta/tenant/proveedor/sitio); alertas por burn-rate.
Dashboards de extremo a extremo: RED/USE, mapas de dependencia, comparaciones canarias (antes/después de las migraciones).

9) CI/CD y confecciones

Registro único de artefactos (pull-through cache on-prem).
Flujo promocional: dev → stage (on-prem) → canary (cloud) → prod; o viceversa - dependiendo del objetivo.
Verificaciones: pruebas de contrato (OpenAPI/gRPC/CDC), análisis estático, linting IaC, escaneo de imágenes, gates SLO.

10) DR/BCP (plan de continuidad)

• Catálogos/lendings: RTO 5-15 min, RPO ≤ 5 min;
• Pagos/carteras: RTO ≤ 5 min, RPO ≈ 0-1 min (quórum/sincrono dentro del sitio).
• Runbook: cambiar GSLB/weights, levantar standby en el clúster, feature-flags «modo ligero».
• GameDays: trimestralmente: desconexión del sitio/canal, comprobación de RTO/RPO reales.

11) Costo y FinOps

El egreso entre on-prem y la nube es el principal caudal «oculto»; caché y reducir al mínimo las caminatas (SWR, edge).
Teging: 'service', 'env', 'site', 'tenant', 'cost _ center'.
Regla 80/20: transferimos/mantenemos el 20% del «núcleo crítico» portable, el resto es donde es más barato.
Downsampling métricas, retoques de registro «caliente/frío», presupuesto-aware sampling treasing.

12) Patrones de colocación workload's

13) Ejemplos de confecciones

13. 1 IPsec S2S (idea)

onprem ↔ cloud: IKEv2, AES-GCM, PFS group 14, rekey ≤ 1h, DPD 15s, SLA monitoring jitter/packet-loss

13. 2 Terraform (fragmento de etiquetas/etiquetas)

hcl resource "kubernetes_namespace" "payments" {
metadata {
name = "payments"
labels = {
"site"    = var. site    # onprem    cloud
"tenant"   = var. tenant
"cost_center" = var. cc
}
}
}

13. 3 Vault + ESO (el secreto de on-prem en el clúster de la nube)

yaml apiVersion: external-secrets. io/v1beta1 kind: ExternalSecret spec:
refreshInterval: 1h secretStoreRef: { kind: ClusterSecretStore, name: vault-store }
target: { name: psp-hmac, creationPolicy: Owner }
data:
- secretKey: hmac remoteRef: { key: kv/data/payments, property: HMAC_SECRET }

14) Antipattern

CIDR que se superponen → NAT-caos; primero el plan de direcciones, luego los canales.
Una caché global «compartida» con una fuerte consistencia → latencia y split-brain.
Retraídas sin idempotencia → cargos/pedidos dobles.
Una VPN «desnuda» sin mTLS/Zero Trust dentro es un movimiento lateral cuando se compromete.
Falta de ejercicios de RD: los planes no funcionan en la realidad.
La variedad de versiones de K8s/CRD/operadores → la imposibilidad de tener listas únicas.
Registros en formato libre sin 'trace _ id' y enmascaramiento - forensic no es posible.

15) Especificidad de iGaming/finanzas

Residencia de datos: PII/eventos de pago - en el circuito on-prem/regional; en la nube - agregados/anónimos.
PSP/KYC: proveedores múltiples; smart-routing de la nube a las puertas de enlace locales, fallback en la copia de seguridad; webhooks a través de un corredor con un dedoop.
«Caminos del dinero»: SLO individuales por encima del total; son obligatorias HMAC/mTLS, 'Retry-After', 'Idempotency-Key'.
Auditoría: almacenamiento de información WORM (Object Lock), registros de transacciones inmutables, escritura bidireccional (on-prem + cloud) para eventos críticos.
Jurisdicciones: segmentación de claves KMS/Vault per país/marca; geo-bloques en el perímetro.

16) Lista de comprobación prod

• El plan de direcciones, DNS, NTP son uno solo; canales S2S + líneas rectas con reserva (BGP).
• Identidad única (SSO/OIDC/SAML), MFA, privilegio least; SPIFFE/SPIRE para servicios.
• K8s en todos los sitios, GitOps, los mismos operadores/CRD; service mesh с mTLS и locality-aware LB.
• Datos: CDC, pruebas de consistencia, políticas de RPO/RTO, backup 3-2-1 y restore-drid regulares.
• Seguridad: Vault/ESO, Rotación, NetworkPolicies, ZTNA; los registros son inmutables.
• Observabilidad: OTel, tail-sampling, SLO/presupuestos por site/region/tenant; dashboards canarios.
• CI/CD: pruebas contractuales, linting IaC, escaneo de imágenes; release-gates por SLO.
• DR-runbooks, GameDays, RTO/RPO reales medidos; botones cutover/roll-back.
• FinOps: límites de egresos, etiquetas e informes, política de retiro de métricas/logs/tracks.
• iGaming-especificidad: residencia de datos, multi-PSP, auditoría WORM, SLO individuales para pagos.

17) TL; DR

Híbrido = plataforma de ejecución compartida (K8s + GitOps + mesh + OTel + Vault) en dos mundos: on-prem y cloud. Planifique su red e identidad, haga que los datos sean transferibles a través de CDC/idempotencia, delimite la seguridad a través de Zero Trust, mida la confiabilidad de SLO/Error Budgets y entrene regularmente a DR. Para iGaming, mantenga los datos y pagos en la jurisdicción, use multi-PSP smart-routing y auditoría inmutable