Esta semana em cloud (20–26/jul): ter duas regiões não é ter duas chances

TL;DR — A semana entregou seis peças independentes sobre a mesma dor: continuidade. Cloud Run ganhou failover regional automático, a CNCF publicou o padrão de banco multi-cluster no Kubernetes, a Microsoft contou como trocou o runtime de 60 mil apps sem downtime e Oracle e Equinix levaram a conversa para independência de provedor. O ponto que amarra tudo: redundância de dados não é redundância de controle — e é o plano de controle que decide se você tem mesmo duas chances.

Por várias semanas seguidas esta newsletter girou em torno do agente — do crachá que não prova confiança ao controle que desceu para a camada de dados. Entre 20 e 26 de julho, o agente seguiu rendendo volume: Claude Opus 5 chegou ao Microsoft Foundry, o Copilot Studio ganhou grounding com Azure AI Search e a CNCF discutiu platform engineering para a "empresa agêntica".

Só que, lidos juntos, os anúncios mais consequentes da semana não falam de agentes. Falam de continuidade — e chegaram de quatro fornecedores diferentes, em quatro camadas diferentes da pilha, sem combinar.

Por que multi-região no papel pode ser single-region na prática?

Porque redundância de dados e redundância de controle são coisas distintas, e quase todo mundo só compra a primeira.

A formulação mais afiada do problema não veio de um provedor, veio de uma análise da InfoQ sobre domínios de falha soberanos: um sistema pode ter data plane implantado em várias regiões e continuar funcionalmente single-region se o plano de controle estiver em uma região só. Configuração centralizada, gerenciador de segredos sem failover, orquestração de deploy amarrada a um endpoint regional — qualquer um desses transforma a segunda região em enfeite no diagrama. Pior: a falha é invisível até o dia do incidente, porque o tráfego normal nunca exercita esse caminho.

O contexto dá urgência ao ponto. A Forrester projeta para 2026 ao menos duas interrupções multi-dia em hyperscalers, à medida que a prioridade de investimento migra para infraestrutura de IA. Não é previsão exótica: é a leitura de que indisponibilidade deixou de ser risco e virou item de calendário.

Foi contra esse pano de fundo que a semana entregou peças concretas:

O que apareceu	Que camada da continuidade endereça	O que ainda fica com você
Readiness probes + service health no Cloud Run (Google Cloud)	Tráfego — detecção de falha regional e desvio automático em segundos, via serverless NEGs e load balancer global	O estado: RPO, replicação e residência da camada de dados
Bancos multi-cluster no Kubernetes (CNCF/Percona)	Estado — padrão 2+2+1, cinco votantes em três locais sobre a MCS API	Retryable writes na aplicação e a margem menor pós-failover
SnapScheduler no OKE (Oracle)	Recovery point — snapshot de PV como política declarativa, com tiers por label	Backup application-aware e DR de fato — snapshot não é nenhum dos dois
Shadow traffic em 60 mil apps (Microsoft)	Mudança — trocar runtime em produção sem expor o cliente ao caminho novo	Tempo: a migração levou dois anos, e isso é a notícia boa

Repare no eixo. Não é uma disputa de quem tem mais região; é a admissão de que continuidade se decide em quatro lugares diferentes, e que ter resolvido um deles não adianta nada se os outros três seguem manuais.

Failover automático resolve, ou só muda o lugar do problema?

Muda o lugar — e essa é a parte honesta que os anúncios costumam omitir.

O caso do banco multi-cluster é o mais didático. O padrão que a CNCF descreveu, com MongoDB e o Percona Operator, distribui cinco membros votantes em três locais no arranjo 2+2+1: perde-se uma região inteira e o quórum se mantém, sem intervenção manual. Excelente. Só que o texto é explícito sobre o preço: depois do failover você opera com redundância reduzida até reconstruir o local perdido. E há um pré-requisito que mora fora da infraestrutura — a aplicação precisa suportar retryable writes. Sem isso, o failover que o operador celebra no dashboard chega ao usuário como erro.

O mesmo padrão aparece no Cloud Run. Os readiness probes entregam health check por instância, e o service health agrega esse sinal por região, expondo-o via serverless NEGs — quando o serviço está atrás de um global external application load balancer (ou de um cross-regional internal ALB, para tráfego privado), a região não saudável sai da rotação sozinha. Não há custo adicional além do CPU e memória que as sondas consomem. Mas o mecanismo cuida do tráfego, não do dado: escolher entre Firestore, Spanner, Cloud SQL ou Cloud Storage segue sendo uma decisão de RPO e de residência que ninguém automatiza por você.

E o SnapScheduler fecha o raciocínio pelo lado do estado. Transformar snapshot de volume persistente em política nativa do Kubernetes — schedule por label, retenção configurável, tiers Gold/Silver/Bronze sem script manual — é ganho operacional real para workload stateful. Só que snapshot de volume não é backup application-aware nem DR. Ele garante recovery point governado; não garante consistência lógica da aplicação nem recuperação em outra região.

A peça mais instrutiva da semana, aliás, é a que menos parece anúncio: a Microsoft contou como migrou cerca de 60 mil Azure Functions Apps do runtime v1/v2 para o v4 isolated worker sem exigir ação dos clientes. A técnica é shadow traffic — rodar o runtime novo em paralelo, comparando 100% dos resultados sem expor o cliente ao caminho novo — combinada a rollout progressivo e reversível. Levou dois anos, sem regressão significativa de latência ou erro. A lição não é o número; é que mudança segura em produção é uma propriedade de arquitetura, não de janela de manutenção.

Testar se a sua arquitetura multi-região sobrevive à perda do plano de controle exige exercício, não diagrama. A gente conduz esse teste com o seu time.

Independência é o mesmo que redundância?

Não. E a semana trouxe dois textos que empurram a conversa exatamente para essa distinção.

A Oracle argumentou que resiliência exige independência operacional — controle, backbone e governança separados —, tratando concentração de risco em plataformas globais como uma ameaça de natureza diferente da falha técnica. Quando milhares de serviços dependem do mesmo fornecedor, a redundância geográfica dentro dele não cobre o modo de falha que importa. É um argumento de vendor, com a Oracle EU Sovereign Cloud como exemplo, e vale lê-lo com essa ressalva; mas o raciocínio se sustenta independentemente de quem o assina.

Do outro lado, a Equinix tratou do dilema entre soberania digital e expansão regional — e, embora o recorte do texto seja a APAC, a pergunta é a mesma que empresas brasileiras enfrentam ao crescer: como manter controle sobre o dado sem travar a operação em novos mercados. A resposta proposta passa por infraestrutura distribuída, escolha consciente de provedor e políticas explícitas de data residency, em vez de tratar compliance como cláusula contratual.

No plano técnico, a peça que materializa essa agenda é o Confidential Containers, que se tornou projeto incubado da CNCF. O CoCo protege dado em uso via Trusted Execution Environments, abstraindo hardware confiável em padrões nativos do Kubernetes. Para quem responde à LGPD e precisa rodar workload sensível em nuvem pública, ele fecha a última lacuna do trio: dado em repouso e em trânsito já tinham resposta madura; dado em uso, não. A graduação para incubação não significa "pronto para todo mundo" — significa que a governança do projeto amadureceu o suficiente para entrar em roadmap sério.

O que mais mereceu atenção

Fora do eixo de continuidade, seis movimentos que valem registro:

O OpenTelemetry se graduou na CNCF. Consolidação do padrão aberto de observabilidade, com ecossistema maduro em torno de Collector, Operator, Weaver e packaging, e foco seguinte em escala e novos sinais como profiling. Para quem constrói observabilidade self-hosted sem lock-in, a graduação é o argumento que faltava em conversa de comitê.
Azure Policy ganhou validação nativa com CEL e VAP. As regras passam a rodar dentro do próprio API Server via Validating Admission Policy, eliminando o round-trip para webhooks externos — menos latência em admission, fail-close nativo e CEL no lugar de Rego. Quem opera AKS com muitos clusters sente na operação.
Azure DDoS Protection ganhou custom policy em preview pública, com thresholds de mitigação ajustáveis por IP de frontend do Standard Load Balancer. Serve para reduzir falso positivo em aplicação de tráfego atípico — desde que você tenha baseline medido, e não chute.
ArgoCon Japan 2026 apontou os rumos do Argo CD 3.5 e do GitOps corporativo.
Azure VPN Gateway atingiu GA com IPv6, em configuração dual-stack nos SKUs de produção, reduzindo dependência de NAT em ambiente híbrido. Em paralelo, o Standard Service Endpoint entrou em preview público, integrando-se à família Private Link para conectar IaaS a PaaS com gestão centralizada.
No bloco de IA, o destaque estrutural não foi modelo: o goodput superando throughput como métrica de LLM serving e a depuração de 60% de GPUs ociosas em Kubernetes mostram que a conta da inferência agora se resolve em scheduling e rede, não em comprar mais acelerador.

O que isso muda para quem opera infra no Brasil?

Muda o que você deveria testar no próximo trimestre — e o teste é desconfortável de propósito.

A pergunta prática não é "temos multi-região?". É: se a região primária ficar inacessível agora, seu time consegue aplicar um deploy, girar um segredo e alterar uma configuração sem tocar nela? Se a resposta depender de um cofre, um registry, um repositório de estado do Terraform ou um pipeline que vive só lá, você tem redundância de dados com plano de controle único — exatamente o cenário que a análise da InfoQ descreve. Descobrir isso em exercício custa uma tarde; descobrir em incidente custa o SLA do ano.

O segundo ponto é de sequência. As ferramentas que a semana entregou são acumulativas, mas têm ordem de valor: detecção e desvio de tráfego (Cloud Run) só compensam depois que o estado tem plano (multi-cluster ou replicação gerenciada); snapshot governado (SnapScheduler) resolve recovery point, não recuperação regional; e shadow traffic é o padrão a copiar quando a mudança for arriscada demais para janela de manutenção. Nenhuma delas substitui a anterior.

Por fim, a leitura de soberania. No Brasil, a conversa tende a parar na região do datacenter — e essa é a parte fácil. O que a semana reforça é que independência se mede em custódia e em controle: onde vive o plano de controle, quem detém a chave, e quanto trabalho seria sair. É a mesma tese que sustentamos ao operar Kubernetes on-premises em infraestrutura estatal sem lock-in. Redundância é engenharia; independência é decisão de arquitetura — e ela não aparece na fatura, aparece no dia em que você precisa mudar de ideia.

Perguntas Frequentes

Ter workload em duas regiões já garante alta disponibilidade?
Não necessariamente. A análise da InfoQ sobre domínios de falha soberanos coloca o problema com precisão: um sistema pode ter data plane em várias regiões e continuar funcionalmente single-region se o plano de controle — armazenamento de configuração, gerenciador de segredos, orquestração de deploy — viver em uma região só. Se o operador não consegue aplicar uma mudança de configuração sem acessar a região que caiu, a redundância é ilusória. O teste que revela isso não é o diagrama, é o exercício prático de indisponibilidade.

O failover automático do Cloud Run substitui um plano de DR?
Não. Os readiness probes e o service health resolvem a detecção e o desvio de tráfego: o Cloud Run agrega a saúde das instâncias por região, expõe via serverless NEGs e, ligado a um global external application load balancer (ou a um cross-regional internal ALB, no caso de tráfego privado), tira a região não saudável da rotação em segundos, sem custo extra além do CPU e memória dos probes. O que ele não resolve é o estado: a camada de dados continua exigindo decisão própria de RPO, residência e replicação.

Qual o trade-off real de um banco multi-cluster no Kubernetes?
Redundância reduzida depois do failover. O padrão 2+2+1 descrito pela CNCF — MongoDB com Percona Operator sobre a MCS API — distribui cinco membros votantes em três locais, o que permite perder uma região inteira e manter quórum sem intervenção manual. Só que, sobrevivido o evento, você opera com margem menor até restaurar o local perdido. Há ainda um pré-requisito de aplicação frequentemente ignorado: retryable writes. Sem isso, o failover do banco vira erro visível para o usuário.

Snapshot automatizado conta como backup?
Não, e o próprio material da Oracle sobre o SnapScheduler no OKE é honesto quanto a isso. O operador open source da Backube transforma snapshot de volume persistente em política declarativa do Kubernetes, com schedule por label e retenção configurável — dá para oferecer tiers de proteção (Gold, Silver, Bronze) sem script manual. Mas snapshot de volume não é backup application-aware nem DR completo: ele garante recovery point governado, não consistência lógica da aplicação nem recuperação em outra região.

Independência de provedor e redundância são a mesma coisa?
Não, e a semana explicitou a diferença. Redundância protege contra falha técnica; independência protege contra risco sistêmico — concentração, decisão comercial, jurisdição. O argumento da Oracle é que controle, backbone e governança separados formam uma camada estratégica distinta da redundância geográfica. Para o Brasil, a leitura prática do texto da Equinix é direta: data residency e escolha consciente de provedor são decisões de arquitetura, não cláusula de contrato. Rodar em São Paulo não resolve se o plano de controle e a chave estão sob custódia única.

Fontes: