BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

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

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

Pontos Principais

  • Utilizar o padrão de estrangulamento pode ser a resposta para gerar valor de forma incremental e com menor risco financeiro e operacional;
  • 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;
  • Entender o contexto que a nova aplicação irá atender e tentar não extrapolar responsabilidades é o primeiro passo para ter sucesso no estrangulamento;
  • Em caso de necessidade de compartilhamento de dados com a aplicação legada, avaliar o uso de replicadores de dados ou uso de padrões como Event Interception são pontos importantes a considerar.

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

João Bosco Seixas (LinkedIn) MBA em gestão empresarial pela FGV e formado em computação. Atua promovendo transformação de equipes e empresas na área de tecnologia e desenvolvimento de software. Apaixonado por tecnologia, inovação e futurismo. Especialista em arquitetura de software com experiência em sistemas de alta complexidade, microservices e plataformas em cloud. Atualmente é Especialista em arquitetura de soluções digitais no Banco Itau S.A.

Marcelo Costa (LinkedIn) é pós-graduado em Engenharia de Software pela UNICAMP. Atua em sistemas de alta complexidade desde 2002, liderando equipes multidisciplinares no desenvolvimento de soluções de software nas áreas de varejo, aeroespacial, logística, educação, saúde e finanças. Especializa-se em liderança de equipes e arquiteturas de soluções, na coleta inteligente de informações na Internet e de conteúdo eletronicamente disponível; atualmente é consultor em Arquitetura de Soluções.

 

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT