Uma estratégia para estrangulamento de aplicações legadas e transformação para microservices

A medida que um software envelhece, adicionar novas funcionalidades e aplicar mudanças para melhoria de performance pode se tornar incrivelmente trabalhoso. Em geral, quando a equipe começa a ter problemas com a complexidade e velocidade na evolução do sistema é o momento em que se cogita reescrever o software.

Infelizmente essa não é uma alternativa para muitos cenários. Construir um sistema novo pode ser muito caro, demorado e arriscado. Por isso o melhor caminho é pensar em estrangular a aplicação legada.

O que é estrangulamento de software?

Estrangulamento de software é o conceito que prega a transformação gradual de sistemas legados. Em um mundo de microservices, essa pode ser uma técnica útil para "quebra" de sistemas legados e migração para uma arquitetura de microservices.

Figura 1: Fases de um estrangulamento de software - Strangler Pattern

Utilizar o padrão de estrangulamento pode ser a resposta para gerar valor de forma incremental e com menor risco financeiro e operacional, se comparado com a abordagem "big bang" de reescrever todo sistema e muito comum no mercado.

Existem várias técnicas para fazer estrangulamento de aplicações, e a estratégia a ser adotada, depende do seu caso específico. De maneira geral podemos reduzir o processo de estrangulamento em 3 etapas:

Mudança

O primeiro passo para começar um processo de estrangulamento é escolher qual será sua estratégia de mudança. Esse é o momento de criação da nova aplicação e definições de como essas aplicações vão interagir. Em alguns momentos podem surgir escolhas difíceis sobre comunicação entre o legado e o novo e como manter integridade e performance para o consumidor.

Convivência

A aplicação legada e a nova aplicação terão que conviver durante o período em que a aplicação é estrangulada. O segredo para o sucesso em projetos de estrangulamento de longo prazo é estabelecer boas estratégias de convivência e release.

Desligamento

Etapa final do processo de estrangulamento, onde a aplicação legada sai inteiramente do ar. Em geral nessa etapa temos que fazer pequenas adaptações também na nova aplicação ou na infraestrutura, já que não temos mais a necessidade de "pontes" de convivência entre o legado e o novo. É possível trabalhar nesta fase com uma estratégia de uso de Proxy que fica entre a aplicação legada e o usuário. Como estratégia inicial, esse proxy não faz nada além de passar todo o tráfego, sem modificações, para a nova aplicação.

As 3 etapas do processo de estrangulamento levantam uma série de perguntas que devem ser respondidas de acordo com o caso particular de cada projeto. Pensando em facilitar o processo de estrangulamento, criamos uma estratégia inicial para auxiliar equipes no processo.

Estratégia - Quebrar, Rotear, Averiguar, Expandir

Figura 2: Quebrar, Rotear, Averiguar, Expandir

Neste contexto, o proxy opera no nível de requisição Web. Algumas páginas são manipuladas pela aplicação legada, e outras páginas são manipuladas por um novo serviço. Este redirecionamento pode ser baseado em várias abordagens:

• Endereço IP (de forma que os usuários dentro da empresa vejam primeiro o novo recurso);
• cookies;
• agente de usuário (user agents);
• Grupos de usuário com menor impacto para o negócio.

Quebrar - Como vou dividir minha aplicação?

A primeira etapa é tomar decisões sobre como a divisão de funcionalidades entre o sistema antigo e o novo sistema será feita. Pensando em um cenário de microservices um caminho natural é usar a abordagem de "bounded contexts". Entender o contexto que a nova aplicação irá atender e tentar não extrapolar responsabilidades é o primeiro passo para ter sucesso no estrangulamento.

Uma dica importante para esse momento é tentar sempre "quebrar" as peças com a visão de negócio e nunca com a visão técnica.

Quebrar - Compartilhamento de dados

Desde o início é importante pensar também nos dados. Da abordagem lógica, até a abordagem física. Compartilhar bancos de dados neste momento não é uma boa prática. Sempre que possível procure fazer o recorte da nova aplicação de forma que ela seja completamente independente. Em caso de necessidade de compartilhamento de dados com a aplicação legada, avalie o uso de replicadores de dados ou uso de padrões como Event Interception.

Fazer a aplicação legada lançar "eventos" de modificação de recursos para um stream de eventos/event sourcing é quase sempre a estratégia mais inteligente, mas nem sempre ela é possível em ser adotada.

Outra situação complexa e que frequentemente temos que enfrentar é fazer com que a nova aplicação atualize algo na aplicação antiga para que ela continue consistente. Muitas vezes essa dinâmica é causada por uma divisão errada do "bounded context". De qualquer forma, o grande desafio nesse cenário é evitar que a modelagem da sua aplicação nova seja influenciada pela aplicação legada. Então caso esse cenário exista na sua aplicação, procure deixar toda lógica de interação com o sistema legado de forma destacada, pois na etapa de desligamento, citada anteriormente, essa parte da nova aplicação deverá deixar de existir.

Figura 3: Compartilhamento de dados

Rotear

A estratégia de roteamento está atrelada a etapa de convivência do processo de estrangulamento. Para ter um roteamento efetivo devemos pensar em como o tráfego chegará na nova aplicação e além disso, devemos pensar em como essa operação poderá minimizar os impactos em casos de problemas com o novo código.

Se estivermos pensando no estrangulamento no nível de microservices, temos a opção de fazer o roteamento de chamadas através de gateways ou proxys conforme os diagramas já apresentados, mas também temos a possibilidade de deixar o sistema legado continuar a receber todo o tráfego e produzir eventos, de acordo com as ações realizadas. Nesse caso, o novo sistema apenas reagirá aos eventos disparados pelo sistema legado e realizará suas ações independentemente.

Figura 4: Roteamento baseado em eventos

Sistemas complexos tiveram anos de evolução e podem ter regras e situações de difícil reprodução, pensando nisso é importante levar a sério o aspecto operacional no momento de decidir a estratégia de roteamento. Algumas perguntas que podem ajudar nas definições são:

1. A aplicação nova receberá todo tráfego?
2. O tráfego será dividido por percentual ou por criticidade dos consumidores?
3. Em caso de erro no novo sistema é possível desabilita-lo via roteamento?

Essas perguntas vão ajudar em decisões como por exemplo, conheçer onde o tráfego deverá ser roteado, ou se será necessário utilizar alguma técnica como bulkhead isolation.

Averiguar

A averiguação do funcionamento da aplicação é uma etapa geralmente subestimada pelos desenvolvedores, por isso é importante que as intenções quanto a essa parte da estratégia estejam explícitas.

O monitoramento da aplicação é fundamental, mas além disso, queremos também garantir que as novas funcionalidades de negócio estejam de acordo com as saídas esperadas. Para isso devemos pensar em técnicas como testes A/B, traffic shadowing e até machine learning para detecção de anomalias.

A partir deste ponto, outros desafios vão surgir, como por exemplo, comparar os resultados do novo sistema com o legado, fazer o acompanhamento em tempo real, anotação de tráfego, entre outros. Esse é um processo contínuo e que tem que ser feito em produção, para que não existam distorções.

Expandir

O processo de expansão diz respeito principalmente a operação. Tendo em vista que a averiguação contínua está constatando que os resultados estão dentro do esperado, como nós podemos promover o novo software a ser a versão definitiva que recebe todo tráfego? Esteiras de deploy bem implementadas, gestão de configuração distribuída e uma boa plataforma de feature toggle são alguns artifícios que podem ajudar nesse processo. Esse processo está ligado a etapa de desligamento que citamos anteriormente, então é importante lembrar que alguns ajustes fora da nova aplicação também sejam necessários.

Conclusão

O processo de estrangulamento de software não diz respeito apenas ao time de desenvolvimento. É preciso envolver múltiplas disciplinas para ter sucesso nessa jornada. Conceitos de DevOps e SRE são muito importantes para alcançar a confiabilidade necessária e diminuir os riscos que uma migração de sistema traz naturalmente.

Este processo é uma ferramenta muito útil para substituir gradualmente uma aplicação legada e monolítica por uma arquitetura moderna e orientada a serviços. Os benefícios, comparados a uma reescrita tradicional, são claros: menos risco, lançamentos mais frequentes, melhor retorno do investimento e espaço para agregar valor. Além disso, como todas as funcionalidades são implementadas em novos serviços, um alto padrão de qualidade pode ser aplicado desde o primeiro dia que possua a seguinte abordagem:

• Desenvolvimento conduzido por teste e orientado a comportamento;
• Testes rápidos e abrangentes;
• Muita cobertura de código (uma regra de 80% de cobertura de código em todos os momentos, seria uma boa e agressiva abordagem);
• Entrega Contínua/Implantação Contínua.

Como sempre, existem algumas ressalvas. Dependendo da quantidade de funcionalidades, estrangular uma aplicação grande é um processo que pode demorar. É muito importante manter o foco na eliminação da antiga aplicação. Envolvimento e alinhamento de negócios é fundamental para que a estratégia funcione.

Sobre os autores