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

Incidentes de nuvem importantes, como o que ocorreu esta semana na AWS, são inevitáveis. Quatro métodos podem ajudar sua empresa a atravessar essa situação.
Com incontáveis 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 esta semana foi um dia terrível para equipes de TI globais. É claro que 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 amenizar o impacto? Abaixo, oferecerei quatro passos que sua equipe pode tomar imediatamente.
Traga seu ceticismo – e faça sua lição de casa.
Muitas vezes, as equipes se deparam com desastres 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. No entanto, 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, já havia causado grandes interrupções em 2020, 2021 e 2023, e era conhecida 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, dado o baixo custo e as ofertas abundantes da região. No entanto, diante do alcance da interrupção, é impossível não considerar quantas empresas foram pegos completamente de surpresa – e teriam certamente optado por regiões mais confiáveis se tivessem conhecimento das compensações. 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 ao lidar com opções de infraestrutura de nuvem, independentemente da nuvem que você está trabalhando. Locais 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. No entanto, embora seja conveniente selecionar aplicativos prontos para uso, 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 seguintes:
|
Categoria |
Exemplo de Oferta Nativa |
Alternativas de Código Aberto Incluem… |
|
Autenticação e 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 e 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 da sua pilha de nuvem do zero significa mais trabalho para suas equipes. No entanto, na minha experiência, uma vez que você tem a infraestrutura funcionando, há pouca ou nenhuma diferença entre adicionar carga de trabalho a uma infraestrutura caseira estabelecida ou operar em uma nativa de nuvem. E os benefícios em termos de resiliência – não mencionando a redução da dependência de nuvem – tornam as opções independentes altamente valiosas.
Projetar para falha.
Dado que falhas de nuvem ocorrerão, certifique-se de projetar seus produtos com falha de nuvem em mente. Um exemplo a considerar é o Datadog: em um incidente de 2023, a empresa perdeu abruptamente o acesso a mais da metade de seus nós Kubernetes em produção e redesenhou completamente 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 uma 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 medidas de segurança para proteger o que é mais importante.
Execute em pelo menos duas nuvens.
É claro que a melhor maneira de não ser refém de falhas de nuvem é a redundância multicloud. Alcançar uma verdadeira fluidez multicloud é uma grande tarefa para muitas empresas, pois é extremamente difícil traduzir infraestrutura de uma nuvem para outra. No entanto, construir infraestrutura em apenas duas nuvens é um ponto de partida forte – e frequentemente realizável. Crítico 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. No entanto, com a devida diligência, uma abordagem portátil de nuvem, projetando para falha e usando “dual-cloud” como uma pedra para a verdadeira multicloud, as empresas podem ser muito mais ágeis quando o próximo (e infelizmente inevitável) grande incidente de nuvem ocorrer.












