Muitos tentam duplicar sistemas com pelo menos dois hyperscalers, mas em muitos cenários, é uma solução cara que pode não fazer sentido
Tenho ouvido os argumentos sobre o uso de multicloud: os melhores serviços em nuvem, otimização de desempenho de custos e, é claro, redundância ao alavancar mais do que uma única marca de provedor de nuvem.
As empresas estão usando uma nuvem como principal e uma segunda nuvem como standby. A maioria está presumindo que haverá uma grande interrupção ou ataque de negação de serviço com a nuvem A e eles podem fazer failover para a nuvem B. Isso é redundância multicloud e está ganhando popularidade agora que multicloud é realmente alguma coisa.
Mas não é a única solução. A maioria dos principais provedores de nuvem oferece data centers secundários para alta disponibilidade ou capacidade de aproveitar regiões físicas para fornecer redundância. Contar com os recursos de continuidade de negócios/recuperação de desastres em um segundo nível de provedor de nuvem para a maioria das interrupções e ataques não impedirá que seu primeiro provedor de nuvem… bem … forneça.
Embora tenha havido algumas interrupções na nuvem pública ao longo dos anos, houve muito pouco impacto sobre os clientes da nuvem pública. Além disso, as nuvens públicas têm registros de tempo de atividade muito melhores do que a maioria dos sistemas internos.
Portanto, há valor em adotar redundância multicloud?
Não será gratuito, claro. A redundância multicloud requer que você configure uma versão primária do aplicativo e conjunto de dados em um provedor de nuvem pública, depois faça tudo novamente e configure um hot standby secundário em um segundo provedor de nuvem pública. Não é o dobro do dinheiro para fazer esse truque, mas é cerca de 75% a 85% a mais, em média.
Se configurar um único aplicativo e dados em uma única nuvem custar US$ 1 milhão para colocar em produção, optar pela redundância multicloud custaria até US$ 1,85 milhão. Isso é apenas para começar a implantação. Ops e os segundos seriam cerca do dobro também, em andamento.
Mesmo que custe cerca de duas vezes mais, você obtém um sistema que nunca deixará de fornecer serviços para a empresa, certo? Claro, eu acho que se você olhar como esses sistemas redundantes heterogêneos operam em um mundo perfeito e que você sofreria alguma perda de dinheiro quando os sistemas não funcionassem (digamos US$ 1 milhão por hora), então talvez valham a pena.
No entanto, isso quase nunca é o caso. A maior parte da redundância multicloud que vejo faz backup dos sistemas necessários, mas se eles parassem por algumas horas, o impacto nos negócios seria mínimo. Claro, se o argumento é que isso protege a empresa de uma grande interrupção que ainda não vimos e esse tipo de redundância ajuda você a dormir melhor, então vá em frente.
Outro argumento para redundância multicloud é que você nunca pode ser muito cuidadoso. Na verdade, você pode. Você pode “tomar cuidado” com a falência da empresa, se levar as coisas longe demais.
Você deve considerar um caso de negócios realista para obter redundância multicloud para cada carga de trabalho e conjunto de dados. O custo deve ser considerado em uma avaliação de que um único provedor ficaria ausente por tanto tempo que prejudicaria mais os negócios do que o preço de implantação de redundância multicloud. Além disso, você deve levar em consideração a redundância já existente dentro de uma única marca de provedor de nuvem, incluindo a capacidade de aproveitar regiões fisicamente dispersas para redundância intracloud que você não precisa configurar e operar.
Não estou dizendo que a redundância multicloud seja uma má ideia. Para quem acredita na segurança adicional e pode justificar o custo, vá em frente. Estou dizendo que há um ponto de valor a ser considerado para cada aplicativo e conjunto de dados e, sem fazer essa matemática, você está desperdiçando recursos que poderiam ser melhor usados em outras áreas da empresa.
