Estratégias que ajudam a potencializar o estrangulamento do legado na prática — Tiago Tartari
Aplicações legadas possuem um alto nível de complexidade, juntamente com a dificuldade de manutenções e implementações de novas features. Se a aplicação for antiga o cenário piora, neste momento precisamos agir com estratégia.
Nesse post quero “repregar os pregos” em relação ao Strangler Pattern e como, na prática, esse padrão tem me ajudado na decisão do estrangulamento de um legado.
Há medida que o tempo passa, temos observado que a tecnologia tem evoluído em um ritimo acelerado. Analisando os últimos 20 anos, podemos perceber claramente essa evolução.
Aplicações precisam evoluir constantemente! Empresas são cada vez mais dependentes da tecnologia para atingir seus objetivos.
Frequentemente ouvimos falar do sucesso da Uber, Netflix, IFood que são empresas com seguimentos diferentes, que, através da tecnologia atinge seus objetivos.
A Uber, procura oferecer a melhor experiência em mobilidade. A Netflix oferecer a melhor experiência em filmes e séries. Por fim, o IFood, oferecer a melhor experiência aproximando restaurantes das pessoas.
Dado o apelo acima, vamos para nosso objetivo, falar do Strangler Pattern.
O que já sabemos sobre aplicações legadas?
Sabemos que os sistemas, as ferramentas para desenvolvimento, a tecnologia e a arquitetura ficam obsoletos como passar do tempo, igualmente a forma que os sistemas são hospedados.
Assim também que aplicações legadas possuem:
- Alta dívida técnica;
- Número elevado de bugs;
- Alta complexidade cognitiva;
- Alto acoplamento;
- Dificuldade de novas implementações;
- Dificuldade de manutenção;
- Regras de negócios fragmentadas;
- Falta de confiabilidade;
- Impossibilidade de escalar
Tudo isso torna o legado cada vez mais difícil de manter, outro aspecto muito importante que não é tecnologia é a fuga de talentos.
Quais os riscos do “Precisamos reescrever o sistema”?
Com frequência comenta-se que “Precisamos reescrever o sistema”. Essa frase está associada ao fato de manter a aplicação legada em produção “rodando” e construir “outra do zero” de forma paralela.
Alguns riscos que me vem a mente ao escrever esse post:
- Criar uma aplicação em desalinhamento com negócio
- Migração de código para código moderno, porém com todos os problemas anteriores
- A aplicação no final passou a ser legada, devido o tempo para nova construção
- Falta de indicadores de sucesso na implantação
Objetivo para adoção do Strangler Pattern
Martin Fowler, nesse artigo, explica o padrão de estrangulamento, que basicamente consiste em:
“ The most important reason to consider a strangler application over a cut-over rewrite is reduced risk. A strangler can give value steadily and the frequent releases allow you to monitor its progress more carefully. Many people still don’t consider a strangler since they think it will cost more — I’m not convinced about that. Since you can use shorter release cycles with a strangler you can avoid a lot of the unnecessary features that cut over rewrites often generate. “
Assim que novas funcionalidades passam a ser migradas gradualmente para os novos serviços passamos a ter a percepção que o monolito está morrendo, a imagem abaixo ilustra essa graduação.
O padrão ajuda a minimizar os riscos de uma entrega única, AS-IS para código novo, e aumenta a percepção das entregas mais constantes, o que eventualmente deixa notório o “estrangulamento”.
Strangler Pattern só pode ser aplicado onde for possível interceptar o legado.
Sim é verdade. O Strangler Pattern trabalha com uma estratégia de proxy onde passa a rotear as funcionalidades do legado para os novos serviços.
A imagem abaixo reflete o roteamento
Com muita humildade, discordo dessa afirmação.
Dado o seguinte cenário: Imaginando um software com mais de 20 anos sendo utilizado na empresa, criado em VB6 com SQL, com regras de negócio em procedures e a mesma regra fragmentada por todo o projeto e que mesmo com todos os problemas do legado gera uma receita milionária para uma CIA.
Segundo a recomendação do padrão de estrangulamento eu não poderia utilizar estratégia, pois, não consigo interceptar as chamadas por ser um Windows Desktop.
Minha estratégia está em duas perguntas:
- Qual processo de negócio devemos migrar?
- Qual é o principal problema que vou resolver entendendo o processo que vou migrar?
Na minha experiência, duas perguntas matadoras.
Conclusão
A utilização do padrão de estrangulamento é uma boa estratégia. Quando alinhada as expectativas de negócio, potencializa de maneira gradual a troca do legado para uma aplicação moderna, diminuindo os riscos de implementação única após anos, permite a percepção de entrega contínua, tráz maior controle aos procedimentos internos da companhia, aumenta a confiabilidade e segurança das nossas aplicações.
Originally published at https://www.tiagotartari.net on September 25, 2020.
