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

Para líderes de comércio eletrônico, as festas trazem duas certezas: um grande influxo de compradores e um risco aumentado de interrupções nos provedores de nuvem. Grandes interrupções de nuvem parecem estar se tornando mais comuns e mais devastadoras. A região AWS US-East-1, por exemplo, tem um histórico de interrupções significativas durante a temporada de festas. Da mesma forma, a cada ano, por volta de janeiro, a Microsoft Azure tende a ter problemas de latência de rede ou interrupções de rede devido ao seu plano de lançamento ou teste em certas regiões. E precisamos apenas olhar para o passado, em junho, quando uma interrupção significativa da Google Cloud afetou uma ampla gama de aplicações, para ser lembrado de que nenhum provedor é imune.

Se você é responsável por uma operação de comércio eletrônico, você não quer descobrir que, mesmo tendo tudo configurado corretamente, algo parou de funcionar durante o período mais crítico do ano. Essas tendências de interrupção e problema de provedor de nuvem podem não estar em seu radar, e francamente, não deveriam estar. Se você é um engenheiro de confiabilidade do site, você não deve se preocupar se uma interrupção de nuvem afetará sua aplicação, nem deve tentar ajustar sua infraestrutura em tempo real durante um problema. Em vez disso, você deve reexaminar o que sabe sobre multi-nuvem.

Aplicações multi-nuvem

Se sua organização está pagando taxas de AWS, Azure e GCP, você realmente tem as três nuvens à sua disposição. No entanto, embora você possa estar usando as três, é importante examinar o que acontece quando você vai um nível mais profundo. Algumas de suas aplicações são específicas de AWS, Azure ou GCP? Elas continuarão funcionando se um provedor de nuvem estiver down e você precisar mudar rapidamente para outro?

Sua aplicação deve funcionar perfeitamente em qualquer uma das nuvens. É isso que uma configuração multi-nuvem verdadeira é. Se você quer ser agnóstico em relação à nuvem, você não pode simplesmente pagar por multi-nuvem; você também precisa garantir que suas aplicações sejam multi-nuvem.

Além disso, confiar em um único provedor introduz restrições inerentes à capacidade de computação, limitação de taxa de API e disponibilidade regional. Uma arquitetura multi-nuvem verdadeira aumenta sua capacidade de computação agregada e fornece resiliência contra essas restrições. Ela desbloqueia sua capacidade de dimensionar sob demanda além dos limites de um único provedor, expandir rapidamente a capacidade em diferentes geografias e garantir um desempenho consistente durante os dias de pico de compras. No entanto, ter uma aplicação portátil e agnóstica em relação à nuvem é apenas o primeiro passo; o próximo é implantá-la em uma arquitetura verdadeiramente resiliente.

Escala para uma abordagem ativa-ativa

Isso requer uma preparação séria por parte dos DevOps. É incrivelmente difícil ter uma estratégia de recuperação de desastre de continuidade de negócios (BCDR) 100% precisa, pois, quando se trata de executar suas operações ao vivo, há vários pontos de falha. Você não quer testar sua estratégia de BCDR durante uma interrupção, então você pode sentir que tudo o que você pode fazer é prever cenários possíveis e se preparar de acordo.

Minha recomendação para engenheiros de confiabilidade do site é arquitetar para falha por padrão. Isso significa ter uma nuvem secundária ou até mesmo uma nuvem terciária em execução em um estado ativo. Uma estratégia de BCDR confinada a um único provedor é um ponto de falha único; se o plano de controle ou a espinha dorsal da rede do provedor falhar, todo o seu plano de recuperação se torna inútil.

Durante a temporada de festas, é comum que o número de visitantes aumente subitamente, forçando sua plataforma ou aplicação a começar a funcionar com capacidade reduzida. Se você já criou uma cópia de sua aplicação em funcionamento, uma secundária, você pode mudar para realizar balanceamento de carga para que você possa desviar algumas solicitações para a outra instância de sua aplicação.

Essa abordagem ativa-ativa significa que você tem seu produto completo duplicado, em execução em outro local. Se seu provedor de nuvem primário experimentar uma degradação grave ou interrupção, você pode mudar suavemente 100% de 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 executar uma nuvem secundária não seja trivial, é insignificante em comparação com o impacto comercial de uma interrupção significativa: pedir desculpas aos clientes após uma falha de confiabilidade, tentar garantir que isso não acontecerá novamente e convencê-los a não deixá-lo para um de seus concorrentes. Vamos também não esquecer de todas as receitas perdidas das vendas que você não pode recuperar. Na FluidCloud, eu vi esse cenário se desenrolar repetidamente: as empresas investem pesadamente em um único provedor, apenas para se encontrar no lado errado de uma interrupção sem recurso imediato.

No entanto, é difícil controlar seus custos se você estiver usando 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ó irá parecer ainda mais íngreme.

Quando você duplica sua infraestrutura da nuvem primária, você naturalmente não quer que seus custos dobrem. Eu, portanto, recomendo se concentrar em nuvens mais baratas que oferecem desempenho competitivo a um preço mais baixo. Se você tiver uma nuvem secundária em execução em uma nuvem mais barata, você ainda terá redundância ativa-ativa completa, mas a um custo mais baixo. É um ganha-ganha.

Pensamentos finais

Executar suas aplicações em uma abordagem ativa-ativa em vários provedores de nuvem não significa simplesmente criar um backup. Significa construir para resiliência em tempo real, garantir que seu negócio não tenha um ponto de falha único e ser capaz de oferecer velocidade consistente, mesmo durante picos de tráfego.

Nesta temporada de festas, não apenas espere por confiabilidade. Construa para isso. Engenheie seus sistemas para funcionar consistentemente, não importa qual provedor de nuvem ou região falhe. Forneça uma experiência de cliente perfeita, adotando uma arquitetura multi-nuvem ativa-ativa verdadeira.