Genesis | A ‘cloud history’ da Neoway
Tá vendo aquela nuvem que brilha lá no server?
Você conhece alguma empresa que utilizou ou usa mais de um provedor de cloud? Independente da sua resposta, a migração de recursos computacionais e dados de qualquer empresa para a nuvem é coisa séria.
Só que, quando seu time trabalha na maior empresa de big data analytics da América Latina, o nível das apostas é significativamente maior. Nesse artigo, vamos apresentar a estratégia da Neoway nessa área — e que lições podemos compartilhar sobre a jornada.
É importante lembrar que cada empresa tem sua história de adoção e uso de Cloud e respeitar as escolhas de cada time, antes mesmo de ponderar sobre certo ou errado.
Antes de mergulhar no nosso projeto principal de “IaC” (infraestrutura como código), vale a pena compartilhar um pouco sobre como os times de engenharia eram organizados na Neoway e impactavam na forma de desenvolver a nossa plataforma. Vamos nessa?
2015: “No princípio era o server…” — AWS e migração de on premise Cloud
A Neoway já possuía uma solução monolítica chamada SIMM Flex, hospedada em servidores físicos on premise, a empresa escolheu desenvolver uma nova plataforma do zero utilizando uma arquitetura de referência de micro serviços e cloud native ao invés de modularizar a solução atual.
Na nova plataforma cada time trabalhava de forma autônoma, como se fosse uma startup dentro da estrutura da Neoway, construía, operava e sustentava suas máquinas virtuais e serviços, e tinha total liberdade para escolher suas tecnologias. Isso nos permitiu alcançar maior agilidade no desenvolvimento da nova plataforma, pois praticamente não tínhamos dependências entre os times.
O provedor de Cloud era o AWS, e cada time tinha seu projeto de orquestração de “IaC”. Criamos uma ferramenta utilizada por todos os times para provisionamento de máquinas virtuais e gerência de configuração chamada cloud-machine.
Vale destacar que a construção da VPC (rede, firewall, roteamento), e gestão da Cloud já eram disponibilizados junto com a criação de uma conta no provedor (account na AWS) pelo time que era responsável pela infraestrutura de TI.
Migramos também nossa solução legada (SIMM Flex) do on premise para a Cloud (AWS), que teve ajustes necessários para ser executada na Cloud com dualidade, isso implicou em algumas alterações como duplicar estado de sessão, rodar a aplicação em contêiner, entre outros detalhes, para tornar a solução mais resiliente.
Aprendemos na AWS que Cloud é diferente de servidores físicos, por exemplo, um disco ou uma interface de rede na nuvem pode ter uma performance diferente dependendo da máquina virtual que eles estão conectados. E aprendemos na prática os desafios da computação distribuída.
Também entendemos que existe uma responsabilidade compartilhada entre o provedor e o cliente, dependendo do tipo de serviço contratado.
Responsabilidade do cliente: “segurança na nuvem”: a responsabilidade do cliente será determinada pelos Serviços de nuvem AWS selecionados por ele. Isso determina a quantidade de operações de configuração que o cliente deverá executar como parte de suas responsabilidades de segurança.
Fonte: AWS
Os nossos serviços que rodavam em Cloud já eram executados em container (docker ou rkt). O que permitia empacotar código, configurações e dependências em um único artefato. Toda a nossa stack de máquinas virtuais se resumia em CoreOS e systemd units para execução dos serviços, inclusive o deploy do próprio clusters de Kubernetes era realizado dessa forma.
Foi marcante na época que já usávamos a primeira release do Kubernetes (Kubernetes v1.0) lançado em Julho de 2015, a documentação não era tão madura como atualmente, e foi um projeto interessante de P&D para validar se atenderia nossos requisitos a fim de substituir a forma que executamos nossa orquestração dos serviços (system-d units). Traduzindo: a gente tava lá quando tudo era mato nessa área.
Após executar testes em workloads de baixa criticidade e dominar a tecnologia, em Dezembro de 2015 passamos a utilizar o Kubernetes para orquestrar nossos serviços críticos.
2017: uma migração não traumática da AWS para o Azure
Em 2017, nossa conta da Cloud na AWS era expressiva em termos de custo e despontava-mos no mercado como uma das maiores empresas de ponta em Big Data Analytics, a Microsoft estava investindo para ser um dos principais players do mercado e viu uma oportunidade da Neoway ser um case de utilização do Azure.
Um dos requisitos da nossa plataforma era permitir executar toda a stack de infraestrutura em ambientes on premise, com isso evitamos a utilização de recursos exclusivos do Cloud Provider, por exemplo DynamoDB da AWS. Isso nos permitiu realizar a migração da AWS para o Azure de uma forma não traumática e em tempo hábil.
Cada time ainda atuava de forma independente, além de construir, operar e sustentar suas máquinas virtuais e serviços passou a ter a responsabilidade da Vnet (rede, firewall, roteamento). Com isso tivemos um aumento da carga cognitiva dos nossos times em absorver o conhecimento necessário para fazer a operação e sustentação de toda camada de rede da infraestrutura de Cloud.
Os times continuavam com seu projeto de orquestração de “IaC” independentes. Criamos uma ferramenta para provisionamento de infraestrutura (vms, rede etc) e gerência de configuração que batizamos de KLB (projeto era nosso repositório de libs reutilizadas que simplificava as interações com azure cli). Alguns times usavam, além do “KLB”, outras ferramentas de “iAc”, como terraform e ansible.
A gestão da Cloud e a criação de uma conta no provedor (Subscription no Azure) continuava sendo de responsabilidade do time de infraestrutura de TI.
Nessa época, passamos por algumas experiências de instabilidade de recursos, que nos permitiu:
- Identificar e evoluir diversos pontos de alta disponibilidade e recuperação de desastres nos serviços da plataforma.
- Amadurecer a observabilidade e estabelecermos o nosso processo de atuação em incidentes (“post-mortem”).
2019: A terceira é a que vale? A migração para Google Cloud Platform
Com base nas experiências das migrações passadas e somando com os desafios atuais gerados pela forma que nossos times estavam organizados, resolvemos adotar uma nova abordagem para lidar com infraestrutura de Cloud na Neoway.
Até 2019, vale reforçar, que os nossos times de engenharia trabalhavam de forma autônoma como startups.
Apesar das vantagens, as consequências dessa abordagem eram:
- Duplicação de recursos;
- Alta carga cognitiva;
- Diversos projetos de “IaC” e tecnologias para fazer provisionamento/ gestão de configuração de infraestrutura.
Percebemos também uma divergência na maturidade de conhecimento entre os nossos times para fazer a operação e sustentação da infraestrutura de Cloud.
Isso começou a mudar com o lançamento do programa Neoway 3.0 e uma visão integrada de todas as áreas da empresa. Um dos principais diferenciais desse programa é a organização coesa de times e a capacidade de manter as equipes com foco nas jornadas de valor dos clientes, que por sua vez são definidas pelos problemas a serem resolvidos.
É aquela coisa: a tecnologia é um meio e não um fim. O que significa que, para os clientes, o importante é que a empresa entregue valor — seja para ele ganhar mais ou perder menos.
Durante essa transição da organização dos nossos times, além da escolha de afinidade tecnológica, um conjunto de fatores motivadores influenciaram em nossa decisão de migração para a Google Cloud.
Também foi extinto o requisito de rodar nossa plataforma on premise, que impossibilitava a utilização de serviços exclusivos do Cloud Provider (SaaS).
Um fator que vale destacar foi a reformulação da nossa arquitetura de dados, com intuito de prover serviços para os nossos times de desenvolvimento. A Google Cloud possuía um diferencial de serviços exclusivos (SaaS) para trabalhar com dados, como por exemplo o BigQuery (data warehouse com recursos para analytics) e o DataProc (Apache Spark as a service). A utilização desses serviços nos permitiria uma rápida evolução da arquitetura de dados — assunto para um novo artigo.
Enter the Genesis: Infraestrutura como Plataforma
Conhecendo os nossos desafios atuais, pensando em garantir a eficiência operacional, normalizar a nossa stack de tecnologia de “IaC”, possibilitar a reutilização de código, reduzir a carga cognitiva dos nossos times, fornecer várias camadas de segurança pela plataforma de Cloud e ao mesmo tempo assegurar a autonomia de criação de recursos de infraestrutura por todos os nossos times, criamos o Genesis.
O Genesis tem como princípio idéias-chaves que nos garante focar nas soluções dos nossos desafios:
- Oferecer uma rede única compartilhada;
- Não permitir IP público em recursos;
- Oferecer uma camada de borda para publicação de serviços/endpoints de forma centralizada;
- Impor o isolamento entre os recursos de infraestrutura dos times;
- Garantir a política de acesso de menor privilégio (cada time pode ter N recursos de infraestrutura, porém permissão para operações apenas nesses recursos);
- Garantir que um time não possa interferir na estabilidade do recursos de outro;
O Genesis disponibiliza uma CLI (command-line interface) que permite aos nossos times de desenvolvimento criem novos recursos no Google Cloud, gerando templates de infraestrutura como código [ansible, terraform, packer] em diretórios padrões normalizados no repositório de código, e novos projetos do Google Cloud para segregar esses recursos.
A organização dos diretórios padrões normalizados no repositório de código também refletem a estrutura de projetos no Google Cloud.
Adotamos as melhores práticas para a organização dos projetos do Google Cloud, a criação da rede única compartilhada, organização dos códigos de infraestrutura, segregação de recursos e política de menor privilégio. Para quem curte referências, vão três boas aqui:
Como ferramenta de criação da infraestrutura adotamos o Terraform e Packer, para a gerência de configuração e deployment escolhemos o Ansible. Ao criar ou configurar uma infraestrutura, quem o utiliza não executa os comandos dessas ferramentas, os mesmos são abstraídos pelo CLI do Genesis.
Essas abstrações foram criadas com a finalidade de normalização, possibilitar a troca das ferramentas de automação sem alteração da CLI do Genesis, garantir a autenticação e autorização de quem está executando a automação no momento de cada execução (não salvamos a autenticação, a cada novo comando é preciso realizar a autenticação novamente) e assegurar que antes de aplicar as modificações dos recursos seja exibido o plano com as alterações que serão realizadas.
Para minimizar as dependências,tudo é executado dentro de containers docker, então você só precisa do Docker instalado e pronto.
Quando um novo projeto é criado pelo Genesis (bootstrap), ele resolve algumas complexidades, como criação do projeto de serviço no Google Cloud, definições de tags nos projetos, criação de recursos para salvar o estado do Terraform, criação dos templates no file system sempre respeitando uma estrutura normalizada.
Essa estrutura da automação foi criada para facilitar o manuseio desses múltiplos projetos para várias equipes. Você pode pensar em cada projeto e ou recursos como um namespace isolado na Cloud. Tanto o layout dos diretórios quanto a automação refletem essa estrutura, facilitando a análise de cada automação (e sua execução).
Utilizamos o Genesis de outras formas: compartilhamos bibliotecas (módulos do terraform, roles do ansible) e ferramentas (alguns scripts bash) voltados para automação desenvolvidas por nós, assim incentivando o reuso e colaboração na manutenção desses códigos.
Criamos e entregamos alguns recursos como serviços considerados como “paved way” para outros times (de produtos), por exemplo oferecemos um cluster GKE e o acesso a ele via Genesis abstraindo toda a complexidade como túneis e autenticação e autorização, assim os times de produtos possuem carga menor com operações e conseguem focar nos seus objetivos de produtos.
“Para finalizar, resumir essa história…”
Hoje, o Genesis é o nosso repositório único de infraestrutura como código e o maior case de projeto Open Source Interno da Neoway. Além disso, ele é responsável por propagar uma série de boas práticas de desenvolvimento na empresa — o que, definitivamente, não é pouca coisa.
Gostaríamos também de agradecer todas as pessoas envolvidas nessa jornada (impossível citar todos vocês).
Para quem ficou curioso, aqui vão alguns números do projeto:
Área de Engenharia (pessoas): 119
Estatísticas do projeto Genesis até o dia 18/07/2022:
Pessoas: 79
Commits: 7511
MR: 5.145 fechados
Tipo de códigos
HCL (Terraform): 53.18 %
YAML (Ansible): 36.43 %
Shell (Bash scripts): 5.29 %
Python (Módulo do Ansible): 4.42 %
Language Files Lines Code
Bourne Shell: 73 3073 1997
Terraform: 1745 58104 46119
Python: 1615 465761 330155
Markdown: 108 9302 6711
Makefile: 3 298 237
YAML: 4216 180168 160390
Autores: Luciano Faustino e Wilson Almeida
Curtiu o conteúdo? Não se esqueça de deixar seus comentários, dúvidas e compartilhar esse post nas suas redes.
A Neoway desenvolve soluções de Big Data Analytics e Inteligência Artificial que geram precisão para a tomada de decisão e produtividade para os processos de marketing, compliance, prevenção contra fraudes, análises jurídicas, gestão de crédito, entre outros.
Estamos contratando: para saber mais sobre as vagas disponíveis, visite nosso perfil oficial na Gupy.
