Mostramos por que combinar multicloud e open source permite tirar proveito dos pontos fortes do seu provedor atual sem abrir mão da flexibilidade que a nuvem pública promete.
O open source pode fazer parte da solução para extrair toda a flexibilidade que a nuvem oferece
Um dos grandes atrativos da nuvem é a promessa de uma flexibilidade praticamente sem limites. Mas, se o cliente não consegue trocar de provedor sem encarar custos altos, dores de cabeça jurídicas ou incompatibilidades técnicas, essa flexibilidade fica seriamente comprometida.
Usar mais de um provedor de nuvem parece ser a saída perfeita, só que não é tão simples assim. Vamos analisar o problema do vendor lock-in para clientes de nuvem, por que adotar multicloud não resolve a questão sozinho e como o open source entra nessa conta.
Como o vendor lock-in acontece na nuvem
Se a sua tecnologia está disponível em um único provedor e você não consegue continuar usando-a sem pagar licenças ou taxas de manutenção a ele, você está vivendo o vendor lock-in. Migrar para a nuvem deveria livrar você desse tipo de amarra, já que, em boa medida, você passa a usar a tecnologia nos seus próprios termos. Por exemplo, todos os grandes provedores oferecem o modelo pay-as-you-go, ou seja, em tese você pode desligar o ambiente, exportar seus dados e máquinas virtuais e ir embora quando quiser.
Além disso, os serviços de nuvem costumam ser desenhados para suportar a migração de dados tanto para dentro quanto para fora das plataformas. Os provedores criaram serviços e ferramentas para ajudar a migrar bancos de dados e as aplicações que dependem deles, seja para a nuvem ou entre nuvens.
Mesmo assim, trocar de provedor na nuvem está longe de ser trivial. Veja a transferência de dados, por exemplo: migrar dados entre servidores que usam o mesmo motor de banco de dados (migração homogênea) é relativamente fácil. Já uma mudança aparentemente pequena, como um número de versão, pode revelar uma série de problemas que precisam ser resolvidos antes de migrar para um motor diferente (migração heterogênea). Isso pode exigir uma abordagem e até uma aplicação totalmente diferentes.
Também é preciso considerar as aplicações construídas para tirar proveito dos pontos fortes específicos do seu provedor atual. Reconfigurar uma aplicação dessas para rodar nativamente em outra nuvem é complexo. E aí está o cerne do vendor lock-in na nuvem: cada provedor faz as coisas de um jeito ligeiramente diferente, então a troca sempre vai envolver algum nível de desafio — sem falar na curva de aprendizado que sua equipe terá com as tecnologias e a abordagem do novo provedor.
Por que só multicloud não é a resposta
Uma abordagem multicloud reduz a sua dependência de um único provedor, mas não é uma bala de prata contra o vendor lock-in. Mover uma aplicação ou workload existente de um ambiente on-premises para a infraestrutura de um provedor de nuvem é relativamente tranquilo, e o cliente fica razoavelmente protegido do vendor lock-in. Quando você paga por servidores, rede e armazenamento, o custo de mover suas máquinas virtuais para outro provedor se resume, basicamente, ao custo de aprender uma nova API de provisionamento.
Já com serviços a história é outra. Os provedores de nuvem pública costumam projetar seus serviços com ferramentas de gerenciamento proprietárias, que só funcionam dentro do ecossistema daquele provedor. Por exemplo, para implantar uma única aplicação na Amazon Web Services (AWS), você pode acabar usando serviços como Kinesis, DynamoDB, ElastiCache, Simple Queue Services, TimeStream e Lambda — todos proprietários e disponíveis apenas na AWS.
Considerando o custo de refatorar uma aplicação desenvolvida para uma plataforma de nuvem específica e fazê-la rodar em outra, montar serviços com combinações complexas de soluções proprietárias de alto nível dificulta desacoplar a escolha da tecnologia da escolha do provedor de nuvem. Em teoria, dá para rodar o mesmo workload em várias nuvens, mas isso significa se contentar com o menor denominador comum e abrir mão do potencial de inovação que a nuvem pública oferece.
Sua estratégia multicloud tem mais chances de dar certo se você projetar e construir cada aplicação na nuvem mais adequada a ela. Só que, na prática, quem costuma decidir onde um workload vai rodar é a conveniência, não a análise. É preciso pesar os pontos fortes de cada nuvem e como eles se encaixam no seu caso de uso de negócio. Sem dados confiáveis sobre o desempenho do workload na nuvem escolhida, alocá-lo no lugar certo vira mais uma questão de sorte do que de pesquisa.
Como o open source pode ajudar a evitar o vendor lock-in
Os clientes podem recorrer a uma série de plataformas e ferramentas open source de computação em nuvem para reduzir a dependência de soluções proprietárias. Na prática, o open source desacopla a escolha da tecnologia da escolha do provedor. Os desenvolvedores podem adaptar o código-fonte dessas plataformas e ferramentas conforme implantam, provisionam e gerenciam workloads e ambientes.
O Kubernetes — sistema de orquestração de contêineres que automatiza implantação, escalonamento e gerenciamento de software — e o service mesh Istio foram tornados open source pelo Google, que se consolidou como um dos principais líderes e contribuidores da comunidade open source.
Por exemplo, muitas ferramentas do Google Cloud Platform (GCP) são baseadas em tecnologia open source, e o GCP coloca por cima uma camada de gerenciamento de operações para agregar valor e acelerar a adoção pelos clientes. O Google Kubernetes Engine (GKE) e serviços como Dataflow, Cloud Composer, Managed Service for Prometheus e Cloud Data Fusion são construídos de modo que, no fundo, você pode pegar a mesma lógica de negócio e rodá-la em qualquer outro lugar bastando implementar a nova camada operacional.
Uma plataforma como o Anthos, do Google, viabiliza a modernização de aplicações em multicloud híbrido, permitindo orquestrar e executar clusters Kubernetes — e até VMs (em private preview) — no GCP, AWS, Azure, nuvem privada e bare metal. Mesmo que o Kubernetes não seja a base de toda a sua nuvem, ele é útil para orquestrar parte dos workloads que rodam dentro de uma nuvem pública.
Para garantir o futuro do software open source, as empresas devem incentivar e recompensar as contribuições open source dos seus times. Um relatório recente da CNCF mostrou que 96% das organizações já usam Kubernetes, e o número de outros projetos open source nativos da nuvem disparou no último ano. O software open source ajuda a viabilizar uma estratégia multicloud eficaz e impede que as empresas fiquem reféns de uma única nuvem.
Por outro lado, há um trade-off quando você passa a depender de uma boa quantidade de serviços open source: o Day 2 fica por sua conta. Ou seja, você é quem cuida de monitoramento, atualizações e segurança — e todo esse trabalho extra pode não compensar os recursos e processos adicionais que vai exigir.
Você também terá que operar com mecanismos mínimos de suporte, na maioria das vezes sem qualquer SLA, então fica por conta própria diante de qualquer indisponibilidade em produção. E o que acontece quando você quer adicionar funcionalidades a um serviço crítico? Seus engenheiros terão que arrumar tempo para contribuir com a comunidade open source em vez de evoluir o que é central no seu produto. Assim como ocorre com a estratégia multicloud, contar só com o open source para evitar o vendor lock-in não é a resposta.
Próximos passos
Então, como aproveitar o verdadeiro poder da nuvem sem ficar refém das restrições impostas por um provedor? Trabalhar com um parceiro que conhece a fundo todos os principais provedores ajuda a planejar sua estratégia de nuvem para extrair o máximo de valor de negócio do provedor escolhido.
O time da DoiT não só tem ampla experiência ajudando empresas a tirar proveito de várias nuvens para alcançar seus objetivos de negócio, como também desenvolveu ferramentas open source que otimizam suas operações na nuvem, resolvem desafios técnicos complexos e reduzem a dependência de plataformas proprietárias. Com a abordagem certa, dá para aproveitar os pontos fortes do seu provedor atual sem abrir mão de toda a flexibilidade que a nuvem pública promete.