Como mitigar quedas de serviço de fornecedores

Em 12 de junho, desenvolvedores em todo o mundo enfrentaram uma realidade frustrante: suas aplicações ficaram fora do ar. O Cloudflare Workers parou de responder. Clientes do Google Cloud experimentaram problemas com suas instâncias do Compute Engine tornando-se inacessíveis e Cloud Functions esgotando o tempo limite. Se você foi afetado, não estava sozinho — e não foi sua culpa.

Este incidente revelou um aspecto fundamental da infraestrutura moderna: as dependências ocultas que podem derrubar aplicações inteiras quando um único provedor interrompe o serviço. Como engenheiros, entendemos essa dor — todos já passamos por isso quando a infraestrutura falha. Então, por que tantas plataformas caíram enquanto outras com infraestrutura de ponta a ponta permaneceram operacionais? A diferença está na arquitetura de alta disponibilidade e na eliminação de pontos únicos de falha.

O que realmente aconteceu: o efeito cascata

Em 12 de junho, o sistema Service Control do Google Cloud teve uma falha crítica. O que começou como um único ponto de falha rapidamente demonstrou como a infraestrutura moderna se tornou interconectada.

A interrupção começou com a falha dos serviços principais do Google Cloud - Compute Engine, Cloud Functions, App Engine e Cloud Storage tornaram-se indisponíveis. Mas o impacto não parou por aí. Serviços que dependiam da infraestrutura do Google Cloud também foram interrompidos, criando um efeito cascata que afetou milhões de usuários finais em todo o mundo.

O impacto nos negócios foi significativo: plataformas de e-commerce experimentaram quedas dramáticas em transações bem-sucedidas, equipes de desenvolvimento perderam dias inteiros de trabalho, e serviços financeiros relataram milhões em negociações perdidas. O incidente durou mais de seis horas, afetando não apenas os clientes diretos do Google, mas também qualquer pessoa cujas aplicações dependiam de serviços que, por sua vez, dependiam da infraestrutura do Google Cloud.

Entendendo o desafio de arquitetura

Este incidente destacou um desafio fundamental na infraestrutura moderna: a complexidade das dependências em cadeia. Muitas plataformas construídas com as melhores intenções de engenharia se viram vulneráveis a falhas em cascata.

A realidade é que construir uma infraestrutura de escala global é um empreendimento complexo. Quando os provedores de cloud oferecem serviços maduros e testados, faz todo o sentido da engenharia aproveitá-los. O desafio surge quando essas dependências criam pontos únicos de falha que não são imediatamente óbvios.

O que testemunhamos foi um cenário clássico de falha em cascata. Quando o sistema Service Control do Google Cloud apresentou problemas, não afetou apenas os clientes diretos do Google Cloud. A falha se propagou por todas as plataformas que dependiam da infraestrutura do Google Cloud, criando um efeito dominó que atingiu milhões de usuários finais.

Não se trata de apontar o dedo para plataformas específicas — trata-se de entender um desafio sistêmico. Muitos serviços que parecem distribuídos e resilientes na verdade dependem de infraestrutura de cloud centralizada para funcionalidades críticas. Quando essa infraestrutura falha, mesmo as aplicações mais bem projetadas podem se tornar indisponíveis sem culpa de seus desenvolvedores.

A abordagem de alta disponibilidade que funcionou

Enquanto muitas plataformas trabalhavam para restaurar serviços afetados pela interrupção do Google Cloud, algumas infraestruturas permaneceram completamente operacionais durante todo o incidente. Isso não foi sorte — foi o resultado de princípios de arquitetura de alta disponibilidade aplicados em escala.

A Azion Web Platform manteve a continuidade do serviço porque nossa equipe havia feito uma escolha de arquitetura fundamental: possuir a infraestrutura de ponta a ponta. Essa abordagem elimina dependências externas que podem se tornar pontos únicos de falha.

Essa arquitetura requer investimento significativo em infraestrutura física em centenas de data centers em todo o mundo, bem como relacionamentos diretos com provedores de rede Tier 1, e a construção de toda stack de software, do roteamento à camada de aplicação. Significa criar competências de DNS, CDN, computação, armazenamento e IA sem depender de provedores de cloud externos.

Quando implementada corretamente, essa abordagem cria redundância resiliente. Em vez de depender de serviços externos que podem compartilhar a mesma infraestrutura subjacente, cada componente é projetado com múltiplas camadas de fallback. Quando o Service Control do Google falhou em 12 de junho, a Azion e algumas outras plataformas não experimentaram falhas em cascata porque não faziam parte da cadeia de dependência.

Desta vez a foi Cloudflare que deixou milhares de seus clientes indisponíveis por uma falha de terceiros, no entanto isso levanta uma questão importante: quantas plataformas sobreviveriam caso a AWS experimentasse problemas semelhantes? A resposta revela um desafio de arquitetura mais profundo sobre centralização e dependências de fornecedores.

O trade-off é complexidade e investimento, mas o resultado é uma infraestrutura que pode manter a continuidade do serviço mesmo quando os principais provedores de cloud experimentam interrupções significativas.

O vendor lock-in que ninguém discute

A dependência da cloud cria uma forma sutil, mas significativa, de lock-in em fornecedores que vai além das preocupações tradicionais com APIs. Quando, por exemplo, suas funções só podem ser implantadas através do sistema da Vercel, você não está apenas preso às APIs de um fornecedor. Você está preso às escolhas de arquitetura deles, às suas cadeias de dependência e aos seus modos de falha — incluindo dependência completa da infraestrutura AWS.

Isso cria um novo tipo de limitação que vai além das preocupações tradicionais sobre formatos proprietários ou compatibilidade de API. Você herda não apenas as limitações do fornecedor escolhido, mas todas as suas dependências subjacentes. Suas aplicações dependem da confiabilidade da infraestrutura de cloud, apesar de não desejar depender dessa infraestrutura.

A abordagem alternativa parte de infraestruturas distribuídas e padrões abertos que fornecem portabilidade genuína. As APIs WinterTC garantem que o código da aplicação permaneça portável entre diferentes provedores de infraestrutura. APIs compatíveis com OpenAI garantem que o código de inferência de IA possa ser executado em qualquer lugar que suporte a interface padrão. Runtimes JavaScript padrão significam que o código da aplicação não está vinculado a ambientes de execução proprietários. HTTP/3 e QUIC fornecem performance moderna sem dependências de protocolo específicas de fornecedor.

Quando as plataformas são construídas em padrões abertos, a migração torna-se um exercício técnico em vez de uma revisão de arquitetura. As aplicações podem ser movidas entre provedores exigindo pouca ou nenhuma reescrita de código. As equipes de desenvolvimento mantêm a vantagem nas negociações com fornecedores porque os custos de mudança permanecem gerenciáveis. Mais importante, você evita herdar as dependências de arquitetura e pontos únicos de falha.

Entendendo as dependências da sua arquitetura

Entender a resiliência da sua infraestrutura requer mais do que ler materiais de marketing ou diagramas de arquitetura. Exige análise das cadeias de dependência reais que determinam a disponibilidade da sua aplicação. A maioria das organizações descobre que sua arquitetura “multi-cloud” ou “distribuída” contém pontos únicos de falha ocultos que teriam causado interrupções em 12 de junho.

Para avaliar a verdadeira resiliência da sua infraestrutura, considere estas questões críticas:

• Quem controla os nameservers do seu domínio?
• Seu provedor tem verdadeira redundância de DNS?
• Sua plataforma roda em sua própria infraestrutura ou sobre provedores de cloud?
• Você está usando runtimes de padrão aberto?
• Você está usando APIs de padrão aberto?

A maioria das organizações descobre que sua infraestrutura contém muito mais pontos únicos de falha do que seus diagramas de arquitetura sugerem. As falhas em cascata de 12 de junho revelaram como essas dependências ocultas podem derrubar aplicações inteiras, mesmo quando a infraestrutura primária parece saudável.

A realidade multi-cloud que o marketing não discute

A indústria de cloud comercializou com sucesso o “multi-cloud” como uma solução para o aprisionamento a fornecedores e pontos únicos de falha. A realidade é mais complexa e frequentemente contraproducente. Usar AWS para computação, Google Cloud para análise de dados e Azure para serviços de IA não cria resiliência — cria complexidade com múltiplos pontos únicos de falha.

A verdadeira arquitetura resiliente requer uma abordagem fundamentalmente diferente. Em vez de acumular dependências em múltiplos provedores de cloud, significa reduzir completamente as dependências de provedores externos. Isso requer plataformas que possuam sua infraestrutura de ponta a ponta, desde os servidores físicos em data centers até a pilha de software que executa suas aplicações.

Quando as plataformas controlam toda a sua pilha de infraestrutura, elas podem fornecer capacidades genuínas de redundância e failover. Elas não são limitadas pelas decisões de arquitetura ou práticas operacionais dos provedores de cloud. Elas podem implementar protocolos de rede personalizados, projetar configurações de hardware especializadas e criar sistemas de software otimizados para seus casos de uso específicos, em vez de cargas de trabalho genéricas na cloud.

As implicações para os negócios vão além da disponibilidade e confiabilidade. Os provedores de cloud cobram margens significativas sobre os custos de infraestrutura subjacentes, particularmente para serviços premium como funções serverless e bancos de dados gerenciados. Quando as plataformas possuem sua infraestrutura, elas podem fornecer essas capacidades a custos dramaticamente mais baixos, mantendo características de performance mais altas.

A vantagem dos padrões abertos na prática

Aplicações web modernas devem ser construídas em padrões que forneçam portabilidade genuína entre plataformas. Isso não se trata apenas de evitar o aprisionamento a fornecedores — trata-se de garantir que suas aplicações possam evoluir conforme o cenário tecnológico muda.

WinterTC fornece um exemplo perfeito de como padrões abertos permitem inovação sem dependência de plataforma. Aplicações construídas utilizando as primitivas do WinterTC podem ser implantadas em qualquer plataforma que suporte o padrão, desde provedores de cloud tradicionais até plataformas de edge modernas.

Da mesma forma, plataformas que fornecem APIs compatíveis com OpenAI para inferência de IA permitem que as aplicações usem qualquer modelo que suporte a interface padrão. Seu código não precisa mudar quando você alterna entre diferentes provedores de IA ou implanta em diferentes infraestruturas. A camada de abstração fornecida pela API padrão garante que as decisões de infraestrutura permaneçam separadas da lógica da aplicação.

Runtimes JavaScript padrão oferecem outra vantagem crucial. Quando suas funções usam APIs JavaScript padrão e pacotes npm, elas podem ser executadas em qualquer plataforma que forneça um ambiente de runtime compatível. Você não fica preso a formatos de função proprietários ou APIs específicas de fornecedor que exigem reescritas de código para migração.

O que 12 de junho validou sobre a propriedade de infraestrutura

A interrupção de 12 de junho forneceu validação no mundo real de princípios arquitetura que vinham sendo debatidos em círculos de engenharia por anos. Quando provedores de cloud experimentam falhas no plano de controle, cada serviço que depende de sua infraestrutura herda essas falhas. Os efeitos em cascata podem ir muito além dos clientes diretos do provedor de cloud, afetando milhões de usuários finais que nunca tomaram uma decisão consciente de depender da confiabilidade do provedor.

Plataformas com propriedade de infraestrutura de ponta a ponta demonstraram um perfil de falha fundamentalmente diferente. Elas não experimentaram interrupções porque não faziam parte da cadeia de dependência de ninguém. Sua propriedade de infraestrutura se estende desde servidores físicos implantados em centenas de data centers em todo o mundo até relacionamentos diretos com provedores de rede Tier 1 e extensas parcerias de conectividade de última milha.

Essa propriedade de infraestrutura permite capacidades que arquiteturas compostas têm dificuldade em igualar. As aplicações podem ser executadas com zero cold starts porque a infraestrutura está sempre ativa, em vez de provisionada sob demanda. A performance torna-se previsível porque não há APIs ou serviços externos que possam introduzir picos de latência. Os custos tornam-se transparentes porque não há margens de provedor de cloud ou faturamento surpresa devido a picos de uso.

A escolha de possuir infraestrutura de ponta a ponta parecia cara e complexa quando os provedores de cloud ofereciam recursos aparentemente infinitos com modelos de preços simples. Os eventos de 12 de junho demonstraram que a complexidade sempre esteve lá — estava apenas escondida em cadeias de dependência que os usuários nunca entenderam completamente até que falhassem.

Entendendo seu caminho futuro adiante

Seja você avaliando alternativas para provedores de cloud ou buscando reduzir dependências de infraestrutura, o caminho adiante requer uma avaliação honesta da sua arquitetura atual e um entendimento claro das suas opções.

Comece mapeando suas dependências reais, não apenas as documentadas em seus diagramas de arquitetura. A maioria das aplicações depende de dezenas de serviços externos para tudo, desde autenticação até análises. Cada dependência representa um ponto potencial de falha que poderia afetar a disponibilidade da sua aplicação.

Considere os custos reais da sua arquitetura atual, incluindo não apenas as contas mensais dos provedores de cloud, mas também a sobrecarga operacional de gerenciar múltiplos relacionamentos com fornecedores, o tempo de engenharia gasto em integração e solução de problemas, e os custos de oportunidade do aprisionamento a fornecedores que impede você de adotar soluções melhores conforme elas se tornam disponíveis.

Avalie plataformas que priorizam independência de infraestrutura e padrões abertos. Implante aplicações de teste para entender as características de performance, a experiência de desenvolvimento e os requisitos operacionais de abordagens alternativas. Muitas organizações descobrem que plataformas com propriedade de infraestrutura fornecem melhor performance a custos mais baixos, reduzindo a complexidade da arquitetura.

A próxima grande interrupção de cloud é inevitável. Falhas no plano de controle irão cascatear através de serviços dependentes. Aplicações falharão de maneiras que surpreenderão seus operadores e frustrarão seus usuários. A questão é se você estará preparado com uma arquitetura que pode sobreviver a essas falhas ou se você estará explicando o tempo de inatividade para usuários e stakeholders.

Pronto para construir uma arquitetura resiliente?

Não espere pelo próximo 12 de junho para expor as vulnerabilidades da sua arquitetura.

Fale com nossos especialistas para construir aplicações que possam resistir a interrupções de provedores de cloud. Ajudaremos você a avaliar suas dependências atuais e projetar sistemas com resiliência genuína.

Fale com nossos especialistas ou crie sua conta gratuita na Azion para começar a construir aplicações independentes de infraestrutura hoje.

---

O que aconteceria com suas aplicações durante o próximo 12 de junho? Quantas dependências sua arquitetura realmente tem? O que seria necessário para alcançar uma verdadeira independência de infraestrutura? Estas não são questões hipotéticas — são exercícios de planejamento para as interrupções que certamente virão.