Por que seu site de comércio eletrônico precisa de uma abordagem multi-nuvem ativa-ativa nesta temporada de festas

Para os líderes do e-commerce, as festas de fim de ano trazem duas certezas: um fluxo massivo de compradores e um risco maior de interrupções nos provedores de nuvem. Grandes interrupções na nuvem parecem estar se tornando mais comuns e devastadoras. A região US-East-1 da AWS, por exemplo, tem um histórico de interrupções significativas na temporada de festas de fim de ano. Da mesma forma, todos os anos por volta de janeiroO Microsoft Azure tende a apresentar problemas de latência ou interrupções de rede devido ao seu lançamento ou plano de testes em determinadas regiões. E basta olhar para junho passado, quando um grande interrupção do Google Cloud impactou uma ampla gama de aplicações, lembrando que nenhum provedor está imune.

Se você é responsável por uma operação de e-commerce, não quer descobrir que, mesmo com tudo configurado corretamente, algo parou de funcionar no período mais crítico do ano. Essas tendências de interrupções e problemas com provedores de nuvem podem não estar no seu radar e, francamente, não deveriam estar. Se você é um engenheiro de confiabilidade de sites, não precisa se preocupar se uma interrupção na plataforma de nuvem afetará sua aplicação, nem precisa tentar ajustar sua infraestrutura rapidamente durante um problema. Em vez disso, você deve reavaliar seus conhecimentos sobre multinuvem.

Aplicações multi-nuvem

Se a sua organização paga taxas da AWS, Azure e GCP, você de fato tem as três nuvens à disposição. Dito isso, embora você possa estar usando as três, é importante analisar o que acontece quando você aprofunda ainda mais a camada. Alguns dos seus aplicativos são específicos da AWS, Azure ou GCP? Eles continuarão funcionando se um provedor de nuvem ficar inativo e você precisar migrar rapidamente para outro?

Seu aplicativo deve funcionar perfeitamente em qualquer uma das nuvens. É isso que uma verdadeira configuração multinuvem significa. Se você quer ser agnóstico em relação à nuvem, não pode simplesmente pagar por multinuvem; você precisa garantir que seus aplicativos também sejam multinuvem.

Além disso, depender de um único provedor introduz restrições inerentes à capacidade computacional, à limitação da taxa de API e à disponibilidade regional. Uma verdadeira arquitetura multinuvem aumenta seu poder computacional agregado e oferece resiliência contra essas restrições. Ela libera sua capacidade de escalar sob demanda além dos limites de um único provedor, expandir rapidamente a capacidade entre regiões geográficas e garantir um desempenho consistente durante os dias de pico de compras. Mas ter um aplicativo portátil e independente de nuvem é apenas o primeiro passo; o próximo é implantá-lo em uma arquitetura verdadeiramente resiliente.

Escalando para uma abordagem ativa-ativa

Isso requer uma preparação séria por parte do DevOps. É incrivelmente difícil ter uma previsão 100% precisa Recuperação de Desastres de Continuidade de Negócios (BCDR) estratégia, pois quando se trata de executar suas operações ao vivo, existem vários pontos de falha. Você não quer testar sua estratégia de BCDR em uma interrupção, então pode achar que tudo o que pode fazer é prever cenários possíveis e se preparar adequadamente.

Meu conselho aos engenheiros de confiabilidade de sites é que a arquitetura seja baseada em falhas por padrão. Isso significa ter uma nuvem secundária ou mesmo terciária em execução em estado ativo. Uma estratégia de BCDR confinada a um único provedor é um ponto único de falha; se o plano de controle ou o backbone de rede do provedor falhar, todo o seu plano de recuperação se tornará inútil.

Durante as festas de fim de ano, é comum que o número de visitantes aumente repentinamente, forçando sua plataforma ou aplicativo a começar a funcionar com capacidade reduzida. Se você já criou uma cópia do seu aplicativo em funcionamento, uma secundária, pode passar a executar o balanceamento de carga para poder redirecionar algumas solicitações para a outra instância do seu aplicativo.

Essa abordagem ativa-ativa significa que você tem seu produto completo duplicado, rodando em outro lugar. Se o seu provedor de nuvem principal sofrer uma degradação ou interrupção grave, você pode transferir 100% do seu tráfego para o provedor secundário via DNS ou um balanceador de carga global, tornando-o o ponto de entrada principal sem interrupção para seus clientes.

O custo real de não adotar a multi-nuvem

Embora o custo de operar uma nuvem secundária não seja trivial, é insignificante em comparação com o impacto comercial de uma grande interrupção: pedir desculpas aos clientes após uma falha de confiabilidade, tentar garantir que isso não acontecerá novamente e convencê-los a não trocar você por um de seus concorrentes. Não podemos nos esquecer também de toda a receita perdida com as vendas perdidas que você não consegue recuperar. Na FluidCloud, já vi esse cenário se repetir inúmeras vezes: empresas investem pesadamente em um único fornecedor, apenas para se verem do lado errado de uma interrupção sem recurso imediato.

Dito isso, já é bastante difícil controlar seus custos se você usa apenas um provedor de nuvem; seus custos de nuvem provavelmente parecem um gráfico exponencial. Se você adotar várias nuvens, esse gráfico exponencial só vai parecer ainda mais acentuado.

Ao duplicar sua infraestrutura da sua nuvem primária, você naturalmente não quer que seus custos dobrem. Portanto, recomendo focar em nuvens mais baratas que ofereçam desempenho competitivo a um preço mais baixo. Se você tiver uma nuvem secundária em execução em uma nuvem mais barata, ainda terá redundância ativa-ativa completa, mas a um custo menor. É uma situação vantajosa para todos.

Considerações Finais

Executar seus aplicativos de forma ativa em vários provedores de nuvem não significa simplesmente criar um backup. Significa construir resiliência em tempo real, garantindo que sua empresa não tenha um único ponto de falha e sendo capaz de oferecer velocidade consistente mesmo durante picos de tráfego.

Nesta temporada de festas, não espere apenas por confiabilidade. Construa para ela. Projete seus sistemas para funcionarem de forma consistente, independentemente do provedor de nuvem ou região que apresentar falhas. Ofereça uma experiência impecável ao cliente adotando uma arquitetura multinuvem verdadeiramente ativa-ativa.