O que é estrangulamento de aplicações legadas?

Por João Bosco - 28/Set/2016
  • Seja um dos primeiros a saber o que estamos escrevendo

  • Quando você pensa em estrangulamento, talvez alguma imagem dessas venha a sua cabeça. A imagem não deixa de fazer sentido, já que o estrangulamento no Jiu-Jitsu provoca a diminuição da oxigenação e no final das contas leva você a “desligar”.

    estrangulamento

    Se fizermos uma analogia com os nossos sistemas, o que buscamos com estrangulamento de sistemas legados é exatamente isso. Podemos resumir em 3 intenções básicas

    1. Diminuir o fluxo de uso do sistema legado
    2. Parar de construir novas funcionalidades no sistema legado
    3. Por fim, desligar o sistema legado por asfixia natural de suas funcionalidades.

    Note que todas as vezes que me refiro a estrangulamento de sistema legado, não quer dizer que isso se aplique apenas a sistemas inteiros. Isso pode servir como estratégia de refactoring para evolução de partes do seu sistema também.

     

    Estrangulamento na prática

    stranglerpattern

    Podemos falar de estrangulamento em vários níveis. Recentemente o termo me voltou a memória em uma conversa com um amigo, que citou um refactoring em classes de processamento de eventos do sistema dele.

    Ele me disse que iria aplicar um “estrangulamento” para fazer a implementação antiga conviver com a nova implementação durante um tempo, até que a equipe tivesse tempo suficiente para gradualmente reimplementar tudo.

    O uso do termo estrangulamento é mais comum na visão de arquitetura do que de refactoring de código, mas a aplicação nas duas áreas tem exatamente o mesmo sentido e intenção. O que muda são as soluções que você vai dar ao problema.

    Estrangular um trecho de código ou aplicação é fazer com que gradualmente, um novo “sistema” assuma o lugar do antigo, com período de convivência.

    Quantas vezes você já teve que trocar o pneu do carro com ele andando? Pensar no estrangulamento de aplicações e códigos legados pode te ajudar nisso!

    Partindo para a prática, existem uma serie de técnicas que podem ser aplicadas, Asset Capture, Event Interception, Extração de serviços, Extração de módulos, separação de frontend e backend entre milhares de outras coisas que podem ser feitas para tornar o estrangulamento realidade. O que vai ser realmente aplicado, depende muito do seu caso especificamente. Em um outro artigo vamos tentar discutir um caso real de um dos nossos clientes para que isso fique mais vivo e detalhado.

    Exemplos

    Se você tem uma arquitetura orientada a microserviços, vai achar que é relativamente fácil fazer o estrangulamento, já que todas as suas partes(serviços) provavelmente foram projetados tendo em mente que poderiam ser substituídos, sem afetar os demais sistemas ou mantendo um contrato mínimo de comunicação. Mas a vida não é tão fácil assim para a maioria dos mortais.

    Vamos tomar como exemplo um caso que tem se tornado recorrente em nossos clientes. Sistemas legados com muita lógica em procedures e triggers que tornam o sistema difícil de evoluir e manter.

    Muitas empresas tem cálculos e processamentos complexos relativos a baixa ou perda de um item de estoque. Esse é um domínio delimitado pelo qual podemos começar a estrangular nossa aplicação.

    Não vou entrar no mérito dos critérios para eleger as áreas do sistema que são boas para isso, porque essa discussão rende uma outra postagem.

    Poderíamos, a partir dessa visão de baixa de item do estoque, tirar um monte de código daquela procedure gigantesca e de quebra escrever um código obedecendo a uma nova/melhor arquitetura. Isso não quer dizer que esse novo trecho de código não precise de nenhuma interação com o código antigo. Talvez ele precise sim, mas cortar esse cordão umbilical entre os dois sistemas vai ser questão de tempo e evolução do novo. Afinal, o objetivo de todo estrangulamento é que um dia o novo substitua completamente o antigo. Abaixo uma figura que pode ilustrar isso do ponto de vista conceitual.

     

     

    adding_a_secure_microservice_alongside_a_monolithic_application

     

    Estrangular ou Reescrever

    A maioria das pessoas pensa que não existe dilema. Basta jogar tudo fora e reescrever o sistema! Do ZERO!!

    Claro, greenfield é sempre melhor do que brownfield! Esse é um consenso entre qualquer grupo de desenvolvedores que você consultar. Mas a decisão de reescrita do sistema, não depende apenas de aspectos técnicos. Muitas apostas e expectativas relativas ao negócio estão  em jogo.

    Se você está considerando reescrever completamente, certamente seu sistema não é muito grande ou muito complexo. Ou talvez você simplesmente não tenha passado por experiências de reescrita de sistemas.

    Fazer um sistema novo para fazer exatamente o que o antigo faz e mais algumas coisas, é muito arriscado!

    E quem já passou por essa experiência em grandes sistemas sabe disso. O risco vai desde o atendimento de expectativas dos usuários até a prisão em modelos mentais do sistema antigo.

    Isso tudo, sem falar que sistemas críticos não podem parar e dificilmente poderão ser inteiramente substituídos da noite para o dia. O estrangulamento gradual permite diminuir os riscos da evolução de sistemas, mas para isso, é preciso ter cuidado nas técnicas e tecnologias que serão utilizadas.

    Hoje em dia se fala em construir sistemas/serviços que facilitem seu próprio estrangulamento futuro, e isso não é a toa. A visão de que sistemas complexos são organismos vivos e precisam estar sempre em evolução para proporcionar os diferenciais competitivos que o negócio precisa, faz com que a visão de estrangulamento de aplicações seja extremamente realista e plausível.

    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. — Martin Fowler

    Se você quer discutir com mais profundidade técnicas para estrangulamento de aplicações para o caso da sua empresa, pode me mandar um e-mail em joao @ innovt.com.br

    Uma referência básica que podem ser útil para você entender um pouco mais sobre o conceito:

    http://www.martinfowler.com/bliki/StranglerApplication.html

     

    João Bosco

    João Bosco

    Ver Todos os posts
    João Bosco Seixas é consultor especialista em arquitetura de sistemas e trabalha com as principais plataformas de Cloud do mercado desde 2010. Acredita que somente através de inovação se pode garantir diferencial competitivo, por isso procura manter referências variadas de conhecimento, estudando assuntos diversos que convergem na criação de soluções inovadoras.
    Tem prazer em atuar como transformador digital conduzindo equipes e empresas a novos estágios de desenvolvimento, permitindo que sejam competitivas e estejam a frente nas inovações dos seus mercados.

    Nós da INNOVT aplicamos esse e
    outros conhecimentos em nossos trabalhos.
    Precisa disso para a sua empresa?

    Mensagem Enviada com sucesso!