O Strangler Pattern não tem esse nome à toa. Ele faz exatamente o que se propõe. Dá a ideia de estrangulamento para representar a supressão de um componente que será reconstruído de maneira independente, porém interligado, como microsserviço.

É uma solução que ajuda muitas companhias com projetos legados a modernizarem suas soluções e migrarem para microsserviços. 

Universo do monólito e necessidade de mudanças

As empresas tech quando nascem começam a se desenvolver e criar softwares, que são suas soluções para o mercado, muitas vezes desenvolvidas em monólitos. Ao criá-las, ninguém sabe o tamanho exato que a empresa vai alcançar.

Aos poucos, com novas soluções implementadas, a companhia começa a crescer, mudar e se adaptar.

Junto com a maturidade das empresas, as aplicações que surgem no modelo de monólito também vão ganhando melhorias, novas atualizações que, aos poucos, as tornam enrijecidas. Com isso, o custo para mantê-las aumenta e se torna impraticável fazer o desenvolvimento de qualquer mudança ou melhoria.

Quando uma aplicação em um monólito passa anos sendo construída por completo em um mesmo ambiente, ela fica muito “pesada” e lenta. Não dá para fazer coisas rápidas com um software que está há muitos anos no ar, em uma mesma estrutura de desenvolvimento rígido.

Exatamente por isso, se algo dá errado e algum bug aparece, fica difícil identificar a origem e a solução.

É por isso que qualquer desenvolvimento e mudança técnica dentro dessa solução de monólito acaba sendo muito complexa.

Os softwares mais antigos, aqueles sistema legados, que têm muitos anos de existência, apresentam maior dificuldade para adaptação ou melhorias.

O motivo é que eles não foram estruturados para comportar a dinamicidade que a gente tem hoje. A tecnologia vem se reescrevendo a cada 2 anos. E nesse período, tudo o que a gente conhece, todos os padrões de projetos e conceitos que são aplicados e atualizados, podem mudar e em pouco tempo não serão mais usados. É tudo muito dinâmico.

A tecnologia está mudando a todo instante. A maneira de usar backend, frontend, microsserviços e diversas ferramentas muda muito rápido. Isso faz com que você precise estruturar sua aplicação com frequência.

Se voltarmos 5 anos atrás, não existia javascript sendo trabalhado da forma como é hoje.

Em outras palavras, é preciso adaptar todo o seu legado e tudo o que você já teve para esse universo novo.

Mas como fazer isso? Por que mexer em algo que já funciona?

Benefícios

Alguém sempre precisa desenvolver uma nova funcionalidade, um novo meio de pagamento ou fazer uma integração com alguma nova rede social, não é mesmo? E você percebe que a entrega começa a ficar demorada, com alto custo e com erros.

O benefício de “quebrar” essa aplicação em microsserviços é reduzir custos, acelerar a entrega e ter uma estrutura simplificada. Com esse compartilhamento, é possível ter um microsserviço criado em uma linguagem que não seja a mesma usada no core da aplicação.

Ou seja, passa a ser possível ter uma equipe multidisciplinar, com vários conhecimentos e várias linguagens em uso dentro da mesma aplicação. É como se eu tivesse vários fragmentos dentro da minha aplicação que se interligam. 

Por isso, se eu tiver uma falha em um dos microsserviços da minha aplicação, eu consigo de maneira independente e ágil, resolver apenas aquele problema daquele componente específico. Não preciso mudar e atualizar toda a aplicação, como seria em um monólito.

Essa componentização faz toda a diferença para a agilidade e sucesso de um negócio.

Como fazer? 

Reconhecer que é preciso facilitar as coisas na sua aplicação é o primeiro passo. Mas agora entra a maneira de como fazer tudo isso.

O que é melhor? Eu “quebro” a aplicação para refazer aquela parte específica que passará a ser independente? Ou eu refaço toda a aplicação?

Para fazer uma aplicação do zero, vamos usar como exemplo o tamanho robusto do Sorte Online. Nossa aplicação, já atualizada com microsserviços, componentes e estruturas independentes, está no ar há 17 anos e tem evoluído, recebido upgrades, melhorias e atualizações o tempo todo. Para refazer tudo isso de novo, imagina quanto tempo a gente iria levar? Outros 17 anos? Seria inviável.

Mas existem empresas que fazem isso. Porém, para começar do zero, é preciso criar uma estrutura de trabalho com pelo menos duas equipes trabalhando e dando manutenção. Ou seja, o custo aumenta.

O que fazer, então? Fico sem mudar minha estrutura? Se isso acontecer, a empresa fica sem crescer até que a aplicação seja atualizada, porque a aplicação atual não comporta o crescimento.

Strangler Pattern

O Strangler Pattern é um conceito novo do mercado, que permite literalmente estrangular aos poucos o seu monólito. Como em uma árvore que está com a raiz podre, o Strangler cria caminhos para envolver a árvore (a nossa aplicação) para que ela seja substituída aos poucos, sem perder o topo de árvore. Aos poucos começam a ser criadas estruturas menores, complementares, que vão manter a minha aplicação de pé e eu vou poder aos poucos substituir a estrutura anterior.

Geralmente para mudar de cloud, por exemplo, é preciso mudar todas as aplicações, todos os serviços, tudo o que está conectado com o grande core.

Esse conceito do Strangler Pattern significa justamente trazer camadas de serviços e a principal delas é o Data Event. Tudo que vai ser transitado dentro da sua plataforma, vai passar dentro dessa camada e essa camada vai começar a monitorar e estruturar.

É como se fosse um orquestrador de comunicação, que vai fazer com que tudo que ele receba de informações, de dados, além de tudo o que entrar e sair de dentro do seu software, seja monitorado e comece a te dar a vazão desses dados.

Tudo o que é alterado nos seus serviços, na sua aplicação, você começa a monitorar, e vai direcionando isso para poder consumir novos serviços.

Em outras palavras, é possível manter o seu legado, manter a parte antiga e pesada, só que agora um novo módulo que vai atualizar as funcionalidades da sua aplicação.

Sorte Online

Aqui no Sorte Online usamos dados estatísticos do setor de BI. Por trabalharmos com jogos online, a gente faz muita previsibilidade de apostas, com análise estatística e combinatória.

Uma equipe de BI olha nossos dados e sugere os resultados que têm maiores probabilidades de serem premiáveis. Essa probabilidade é baseada, por exemplo, no histórico de jogos e de premiações anteriores, de muitos anos de aprendizado do nosso sistema.

Para desenvolver um sistema como esse, não dá pra ser com um monólito padrão. Essa é uma API que pode estar apartada do monólito. Porém, conservando e consumindo informações dele.

É um serviço independente, mas conectado ao monólito padrão. A ideia é exatamente essa: ter a dinamicidade de quebrar o monólito para isolar funcionalidades que passarão a ser independentes, mas ainda conversando com a aplicação central.

A moral da história é que se estamos na era da revolução digital, precisamos estar atualizados com a melhor estrutura possível, para que nossos clientes consigam navegar de maneira intuitiva, sem demora e com satisfação.