Práticas comprovadas para desenvolver uma estratégia multi-nuvem

Como Enterprise Strategist, acho que tópicos multi-nuvem surgem em muitas discussões repletas de confusão, falsa certeza e hesitação. As empresas são bombardeadas com mensagens conflitantes, dizendo-lhes que nunca adotem uma abordagem multi-nuvem ou que não percam a oportunidade porque “todo mundo está migrando para multi-nuvem”.

Há boas razões para seguir ou evitar estratégias multi-nuvem. Este blog se concentra em oito práticas comprovadas para o sucesso com multi-nuvem, incluindo quando e onde faz sentido e como a AWS está posicionada para ajudar as empresas a ter sucesso com suas estratégias multi-nuvem.

Multi-nuvem se refere ao uso simultâneo de mais de um provedor de serviços de nuvem (CSP, do Inglês “Cloud Service Provider”) em uma organização. Mas primeiro, vamos esclarecer algumas terminologias. Usar produtos SaaS, como e-mail ou software de gerenciamento de projetos, junto com um CSP não constitui um ambiente multi-nuvem puro. É uma boa estratégia e pode permitir que você aproveite várias nuvens, mas, no contexto deste blog, não é multi-nuvem para nuvens públicas.

1.Busque multi-nuvem somente para atender às necessidades de negócio legítimas

Embora recomendemos os clientes da AWS a aproveitar ao máximo os benefícios da nuvem escolhendo um provedor de nuvem principal, em que a maioria de suas cargas de trabalho estejam em um único CSP, há motivos válidos pelos quais uma abordagem multi-nuvem pode ser adequada para sua organização. Situações que podem exigir a complexidade de uma infraestrutura multi-nuvem incluem:

Fusões e aquisições

Um ambiente multi-nuvem pode ser criado durante uma transação de fusão e aquisição, quando a empresa adquirente está em um CSP principal e a empresa adquirida está em outro. Bem-vindo a multi-nuvem! O que vem a seguir não é fácil. O engenheiro em mim quer dizer consolide — menos é mais. Entretanto, pode não fazer sentido consolidar imediatamente. Sua estratégia geral de integração de tecnologia e abordagem de avaliação devem ser refletidas nesse processo; torne-as parte de seu manual de fusões e aquisições. O que você transfere de um provedor para outro, quando você o move e o que você mantém podem variar. Mas estabelecer uma estratégia de integração é tão importante quanto impedir que várias instâncias do ERP funcionem para sempre.

Desejo de aproveitar as capacidades diferenciadas de longo prazo de outro CSP

O medo de ficar de fora faz com que algumas empresas queiram um pouco de cada nuvem. Acreditamos que as empresas são melhor atendidas selecionando um CSP que possa resolver a maioria dos desafios de sua organização, em vez de adotar uma estratégia mais difusa. Uma estratégia 80/20 é uma boa maneira de pensar sobre isso. Focar nos 80% (e não nos 20%) pode resultar em melhor eficiência, retenção de talentos e valor. Embora possa haver cargas de trabalho especializadas que exijam uma determinada tecnologia, essas situações devem ser tratadas caso a caso, onde benefícios e compensações possam ser considerados.

As empresas podem pensar na “carga de trabalho certa para a nuvem certa”. Certifique-se de que a análise do que constitui a “nuvem certa” vá além das considerações para uma carga de trabalho específica. Pergunte como a distribuição dessa carga de trabalho em um CSP adicional afeta a complexidade geral. Eu recomendo que você faça uma análise cuidadosa de preço e desempenho de cada carga de trabalho em cada nuvem para garantir que o valor seja suficiente para justificar isso.

Multi-nuvem na holding e nuvem primária na empresa operacional/linha de negócios

Para organizações de Private Equity ou grandes holdings com várias empresas no portfólio, pode fazer sentido que cada empresa do portfólio tenha sua própria estratégia de CSP (frequentemente impulsionada por fusões e aquisições). A concentração de seus gastos em um único provedor de nuvem pode permitir que você aproveite descontos por volume e incentivos para reservar instâncias. Mas as outras deficiências relacionadas a talentos, cargas de trabalho fragmentadas e maiores riscos são amplamente contornadas, pois cada organização opera de forma independente.

2. Esteja atento aos mitos da multi-nuvem

Mito 1: Todos estão adotando estratégias multi-nuvem

Empresas de consultoria e empresas de mídia divulgaram resultados mistos sobre até que ponto as empresas colocam suas cargas de trabalho em várias nuvens. Nossa recomendação é fazer a coisa certa para sua empresa e tomar decisões com base em custos e riscos, independentemente de quão predominante essa prática possa parecer.

Mito 2: Multi-nuvem reduz o risco de dependência de fornecedores

Algumas empresas citam o medo da dependência de fornecedores (do ponto de vista contratual e tecnológico) como a principal razão para buscar estratégias multi-nuvem. Em ambientes de data centers locais, as empresas são motivadas a grandes investimentos de capital de longo prazo, geralmente regidos por contratos de serviço longos e complicados. Essas são grandes decisões de porta que abre para um lado (ou seja, difíceis e caras de reverter) para as empresas e exigem um forte foco na redução de riscos.

A nuvem é diferente. As empresas que executam a mesma carga de trabalho em vários provedores de nuvem geralmente se sentem pressionadas a usar o “menor denominador comum” — elas devem considerar as limitações. Em alguns casos, elas podem evitar esse problema executando cargas de trabalho diferentes com provedores diferentes.

Eu recomendo que as empresas trabalhem para entender completamente seus possíveis custos de mudança se precisarem sair do CSP existente e a probabilidade de isso ocorrer. A partir daí, é possível definir a melhor abordagem para reduzir a dependência avaliando o custo e a probabilidade de precisar alterar os CSPs versus os benefícios estratégicos de ter um provedor principal.

Também é importante observar que a nuvem é inerentemente mais aberta do que o modelo tradicional de TI, e não acreditamos que multi-nuvem seja necessária para evitar a dependência. Veja como a AWS cria serviços em tecnologias e padrões de código aberto, como SQL, Linux e contêineres. Os clientes têm a opção de usar serviços gerenciados de código aberto—como o Amazon Relational Database Service (RDS) para MySQL e o Amazon RDS para PostgreSQL, ou componentes básicos—e pagam conforme o uso; não há compromisso antecipado e de longo prazo. Nós nos empenhamos para criar serviços que os clientes queiram usar, mas se um cliente optar por se mudar, a AWS torna isso o mais simples possível. A AWS fornece várias ferramentas de migração não apenas para ajudar os clientes a mover recursos do data center local para a AWS com mais facilidade, mas também para movê-los de volta para o data center local ou para outras nuvens, se os clientes assim o desejarem.

Mito 3: Multi-nuvem melhora a disponibilidade

Reduzir o risco de interrupção do serviço se o CSP principal de uma empresa tiver uma indisponibilidade é um motivo cada vez mais raro para adotar uma estratégia multi-nuvem. Nesses casos, acredita-se que uma empresa pode mudar suas cargas de trabalho de forma simples e sem dificuldade para um CSP secundário.

O failover multi-nuvem presume que um aplicativo pode ser transferido para outra nuvem. Como muitas organizações descobriram, isso é extremamente desafiador. Conseguir isso exige que a empresa mantenha a portabilidade total entre dois CSPs, adicionando complexidade, risco e trabalho adicional com a crença de que o failover é possível.

A Distinguished Vice President e analista Lydia Leong, da Gartner, resumiu os problemas com o failover multi-nuvem em seu tweet: “O failover multi-nuvem é complexo e caro a ponto de ser quase sempre impraticável, e não é uma forma especialmente eficaz de lidar com os riscos de resiliência da nuvem”. O problema em fazer o failover funcionar são todos os diferenciais do CSP (por exemplo, as diferentes arquiteturas e recursos de rede, diferentes recursos de armazenamento, serviços proprietários de nível superior, camadas de banco de dados, serviços de aprendizado de máquina, além de diferentes recursos de segurança, etc.). Quando as cargas de trabalho estão espalhadas entre os CSPs, uma falha em qualquer um dos CSP pode causar uma interrupção. Nesse caso, a distribuição de cargas de trabalho entre os CSPs, na realidade, aumenta o risco.

Em vez disso, recomendo que as empresas reduzam os riscos “implementando e simplificando”. Escolha uma carga de trabalho ou aplicativo específico para uma única nuvem, migre-a, domine-a, elimine custos e riscos e repita. Incentive um aprendizado mais profundo dos recursos e capacidades específicos do CSP por meio de treinamento e aproveite os serviços e ferramentas de nível superior específicos do CSP que já estão integrados. Por fim, e talvez o mais importante, tire proveito das Regiões e Zonas de Disponibilidade da AWS. Os recursos da AWS nessa área já oferecem aos clientes da AWS excelentes recursos para garantir soluções altamente disponíveis e confiáveis.

Mito 4: Multi-nuvem oferece melhores preços

A competitividade de preços pode ser o argumento mais fraco de todos para a multi-nuvem. As experiências das organizações com contratos complicados e caros de software ou data center que as prendem por vários anos as tornaram cautelosas ao adquirir serviços de TI. As abordagens tradicionais de compras não se adaptaram às compras pagas conforme o uso, aos descontos por volume ou à realidade da concorrência de preços na nuvem. (A AWS reduziu os preços 129 vezes desde o seu lançamento.)

O maior fator isolado da redução de custos é o quão bem gerenciado e otimizado é o ambiente de nuvem de uma empresa. Uma empresa pode obter uma melhor otimização de custos trabalhando principalmente com um provedor cujos serviços oferecem vantagens de preço-desempenho (como instâncias de computação baseadas em chips personalizados, como o AWS Graviton) e têm soluções superiores de gerenciamento financeiro na nuvem. De acordo com um estudo de 2021 do Grupo Hackett com mais de 1.000 organizações, os gastos com infraestrutura como porcentagem dos gastos totais com TI foram 20% menores para os clientes da AWS do que para organizações multi-nuvem.

Nossa experiência mostrou que as empresas não preveem o custo e a complexidade adicionais de operar em várias nuvens, nem os comparam adequadamente com o ganho percebido em um contrato direto de fornecimento.

3. Tenha uma estratégia clara e governança para apoiá-la

A simples decisão de adotar uma estratégia multi-nuvem é insuficiente; você também deve estabelecer uma estratégia para cumprir seu objetivo de multi-nuvem, incluindo uma governança clara de quais cargas de trabalho irão para onde e por quê. Critérios de avaliação devem ser usados para otimizar as cargas de trabalho e suas dependências. Se deixada para os indivíduos, a dispersão descoordenada entre os CSPs provavelmente corroerá qualquer valor que a estratégia multi-nuvem buscava alcançar. Avalie o desempenho da carga de trabalho do CSP regularmente e use sua avaliação como um elemento chave para a seleção, os critérios e o uso futuro do CSP.

É crucial ter visibilidade abrangente do número total de serviços, aplicativos e componentes usados em toda a empresa como parte de uma estratégia geral de governança. Parte integrante disso é uma estratégia robusta de marcação (do Inglês “tagging”) que abrange todos os CSPs e estabelece claramente propriedade, uso e ambiente (por exemplo, desenvolvimento, controle de qualidade, pré-produção e produção) para 100% dos recursos implantados. Tudo deve ser marcado para um proprietário; se não estiver marcado ou um proprietário não puder ser identificado, deve ser removido. Isso codifica as regras de governança e automatiza a fiscalização em vez de criar obstáculos ao progresso (grades de proteção, não portões). O custo, as operações e a segurança devem ser rastreados, monitorados e aplicados da mesma maneira, com a mesma profundidade de dados e transparência entre os CSPs. É preferível uma única ferramenta para uma determinada necessidade que possa operar entre CSPs.

4. Não distribua cargas de trabalho contíguas entre CSPs

Na minha opinião, fluxos de trabalho que abrangem vários CSPs introduzem complexidade, risco e custo desnecessários, ao mesmo tempo em que complicam o suporte, a implantação e a arquitetura com pouco valor agregado. Cargas de trabalho contíguas geralmente envolvem grandes volumes de dados que precisam ser processados e analisados juntos. Quando os dados são distribuídos entre vários provedores de nuvem, eles podem criar desafios na movimentação, sincronização e também na manutenção de sua consistência. Além disso, gerenciar uma carga de trabalho contígua em vários CSPs pode ser complexo e demandante. Ela exige lidar com diferentes APIs, interfaces de gerenciamento, modelos de segurança e processos operacionais para cada CSP. Essa complexidade aumenta as chances de erros, aumenta a sobrecarga operacional e pode prejudicar a agilidade e a escalabilidade.

Critérios específicos e princípios orientadores devem ser estabelecidos ao avaliar esse tipo de design e necessidade de negócio.

5. Os aplicativos devem permanecer com seus dados transacionais

Deve-se tomar cuidado quando os desenvolvedores precisarem mover grandes volumes de dados entre aplicativos em diferentes nuvens, especialmente com computação/aplicativos implantados em um CSP e armazenamento de dados em outro. Essa situação pode adicionar complexidade e latência que podem anular os benefícios percebidos.

Os critérios de decisão para determinar um CSP para uma carga de trabalho devem incluir uma visão de longo prazo da integração dessa carga de trabalho com outras. Os dados serão necessários para análise avançada ou aprendizado de máquina além do escopo atual? Os serviços fornecidos serão amplamente consumidos em outros CSPs ou estarão isolados para as cargas de trabalho desse CSP? Para obter mais orientações e um modelo de decisão para considerações de implantação, confira o blog Multi-cloud: From Buzzword to Decision Model, do meu colega Gregor Hohpe.

6. Os contêineres podem ajudar, mas entenda que não resolvem todos os casos de uso

Usar contêineres geralmente é uma boa ideia para qualquer aplicativo moderno e eles ajudam com muitos elementos de portabilidade. Os contêineres são plataforma-agnósticos, o que significa que podem ser executados em qualquer plataforma de nuvem ou infraestrutura que ofereça suporte à conteinerização. Isso permite que você desenvolva e empacote seu aplicativo uma vez e o implante de forma consistente em vários provedores de nuvem ou data centers locais sem modificações significativas. Mas tenha cuidado, pois os contêineres não funcionam em todos os casos (por exemplo, grandes aplicativos monolíticos) nem resolvem todos os problemas (especialmente dados, políticas e segurança) relacionados à portabilidade entre CSPs.

7. Tenha um único Centro de Excelência em Nuvem (CCOE), mas especialize-se dentro dele

Como aconselhamos muitos clientes da AWS, você deve utilizar um CCOE (do Inglês “Cloud Center of Excellence”) em sua organização para fornecer liderança, padronização e aceleração de sua jornada na nuvem. Quando se trata de multi-nuvem, descobrimos que as empresas mais bem-sucedidas têm um único CCOE, mas especializam nesse CCOE as habilidades, as ferramentas e os mecanismos específicos para um CSP. Descobrimos que quando os clientes da AWS têm vários CCOEs para cada CSP, isso geralmente leva à divergência, reengenharia e desperdício, ao invés de uma abordagem mais coordenada por meio de um único CCOE.

8. Certifique-se de que a segurança seja sempre a principal prioridade

Multi-nuvem dificulta a segurança ao aumentar o risco de acesso não autorizado ou violação de dados. Multi-nuvem força as empresas a lidar com vários modelos de segurança através dos CSPs em áreas como gestão de identidade, segurança de rede, gestão de ativos e logs de auditoria.

Essa complexidade dificulta a transparência e aumenta a carga sobre as equipes de segurança, elevando o risco. Embora não sejam exclusivas de multi-nuvem, várias práticas básicas de segurança se tornam mais importantes: (1) transferir a segurança para o ciclo de desenvolvimento, automatizando-a e incorporando-a aos pipelines de entrega, ambientes de nuvem e prioridades da equipe; e (2) criptografar dados em repouso e em trânsito dentro ou entre CSPs.

Uma abordagem útil para a adoção de multi-nuvem é criar um único destino para os dados de segurança (ou seja, uma única visão). Amplie isso com ferramentas nativas da nuvem desenvolvidas por cada CSP para apresentar esses dados de forma que façam sentido nesse ambiente.

Conclusão

Para a maioria das organizações, uma estratégia de nuvem principal fornece o máximo valor por meio de simplicidade, foco e mitigação de riscos, ao mesmo tempo em que permite que as empresas aprofundem suas parcerias e conhecimentos práticos sobre seu principal CSP e serviços. Isso aumenta a capacidade da organização de aproveitar serviços mais sofisticados e atrair e reter melhor seus talentos, ao mesmo tempo em que agrega valor às empresas com mais rapidez.

Uma abordagem multi-nuvem pode fazer sentido, mas as empresas devem garantir que sua decisão de adotá-la seja orientada pelas necessidades de negócio e feita com uma compreensão clara das vantagens e desvantagens envolvidas. Nesses casos, recomendamos um modelo de nuvem focado em aplicativos e fluxos de trabalho de negócios que possam ser fornecidos de um único CSP, que provavelmente não compartilhem dados entre os CSPs e tenham uma governança clara de qual carga de trabalho vai para onde.

Para saber mais sobre os serviços da AWS que podem ajudar a centralizar e simplificar o gerenciamento e o monitoramento de ambientes híbridos e multi-nuvem, fornecer acesso a todos os seus dados onde quer que estejam armazenados e executar aplicativos na AWS, no data center local e em outras nuvens com os serviços de contêiner da AWS, confira as soluções da AWS para nuvem híbrida e multi-nuvem.