Connect with us

Líderes de pensamento

Comece a se Preparar Agora para a Próxima Interrupção de Nuvem

mm

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.

Harshit Omar é o co-fundador e CTO da FluidCloud, onde ele está construindo o futuro da infraestrutura de nuvem - permitindo que as empresas migrem, repliquem e otimizem workloads de forma transparente em ambientes de multi-nuvem. Ele foi anteriormente o primeiro engenheiro da Accurics, onde liderou os esforços de desenvolvimento central no seu motor de política e plataforma de segurança de nuvem.

Com profunda especialização em Go, Kubernetes, Terraform e conformidade de nuvem, Harshit passou mais de uma década projetando sistemas resilientes em AWS, Azure e GCP.

Sua missão agora é eliminar o bloqueio de nuvem e tornar a infraestrutura tão portátil e resiliente quanto o código.