Modernização de Legado através de Kubernetes

Uma abordagem realista!

Em primeiro lugar, se você acha que vou falar sobre adotar microsserviços, você não poderia estar mais errado, ok :D

Quando se fala em modernização partimos do lugar onde as empresas já possuem suas aplicações rodando, e claro que em 2023 muitas pessoas já ouviram falar de microsserviços, de Martin Fowler, de desacoplamento, de responsabilidade única e por aí em diante. Existem muitos artigos sobre o assunto por aí. Aqui, eu quero mencionar uma abordagem realista de modernização.

O ponto central deste tema, é que as empresas hoje já possuem suas aplicações e elas já estão ganhando dinheiro, então por que mexer em time que está ganhando? Porque este é o melhor momento para isso, já que o negócio não está enfrentando uma crise, por isso possuem tempo e dinheiro para investir com certa tranquilidade. A ocasião também é favorável para que o time dedique suas capacidades cognitivas para aprender e colocar em prática novas abordagens e processos.

Obviamente, este seria o cenário no mundo ideal. Afinal, sabemos que a aplicação já existente tem suas próprias demandas, como atualização, ciclo de vida, monitoração e operação. Deixá-la de lado para trabalhar em uma segunda versão não é possível.

É considerando os pontos citados que chego a uma abordagem de estrangulamento, ou Strangler Application Pattern, que para mim faz muito sentido e vou explicar um pouco mais.

Strangler Application Pattern

Nessa abordagem temos o legado coexistindo com as novas features e abordagens, então não temos aqui um momento de “virada de chave” e sim uma transição (o mais suave possível) entre versões. O mais importante aqui é o momento de planejamento e engajamento dos times, que terá como maior empecilho seguir implementando features no legado. Afinal, os times já o conhecem os processos antigos. Por isso, é tão importante alinhar o engajamento até mesmo com os times clientes, sem apertar prazos para que isso não gere desistência.

Aqui pode surgir uma dúvida: por que simplesmente não refazer do zero? Esse é um questionamento importante, pois refazer do zero implica em um grande investimento de tempo. Imagine que levou um ano para criar a aplicação existente. Mesmo com a experiência adquirida, seu time precisará de pelo menos 9 meses para dar à luz a nova versão. Quanto seu mercado pode mudar nesses 9 meses? Sua empresa tem fôlego para investir todo esse tempo em desenvolvimento? Por que não seguir com a estratégia de lançar features, testar e melhorar? Assim, durante todo o processo suas aplicações estarão evoluindo, seu time estará se aprimorando e não teremos nenhum ponto de ruptura no formato “tudo ou nada”, facilitando o erro e correção.

Quero voltar ao ponto de não-microsserviços ou uma abordagem realística. As necessidades de microsserviços são gigantescas. Trabalhar com desacoplamento por si só já é uma tarefa difícil, que depende de um ótimo planejamento e visão dos líderes. Ainda, esta abordagem requer bastante tempo para trazer resultados, visto que são muitas partes pequenas para serem construídas até que elas comecem a participar do processo. Por isso quero deixar aqui uma reflexão que Ross Garrett fez algum tempo atrás sobre “Miniservices”, onde a modernização vai acontecendo em fases sem saltar nenhum degrau, mantendo os serviços atuais rodando, criando serviços cada vez mais desacoplados e mirando em microsserviços. No entanto, sem a pretensão de atingir essa meta já na primeira fase.

Ok, e onde Kubernetes entra nessa história toda?

Kubernetes é a base para que toda essa transformação ocorra. Para que esse planejamento se torne realidade são necessários alguns pontos:

• Facilidade de criação
• Integração entre ferramentas
• Processos bem definidos
• Governança

A princípio, o enfoque deve ser a facilidade com que os times podem criar ambientes e ter disponibilidade para utilizá-los, claro que seguindo parâmetros de governança e processos. Entretanto, a integração entre os ambientes e ferramentas permite não engessar esses processos como foi o ITIL. Por exemplo, Kubernetes traz liberdade ao permitir integrar processos já existentes e, inclusive, automatizá-los, pois não faz sentido algum, ações como, ter que abrir uma GMUD para atualizar uma aplicação que já passou por processos de CI/CD. Porém, faz sentido ter este processo dentro de seu pipeline, que atualiza a aplicação a partir de uma alteração feita e aprovada numa branch.

Ter uma infraestrutura que possibilite a agilidade e escala necessária para essas mudanças é fundamental para o sucesso da modernização ou transformação de sua empresa. O nível de automação que o Kubernetes possui de forma nativa lhe dará não apenas essa vantagem como outros benefícios não computados, por exemplo: uma stack moderna onde seu time estará feliz de trabalhar, onde suas aplicações de todos os tipos poderão nascer padronizadas e suas equipes poderão trabalhar em features e não em manter a infraestrutura em pé.

Citei em diferentes parágrafos uma stack moderna ou cloud native, e talvez alguns podem pensar que essa é uma saída “overkill” ou uma bazuca para uma mosca. É importante clarificar o assunto, pois muito se fala da complexidade do Kubernetes e como sua robustez se aplica a grandes ambientes. Porém, o Kubernetes não foi desenvolvido apenas para ambientes gigantes e sim para ser a infraestrutura para todos os ambientes, pois a princípio toda aplicação precisa de recursos computacionais e são processos rodando em máquinas. É justamente esse o objetivo do Kubernetes, manter esses processos rodando e tarefas sendo executadas, simples assim.

Até aqui, trazer a resiliência e monitoração para uma aplicação que trabalha para manter outras aplicações rodando (e isso se aplica desde functions para suas API’s, uma loja virtual, streamings gigantes com milhões de API’s, até ambientes de machine learning operando Teras de dados, era uma tarefa do time de operações.

Kubernetes se encaixa em todos os ambientes e cenários. Podemos começar com ambientes pequenos e crescer à medida que for necessário para o negócio sem ter que criar uma stack, pois agora está num tamanho X.

Tenha ainda em mente que uma stack moderna e cloud native não é composta apenas por Kubernetes e aplicação. Considere fatores como monitoração, governança, pipeline, segurança, logging, tracing, isso sem falar das inúmeras aplicações que rodam dentro do próprio Kubernetes como Bancos de dados, Mensageria, API Gateways, Service Mesh, entre outros.

Então não trate essa questão como um sprint e sim como uma jornada que precisará de bastante empenho.

Aqui vão minhas dicas para uma modernização:

• Planejamento: Tenha um plano com objetivos e metas claras que possam ser medidas.
• Automação: Automatize tudo que for possível desde seu pipeline até os processos de governança. CI/CD e GitOps são ótimos pontos de partida.
• Veja que definição linda: “Entrega contínua é o processo repetível que permite uma entrega rápida, previsível, barata, frequente e de baixo risco de software”.
• Monitoração: É necessário medir tudo, não apenas aplicações, infraestrutura, mas também testes, entregas e as próprias metas.
• Comunicação: Mantenha o time atualizado, alinhado e motivado. Nada melhor do que um time engajado para completar um plano com sucesso.
• Elimine o “Tempo de espera”, esse com certeza é um ganho e tanto para as entregas.
• Documentação: Inclua no processo de modernização, existem hoje diversas aplicações inclusive de monitoramento como Calico Enterprise que exibem um mapa atualizado de suas aplicações e como elas se comunicam, isso é muito importante à medida que a quantidade de aplicações aumenta.

Minha dica final: Comece! Sente com seu time e inicie um planejamento para modernização de uma aplicação mais simples onde poderão aprender e quebrar algumas pedras e então seguir. E com certeza seria um prazer podermos participar dessa fase.

Para avançar nesta jornada, fale com um especialista.