Arquitetura multicloud com Google Cloud na prática

Conheça os desafios e as oportunidades de criar uma solução híbrida ou multicloud com o Google Cloud

Cada vez mais empresas estão escolhendo soluções híbridas e multicloud com o Google Cloud. Algumas são startups que constroem ativamente sua base de clientes indo até onde os clientes estão; outras são grandes corporações em busca da melhor ferramenta para resolver problemas, garantir alta disponibilidade ou diversificar provedores para reduzir riscos. Antes de partir para a construção de uma solução híbrida/multicloud (que costuma ser parte de um processo maior de modernização de aplicações), as empresas precisam conhecer os possíveis desafios e oportunidades.

Neste post, vou me aprofundar nesses tópicos para ajudar a esclarecer quem é um candidato adequado a essa opção, os desafios a observar, as soluções disponíveis e as situações em que essa opção deve ser evitada (pelo menos no curto prazo).

Definições

Vamos começar com algumas definições:

• Nuvem pública – serviços de computação sob demanda e infraestrutura gerenciados por um provedor terceirizado e compartilhados com várias organizações pela Internet pública
• Nuvem privada – infraestrutura dedicada a uma única organização usuária; pode ser hospedada no próprio data center da empresa ou em uma instalação de colocation de terceiros
• Nuvem híbrida – combina serviços on-premises, de nuvem privada e de nuvem pública de terceiros, orquestrando-os entre as plataformas
• Multicloud – combina vários serviços de computação e armazenamento em nuvem em uma única arquitetura heterogênea; também se refere à distribuição de ativos, software, aplicações etc. em vários ambientes hospedados em nuvem
• Aplicação legada – sistema de informação possivelmente baseado em tecnologias ultrapassadas, mas crítico para a operação do dia a dia; em geral, são aplicações monolíticas de três camadas, frágeis e difíceis de manter e atualizar
• Aplicação moderna – costuma ser descrita como uma aplicação composta por microsserviços em uma arquitetura N Tier. É tão confiável quanto necessário e pode ser atualizada várias vezes ao dia sem impactar a produção (uma definição mais ampla é a aplicação The Twelve Factor).

Casos de uso

Esta lista não é exaustiva:

1. Etapa intermediária da migração de uma infraestrutura de TI cuja transferência para a nuvem é, no máximo, moderadamente difícil: por exemplo, um cliente tem uma quantidade significativa de servidores on-prem (geralmente Linux ou Windows), uma conexão é configurada via VPN ou interconnect, e grupos de VMs (de acordo com os limites das workloads das aplicações) são migrados para a nuvem. Os clientes da empresa são atendidos por uma solução de nuvem híbrida, com algumas aplicações rodando on-prem e outras na nuvem, até que todas as workloads sejam migradas para a nuvem pública (nuvem híbrida).
2. O cliente quer modernizar a solução, mas tem aplicações e bancos de dados muito difíceis de mover para a nuvem: por exemplo, um cliente que tem um mainframe ou Oracle DB (hoje já não tão difícil) no ambiente de nuvem privada e gostaria de mover a aplicação para uma arquitetura moderna como Kubernetes (nuvem híbrida).
3. Requisitos regulatórios: por exemplo, requisitos de regionalidade de dados podem implicar que certas informações não podem sair das fronteiras do país.
4. Cloudbusting: nesse cenário, capacidade adicional pode ser provisionada automaticamente na nuvem e escalada para cima caso o ambiente on-prem fique sobrecarregado. Isso pode acontecer no varejo durante eventos como Black Friday/Cyber Monday (nuvem híbrida).
5. Alta disponibilidade e disaster recovery (nuvem híbrida e multicloud)
6. Usar a nuvem certa para o caso de uso certo: por exemplo, manter ambientes de Kubernetes e data analytics no Google Cloud Platform (GCP) e aplicações baseadas em Microsoft no Azure.
7. Evitar vendor lock-in

Stack tecnológico e capacidades necessárias

Agora vamos nos aprofundar no stack tecnológico e nas capacidades que você precisa ter/construir, e nos desafios que isso pode trazer para empresas em diferentes estágios da jornada:

Compute:

• Entender o ambiente de nuvem privada – VMs e as várias tecnologias na camada do hypervisor: para empresas que já estão em uma nuvem privada, isso obviamente não é problema. Para empresas digital native, que nunca precisaram lidar com o stack tecnológico e a política envolvida em implementar uma solução de nuvem em um ambiente de nuvem privada, isso pode ser um desafio e tanto.
• Entender o ambiente de nuvem pública: isso não é problema para empresas digital native, mas pode trazer questões importantes de segurança e política interna para empresas que rodam on-premises. Elas vão precisar aprender um novo stack, com novas formas de gerenciar VMs, autoscaling etc.

Bancos de dados e armazenamento:

• Para empresas que estão hoje na nuvem privada, o desafio é aprender e selecionar um banco de dados nativo da nuvem adequado. Caminhos fáceis são migrar para SQL Server/PostgreSQL/MySQL gerenciados, mas, dependendo dos objetivos de negócio e técnicos, algumas empresas podem querer ou precisar migrar para tecnologias como Spanner, BigTable e BigQuery. Isso pode ser desafiador.
• Tocar dois stacks tecnológicos ao mesmo tempo pode ser difícil: uma empresa com uma aplicação on-prem baseada em Oracle que quer migrar para PostgreSQL tem duas opções, dependendo da complexidade e dos recursos em uso. A primeira é um lift and shift para uma opção bare-metal, seguido de modernização. A outra é deixá-la onde está, modernizar na nuvem privada e depois migrar para a nuvem. Em qualquer cenário, a empresa precisará operar dois tipos de DBs simultaneamente até que a modernização seja concluída e um deles possa ser desligado.

Networking:

• Há diferenças significativas entre o networking em nuvens públicas e privadas — e até entre as várias nuvens. Por exemplo, a Global VPC do Google Cloud é um benefício enorme para simplificar seu networking. Muitas empresas de nuvem privada precisam aprender como tudo isso funciona. Elas também têm dificuldade em decidir conscientemente não replicar na nuvem pública a forma como fazem as coisas na nuvem privada.
• Configurar VPNs, partner-interconnect e interconnects pode ser simples em alguns casos, mas também pode levar semanas ou meses, dependendo da localização da nuvem privada do cliente.

Segurança:

• Implementar medidas de segurança unificadas e prontas para produção em ambientes híbridos e multicloud pode ser complicado. Cada provedor de nuvem tem medidas de segurança diferentes, implementadas de formas diferentes. A forma como você faz deploy do SW e o testa contra vulnerabilidades de segurança durante o processo de deploy pode ser um projeto à parte.
• Implementar sistemas de monitoramento de segurança em várias nuvens é um desafio.

CI/CD:

• Construir de forma confiável uma pipeline de Continuous Integration e Continuous Deployment (CI/CD) para construir, testar, proteger e fazer deploy tanto de infraestrutura (IAC — como Terraform ou Pulumi) quanto de aplicações em vários ambientes é um desafio enorme. Também exige times e ferramentas de engenharia altamente sofisticados e capazes.

Modernização:

• Decidir o que e como modernizar aplicações e DBs não é tarefa pequena e exige fases consistentes de avaliação e planejamento. Pode levar meses ou até anos, além de uma forte gestão de mudança organizacional, para que clientes de nuvem privada aprendam K8s e a melhor forma de trabalhar com o sistema.

Autenticação:

• O desafio é lidar com SSO Federation, AD Federation etc. em várias plataformas a partir de uma única fonte da verdade.

Time:

• É difícil encontrar engineers/arquitetos com habilidades em várias plataformas, então você precisa investir no treinamento dos seus times.
• A alternativa é aprender e se manter atualizado em vários ambientes em um mundo de nuvem em rápida transformação, ao mesmo tempo em que você monta times separados com diferentes conjuntos de habilidades e tenta definir um processo de negócio para que eles trabalhem juntos com eficiência.

Custo:

• Assim como configurar um ambiente multi-região e de alta disponibilidade (HA), configurar uma solução multicloud ou de nuvem híbrida pode custar até dez vezes mais. Não se trata só de subir mais uma VM ou banco de dados e pagar a mais por isso: as operações do Day 2 incluem orquestração, replicação, custo de network egress e a sustentação das pessoas e mecanismos desses sistemas — tudo isso soma.
• As empresas precisam pensar em FinOps e construir uma prática cultural em que os times gerenciam seus custos de nuvem, todos assumem a responsabilidade pelo uso da nuvem, um grupo central de boas práticas oferece suporte e surge uma visão 360° do custo híbrido/multicloud.

Definindo uma solução

A esta altura, você provavelmente está pensando que multicloud e nuvem híbrida são realmente difíceis, mas, como é para esse caminho que o setor está indo, você precisa encontrar uma solução.

É importante entender que esse tipo de projeto leva tempo e, depois disso, seguir esta metodologia:

1. Avalie a cultura da sua empresa, suas práticas de DevOps, seu stack tecnológico etc.
2. Planeje com base nos objetivos de negócio e tecnológicos da empresa e nos resultados da avaliação. Tenha em mente que existem curvas de aprendizado significativas, tanto dentro da sua empresa quanto junto aos seus clientes, em relação às mudanças que você fizer no sistema. Isso pode levar tempo, e você precisa permitir que as pessoas se adaptem às novas metodologias de trabalho e à nova tecnologia.
3. Migre/refatore: comece devagar e em pequena escala, deixe que as pessoas falhem rápido, aprendam com a falha e melhorem. Se você começar devagar, a velocidade vai aumentar de forma incremental. Não tente otimizar enquanto muda de plataforma, base de código etc.
4. Otimize depois que a mudança inicial for feita e você tiver um novo sistema funcionando. Trabalhe a otimização tanto sob a perspectiva de performance quanto de custo.

Construindo o stack híbrido ideal

Nenhuma das soluções tecnológicas no mercado vai resolver tudo. Você precisa avaliar seu stack e combinar soluções para criar um stack híbrido completo.

Camada de aplicação:

O GCP Anthos é uma ótima solução, que cobre boa parte do que você precisa para operar a camada de código/aplicação. Ele inclui as camadas a seguir, que permitem orquestrar e rodar clusters Kubernetes e até VMs (em private preview) no GCP, AWS, Azure, nuvem privada e bare metal.

Camadas de aplicação do Google Cloud Anthos

Os Anthos clusters, a camada gerenciada de Kubernetes na base do stack, deixam as operações do Day 2 muito mais simples do que rodar seus próprios clusters Kubernetes open source.

O Anthos Ingress é um controlador de Ingress multi-cluster hospedado em nuvem para clusters GKE.

O Anthos Service Mesh é um conjunto de ferramentas que ajuda você a monitorar e gerenciar um service mesh confiável on-premises ou no Google Cloud.

O Anthos Config Management é um serviço de configuração e gestão de políticas que reúne três componentes: Policy Controller, Config Sync e Config Controller. Juntos, eles permitem que o Anthos Config Management proteja e configure continuamente seus recursos do Google Cloud e do Kubernetes.

Os Anthos fleets (anteriormente chamados de environs) são um conceito do Google Cloud para organizar logicamente clusters e outros recursos, permitindo usar e gerenciar capacidades multi-cluster e aplicar políticas consistentes em todos os seus sistemas.

Limitações: vale destacar que o serviço se limita a controlar e monitorar apenas as partes da sua solução que rodam dentro do ambiente Anthos.

Camada de banco de dados e armazenamento:

• Se você opera suas próprias camadas de armazenamento e DB fora do escopo do cluster, pode aproveitar serviços de DB gerenciados como CloudSQL ou RDS.
• Se você opera o DB dentro do seu cluster Kubernetes (por exemplo, mySQL ou MongoDB), agrega um overhead operacional significativo ao rodar seu próprio DB no cluster, em vez de usar as versões gerenciadas do provedor de nuvem.

Segurança + monitoramento:

• SIEM + monitoramento: procure ferramentas que ofereçam uma solução multicloud/nuvem híbrida, como Splunk, Datadog ou PagerDuty.
• Gestão de segurança e secrets: alguns exemplos são HashiCorp Vault e AWS Secrets Manager.

CI/CD:

• Soluções de mercado como Gitlab e Jenkins funcionam em diferentes ambientes e permitem construir e fazer deploy tanto de containers quanto de VMs.

Se você não precisa construir e fazer deploy de VMs, dê uma olhada no spinnaker.

Provisionamento de infraestrutura:

• Entre as opções estão HashiCorp Terraform, Red Hat Ansible e Pulumi.

Para finalizar:

• Construir uma solução híbrida/multicloud é muito difícil e muito caro, tanto sob a ótica de pessoas e processos quanto sob a ótica tecnológica.
• Tecnologias como o GCP Anthos dão suporte a uma solução multicloud, mas nenhuma tecnologia isolada oferece uma solução end-to-end. Isso precisa entrar na conta na hora de desenhar a arquitetura da sua solução.
• Esse processo será mais fácil para empresas que já rodam Kubernetes em produção em escala, seja on-prem ou na nuvem.
• Esse processo será mais difícil para:

  • Empresas que rodam aplicações monolíticas legadas on-prem. Construir uma solução híbrida e a transformação necessária em processos de negócio, capacitação de pessoas e mudança no stack tecnológico podem levar de dois a dez anos, dependendo da complexidade e da escala da mudança.

    É para lá que o mercado está indo, e empresas que passam por esse processo veem um ROI significativo. Mesmo assim, ao embarcar nessa jornada, as empresas devem calibrar as expectativas, entendendo a dimensão do desafio.

  • Startups com times pequenos: Kubernetes é interessante e empolgante, e a sua startup quer atender todo cliente em todo ambiente, mas os recursos são limitados, e você precisa ter um produto funcionando com o menor overhead operacional e de custo possível. Diante dos desafios inerentes, foque primeiro em ter um produto viável (sem perder de vista a portabilidade do workflow) e uma base de clientes em uma única nuvem, usando o máximo possível de serviços totalmente gerenciados. Quando o time estiver grande o suficiente e a solução estiver suficientemente estável, comece a explorar como refatorar e operar uma solução multicloud.

Se você quer saber mais sobre o tema e ainda ver uma demo de como o Anthos funciona em um ambiente multicloud, inscreva-se no nosso evento em 22/02/2022, às 13h GMT.

Fique à vontade para entrar em contato se tiver alguma dúvida ou quiser conversar sobre a sua jornada rumo a uma aplicação moderna em um ambiente híbrido ou multicloud.