Topologia multi-nuvem

1) Quando a nuvem multi é justificada

• Confiabilidade/disponibilidade: áreas de falha independentes no nível dos provedores.
• Soberania/complacência: armazenamento/processamento por jurisdição (data residency).
• Gerenciamento de risco - redução de vendedor-lock, alavancagem de compra/preço.
• Geografia/performance: mais perto do usuário e das fontes de dados.
• Serviços especiais: acesso às melhores capacidades «nicho» de nuvens diferentes.

• Complexidade significativa de SDLC/observabilidade/operações.
• Aumento do custo egress e latência entre os provedores.
• O IAM/modelos de rede/quotas/limites diferentes → mais riscos operacionais.

2) Patternos topológicos

3) Camada de rede e rotação

3. 1 Entrada Global

GSLB/DNS ruling: latency-/health- based; TTL curtos para as janelas de migração.
Anycast + L7-proxy: um único IP, um roteiro sobre a saúde das regiões.
Políticas de jurisdição: geo-blocking/geo-pinning de tráfego.

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 Interconectividade

Canais privados/peering onde possível; senão, TLS+mTLS pela Internet.
Controle Egress: agregação/compressão, cachês/agregadores locais.
Redes como código: Terraform/Blueprint, políticas CIDR, rotas e passarelas egress.

4) Dados e consistência

4. 1 Modelos

A consistência global forte é raramente realista (latência/malha/custo).
Pratmatic eventual: CDC bidirecional (mudança data capture) com resolução de conflitos.
CRDT/Idempotidade: para contadores/redes/logs - estruturas de comutação.

4. 2 Patternes

Dual-write com outbox: gravação transacional do evento → corretor → replicação para a nuvem ao lado.
Read-local/Write-home: gravações em uma região/nuvem doméstica, leituras localmente (com versões e políticas stale).
Protecção split-brain: detecção de divergência, «compensação» (saga), arbitragem manual para invariantes em dinheiro.

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

4. 3 Armazenamento de objeto

Replicação asincrônica de baquetas, hashi/manifesto, deadup.
As políticas ILM (hot/warm/cold) são independentes por nuvens.
Regras de soberania: «PII não deixa UA/EEA» - valida como código.

5) Identidade, segredos e chaves

Federação de Identidade: IdP único, tokens de curta duração, OIDC-trust em pipas.
Segredos: KMS/HSM de cada nuvem + abstração de classe Vault; dual-key para rotações/mudanças.
PoLP/ABAC: direitos baseados em atributos (cloud, region, eng, data _ class).
Domínios criptos: diferentes chaves de raiz para jurisdições → crypto-erasure por área.

6) Ambiente executivo: clusters e bagunças

Multiclaster (K8s): um cluster por nuvem/região; controle fleet via GitOps (ArgoCD/Fleet).
Сервис-меш: mTLS, retries, circuit-breakers, failover policies cross-cluster.

• Serviços estáticos → por local de dados.
• API interativa em cada nuvem (Ativa/Ativa).
• Batch/ETL → janelas «verdes »/região barata (carbon/cost aware).

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) Observabilidade e SLO em multi-nuvem

Marcas múltiplas: «cloud», «region», «tenant», «data _ domain».
SLI/SLO per-nuvem e globalmente: «Disponível globalmente se as nuvens estiverem disponíveis».
Coleta de telemetria local + agregação com controle de egress.
Traçados: trace-id global, divulgação do contexto, semente tail-based por «cauda».
A vs B por endpoint/p99/erro-budget burn.

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

Um único diretório mono IaC: provedor de plug-ins/stacks, invariantes (tags, redes, criptografia).
GitOps: manifestos declaratórios, detecção draft, ambientes promocionais.
Testes de conformidade: API/eventos, Canaries para ambas as nuvens.
Lançamento-gate: bloco em caso de risco de perturbação do SLO em uma única nuvem (previsão burn rate), sem conformidade com a soberania.

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) Custo e carbono (FinOps/GreenOps)

Métricas unit: '$/req', '$/GB-egress', 'gCO₂e/req'.
Routing de custo/carbono para não-critical batch: relógios/regiões baratas/« verdes ».
Egress-kap: orçamento para tráfego entre os pagamentos; dinheiro/agregação/compressão/TTL.
RI/SP/Committed Use em cada nuvem + «camada elástica» em spot/preemptil.

10) Testes de feeds e exercícios

Game-days: «limpar a nuvem A», «abrandar o BD», «furar os limites de egress».
Cheques-ponto: RTO/RPO, tempo de convergência DNS, pulverização da bandeira de fique, comportamento do dinheiro.
Chaos-smook em lançamentos, a degradação das dependências não deve levar a uma cascata de retraias.

11) Segurança, privacidade, complacência

Zero-Trust: mTLS entre serviços/nuvens, assinatura de artefactos, SBOM.
DPA/soberania: diretórios de conjuntos de dados, regras de localização, Legal Hold acima do ILM.
Segredos e chaves: registro de rotações, playbooks compromise/kill-switch.
Webhooks e integração externa: assinatura, anti-replay, endpoint regionais.

12) Modelos de integração de dados/eventos

12. 1 Ponte bidirecional Kafka (ideia):

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

12. 2 Tabela de Outbox e retransmissão:

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

Em seguida, o conector lê o outbox e publica o evento para o corretor local + retransmissão.

12. 3 Estratégia de conflitos (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-pattern

«Arrastando tudo para duas nuvens». Dificuldade duplicada sem ganhar.
Transações intergradas sincronizadas no caminho quente.
Uma única chave de encriptação global para todas as nuvens/regiões.
Logs/trailers com PII sem camuflagem e sem regras de localização.
Nenhuma medição externa (a disponibilidade real é visível apenas pelo status do provedor).
Nenhum playbooks/exercício - DR. não funciona no momento X.
Cascata de retais com degradação de uma única nuvem (sem limitadores/shading/breakers).
Egress não contabilizado - contas inesperadas.

14) Folha de cheque do arquiteto

1. Os drivers multi-nuvens (SLO/DR./soberania/custo) foram formulados?
2. O pattern foi selecionado (AA/AP/Dr.-Only/Poly-Service) e o RTO/RPO foi registrado?
3. Plano de rede: GSLB/Anycast, health-amostras, egress-kap, canais privados?
4. Dados: CDC/CRDT/dual-write, regras de resolução de conflitos, outbox?
5. Soberania: mapa de dados/regiões, políticas como código e seus gates?
6. IAM/segredos: federação, tokens de curta duração, KMS de domínios?
7. Cluster/mesh: estratégia failover, limitadores/breakes/temporizadores?
8. Observabilidade: rótulos 'cloud/region', SLO per-nuvem e globalmente, sintético externo?
9. Diretório único, teste de conformidade, lançamento-gate?
10. FinOps/GreenOps: métricas unit, orçamento egress, janelas «verdes» batch?
11. Exercícios: game-days regulares, protocolos e retalhos?
12. Plano Exit: exportação de dados/formatos/prazos, segundo-fonte para serviços essenciais?

15) Mini-exemplos de configuração

15. 1 Política de instrução por jurisdição (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 Health-amostra para GSLB:

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

15. 3 Flagra Failover (pseudocode):

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

Conclusão

A nuvem multi é uma disciplina de engenharia, não um rótulo. Requer motivos claros, escolhas conscientes de topologia, trabalho elaborado com dados, automação forte e políticas rigorosas. Medindo riscos e custos, construindo redes e dados «por tutorial», treinando feedback e mantendo o curso simples, a plataforma multi-nuvem lhe dará sustentabilidade, flexibilidade e liberdade - sem surpresas nas contas e sem comprometimento na experiência do usuário.