Líderes de pensamento
Comece a se Preparar Agora para a Próxima Interrupção de Nuvem

Incidentes de nuvem importantes como o desta semana da AWS são inevitáveis. Estes quatro métodos podem ajudar sua empresa a superar.
Com inúmeras horas de produtividade perdida, sistemas financeiros interrompidos para milhões de usuários, e potencialmente centenas de bilhões de dólares perdidos, a interrupção da AWS desta semana foi um dia terrível para equipes de TI globais. É claro, também foi a pior catástrofe de nuvem global desde a última… e até a próxima.
Seja você estiver na AWS, GCP, Azure, ou em qualquer outra plataforma, interrupções importantes são uma realidade da computação em nuvem. Então, o que sua empresa pode fazer para diminuir o impacto? Abaixo, eu oferecerei quatro etapas que sua equipe pode tomar imediatamente.
Traga seu ceticismo – e faça sua lição de casa.
Muitas vezes, as equipes irão atrair o desastre ao entrar em arranjos de nuvem supondo que as grandes corporações de nuvem são intrinsicamente confiáveis. Para ter certeza, as empresas mais confiáveis ganharam sua reputação por um motivo. Ao mesmo tempo, cada nuvem e hyperscaler oferece uma ampla gama de opções de infraestrutura – a AWS North America sozinha tem 31 Zonas de Disponibilidade e 31 Localizações de Rede de Borda – e algumas opções são muito mais confiáveis do que as outras.
De fato, a Região US-EAST-1 da AWS, a causa da interrupção desta semana, estava atrás de interrupções importantes em 2020, 2021 e 2023, e era amplamente conhecido em certos círculos de TI como a região menos confiável. Muitas empresas provavelmente entenderam a situação, mas tomaram um risco calculado, considerando o baixo custo e as ofertas abundantes da região. Mas, dado o escopo da interrupção, é impossível não considerar quantas empresas foram completamente pegos de surpresa – e teriam certamente optado por regiões mais confiáveis se estivessem cientes dos trade-offs. Eu pessoalmente conheci líderes de TI que escolheram mudar para outras regiões da AWS apenas após más experiências com a US-EAST-1 no passado.
A lição aqui é fazer sua lição de casa quando se trata de opções de infraestrutura de nuvem, independentemente da nuvem que você está trabalhando. Lugares para começar incluem ferramentas gratuitas como cloudprice, Cloudping, e as visualizações de incidentes históricos das ferramentas de Saúde de Serviço de Nuvem fornecidas pelos hyperscalers.
Escolha portátil em vez de nativo de nuvem.
Quando você está arquitetando configurações de nuvem, a rota mais simples é ir para o nativo de nuvem. Mas, embora seja conveniente selecionar aplicativos prontos construídos pela e para sua provedora de nuvem, essas opções nativas de nuvem o deixam mais exposto se sua nuvem for interrompida.
Para evitar essa camada adicional de dependência de nuvem, opte por produtos independentes e/ou de código aberto quando possível. Alguns exemplos de substituições incluem os abaixo:
|
Categoria |
Exemplo de Oferta Nativa |
Alternativas de Código Aberto Incluem… |
|
Autenticação & Identidade |
AWS Cognito |
Keycloak |
|
Pesquisa |
Azure Monitor |
Elasticsearch |
|
Bancos de Dados Relacionais |
Google Cloud SQL |
PostgreSQL |
|
Bancos de Dados NoSQL |
AWS DynamoDB |
MongoDB |
|
Orquestração de Contêineres |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Monitoramento & Observabilidade |
Google Cloud Monitoring |
Prometheus + Grafana |
|
Filas de Mensagens |
AWS SQS/SNS |
Apache Kafka |
|
Armazenamento de Objetos |
Azure Blob Storage |
MinIO |
|
Gateway de API |
Google Cloud API Gateway |
Kong |
Para ter certeza, construir mais de sua pilha de nuvem do zero significa mais trabalho para suas equipes. No entanto, em minha experiência, uma vez que você tem a infraestrutura em execução, há pouca ou nenhuma diferença entre adicionar carga de trabalho a uma infraestrutura caseira estabelecida ou operar em uma nuvem nativa. E os benefícios em termos de resiliência – não mencionando a redução de bloqueio de nuvem – tornam opções independentes altamente valiosas.
Engenheirie para falha.
Dado que falhas de nuvem acontecerão, certifique-se de projetar seus produtos com falha de nuvem em mente. Um exemplo para olhar é o Datadog: em um incidente de 2023, a empresa perdeu repentinamente o acesso a mais da metade de seus nós Kubernetes em produção e completamente redesenhou sua abordagem de desastre em resposta. As mudanças incluíram remover gargalos arquitetônicos e abordar dívida técnica para que falhas parciais não se propagassem pelo sistema, melhorar a ingestão e armazenamento de dados para maior disponibilidade de dados durante interrupções, e construir sistemas para se recuperar automaticamente em escala. Um ótimo lugar para começar em sua jornada é seguir a recomendação do Datadog para “começar com o que é importante para o usuário final” e construir dispositivos de segurança para proteger o que mais importa.
Execute em pelo menos duas nuvens.
É claro, a melhor maneira de não ser refém de falhas de nuvem é a redundância multicloud. Alcançar verdadeira fluidez multicloud é uma grande empreitada para muitas empresas, desde que é extremamente difícil traduzir infraestrutura de uma nuvem para outra. Mas construir infraestrutura em apenas duas nuvens é um lugar forte – e frequentemente viável – para começar. Fundamental para tornar isso funcionar é ter uma equipe no lugar com um especialista em cada uma das nuvens em que você está executando.
Para ter certeza, nada pode proteger completamente as empresas do impacto de uma interrupção maciça como a que vimos esta semana. Mas com a devida diligência, uma abordagem portátil de nuvem, engenharia para falha e usando “dual-cloud” como um degrau para verdadeira multicloud, as empresas podem ser muito mais ágeis quando o próximo (e infelizmente inevitável) incidente de nuvem importante ocorrer.










