Nuvem híbrida: on-prem + cloud

1) Por que um híbrido e quando isso é justificado

Drivers: requisitos de reguladores (data residency/PII), investimentos on-prem existentes, latency para sistemas «próprios», controle de custo, acesso a serviços de nuvem administrados.
Compromissos: complexidade de redes e segurança, duplicação de competências, sincronização de dados e configs, riscos operacionais.

Motto: portável onde é crítico; cloud-native onde é benéfico.

2) Modelos de híbrido

On-prem extensão: nuvem como extensão de centro de dados (novos microsserviços/analistas, frentes).
Cloud-first com âncoras locais: núcleo na nuvem, on-prem - sistemas de contabilidade/gateway de pagamento/armazenamento PII.
Cloud-bursting: picos elásticos de carga na nuvem (batch, pró-picos), volume básico - local.
Dr. to Cloud: reserva quente/quente na nuvem para on-prem (RTO/RPO controlável).
Edge + Core: PoP/edge-nódulos mais próximos do usuário, dados de raiz/ML na nuvem.

3) Rede e conectividade

3. 1 Canais

Site-to-Site VPN (IPsec/SSL) - iniciar rapidamente, mais latência, jitter.
Linhas Retas (DC/ER/IC, MPLS) - SLA previsível, menor atraso, mais caro.
Dual-link + BGP - resistência a falhas e controle de rotação.

3. 2 Direções e rotas

Esquema RFC1918 único sem interseções; O plano CIDR está anos adiante.
NAT-domes apenas nas fronteiras; east-west sem NAT.
Segment/ERRF para isolar ambientes (dave/estágio/prod), tenentes, provedores.

3. 3 Políticas de tempo e DNS

Um NTP (relógio = destino para criptografia/assinaturas).
Split-horizonte DNS: zonas internas (svc. cluster. local, corp.local), externo - público.
Health-based GSLB para tráfego de entrada.

4) Identidade e acesso

Federação SSO: OIDC/SAML, on-prem IdP ↔ IdP na nuvem; Mantimentos SCIM.
Papéis least privege; as contas break-glass com a MFA.
Identidade de máquina: SPIFFE/SPIRE ou mesh-PKI para mTLS.
O RBAC é «passível»: Git/CI/CD → cluster/mesh → corretores/BD → logs.

5) Plataforma: Kubernetes + GitOps

5. 1 Camada única de execução

Cluster on-prem e cloud com versões idênticas/CRD.
GitOps (Argo CD/Flux): lista/overlay unificada, controle à deriva, fluxo promocional.

5. 2 Serviços-mesh

Istio/Linkerd: mTLS padrão, balanceamento locality-aware, failover mage-cluster.
Políticas L7 (JWT, headers, rate limits, retry/circuito/timeout) - no código de manifestos.

5. 3 Exemplo (K8s topology & 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) Dados e armazenamento

6. 1 Bases

On-prem master, cloud read-replica (analista/catálogo).
Cloud master + on-prem cache (baixa latência para integrações locais).
Distribuído SQL/NoSQL (Cockroach/Cassandra) com quórum local.
CDC/logo-replicação (Debezium) entre os circuitos; Idempotação dos processadores.

6. 2 Objetos/arquivos/blocos

Estores S3 compatíveis (on-prem MinIO + cloud S3/GCS) com replicação/versão; WORM para auditoria.
Bacapes: 3-2-1 (3 cópias, 2 mídias, 1 offsite), verificação regular de recuperação.

6. 3 Cash e filas

Redis/KeyDB do cluster per-site; O armazenamento global é apenas através de eventos/TTL.
Kafka/Pulsar: MirrorMaker 2/replicator; a chave é a dedução/idempotidade dos conceituadores.

7) Segurança e Conformidade (Zero Trust)

mTLS em todo o lado (mesh), TLS 1. 2 + no perímetro; a proibição de canais não criptografados.
Segredos: HashiCorp Vault/ESO; tokens curtos; Roteiro automático.
KMS/HSM: as chaves são segmentadas per jurisdição/tenante; Rotativo cripto agendado.
Segmentação: NetworkPolicies, micro-segmentação (NSX/Calico), ZTNA para acesso admin.
Registros: imutáveis (Object Lock), «trace _ id», camuflagem PII/PAN.

8) Observabilidade, SLO e gerenciamento de incidentes

OpenTelemetry SDK em todos os lugares; Colector em on-prem e na nuvem.
Tail-sampling: 100% ошибок и p99, labels `site=onprem|cloud`, `region`, `tenant`.
SLO e Erro Budets por corte (rota/tenante/provedor/site); alertas de burn-rate.
Dashboards: RED/USE, mapas de dependências, comparações de canários (antes/depois das migrações).

9) CI/CD e configs

Um único artefato registry (pull-through cachê em on-prem).
Fluxo promocional: dave → estágio (on-prem) → canary (cloud) → prod; ou vice-versa, dependendo do objetivo.
Testes de contrato (OpenAPI/gRPC/CDC), análise estática, linting IaC, scan de imagem, gates SLO.

10) DR./BCP (plano de continuidade)

• diretórios/lendagens: RTO 5-15 min, RPO ≤ 5 min;
• pagamentos/carteiras: RTO ≤ 5 min, RPO ≈ 0-1 min (quórum/sincronia dentro do local).
• Runbook: Alterna GSLB/weights, alça standby no cluster, função-flags «Modo facilitado».
• GameDays: trimestralmente - desativação de local/canal, verificação de RTO/RPO real.

11) Custo e FinOps

Egress entre o on-prem e a nuvem - principal consumo «oculto»; Acorde e reduza ao mínimo as caminhadas (SWR, edge).
Marcas de formatação: 'service', 'eng', 'site', 'tenant', 'cost _ center'.
Regra 80/20: Suportamos/mantemos portáveis 20% do «núcleo crítico», o resto é onde é mais barato.
Downsampling métricas, reticências de logs «quente/frio», orçamento-aware sampling trailing.

12) Pattern de acomodação workload 'ov

13) Exemplos de configs

13. 1 IPsec S2S (ideia)

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

13. 2 Terraform (fragmentos de marcas/editoras)

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 (segredo de on-prem para cluster de nuvem)

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 → caos NAT que se cruzam; Primeiro o plano direcionado, depois os canais.
Um cofre global «compartilhado» com forte consistência → latência e split-brain.
Retraias sem idempotação → duplos débitos/pedidos.
«Nu» VPN sem mTLS/Zero Trust dentro - movement lateral em comprometimento.
Falta de ensinamentos Dr. Os planos não funcionam na realidade.
As versões heterodoxas do K8s/CRD/operadoras → a impossibilidade de uma única lista.
Logs em formato livre sem 'trace _ id' e 'camuflagem' não podem ser forensados.

15) Especificidades do iGaming/Finanças

Data residency: PII/eventos de pagamento - no circuito on-prem/regional; na nuvem, máquinas/anónimo.
PSP/KYC: provedores multi; smart-routing de nuvem para gateways locais, fallback para reserva; webhooks por meio de um corretor.
«Caminhos do dinheiro»: SLO individuais acima do comum; são obrigatórios HMAC/mTLS, «Retry-After», «Idempotency-Key».
Auditoria: Armazenamento WORM, registros de transações imutáveis, gravação bilateral (on-prem + cloud) para eventos críticos.
Jurisdição: segmentação de chaves KMS/Vault por país/marca; Blocos geo no perímetro.

16) Folha de cheque pró-prontidão

• Plano de endereço, DNS, NTP, um só; canais S2S + linhas retas com reserva (BGP).
• Identidade unificada (SSO/OIDC/SAML), MFA, least privegue; SPIFFE/SPIRE para serviços.
• K8s em todos os locais, GitOps, operadores idênticos/CRD; service mesh с mTLS и locality-aware LB.
• Dados: CDC, testes de consistência, políticas RPO/RTO, bacap 3-2-1 e regulares restore.
• Segurança: Vault/ESO, rotação, NetworkPolicies, ZTNA; revistas imutáveis.
• Observabilidade: OTel, tail-sampling, SLO/orçamentos em site/region/tenant; dashboards de canhão.
• CI/CD: Teste de contrato, linting IaC, scan de imagens; release-gates por SLO.
• Dr.-runbooks, GameDays, RTO real medido/RPO; botões cutover/roll-back.
• FinOps: limites egress, tags e relatórios, política de retencagem de métricas/logs/trailers.
• iGaming-especificidades: data residency, multi-PSP, auditoria WORM, SLO individuais para pagamentos.

17) TL; DR

Híbrido = plataforma de execução compartilhada (K8s + GitOps + mesh + OTel + Vault) em dois mundos: on-prem e cloud. Planeje a rede e a identidade, torne os dados portáveis via CDC/Idempotidade, divida a segurança pelo Zero Trust, mede a confiabilidade do SLO/Erro Budets e treine regularmente o DR. Para iGaming, mantenha os dados e pagamentos na jurisdição, use o multi-PSP smart-routing e uma auditoria imutável.