Quebrando um software monolito: Microsserviços vs. Sistemas Autocontidos

Texto de Olga Annenko, disponível em: http://www.elastic.io/breaking-down-monolith-microservices-and-self-contained-systems/


As publicações e discussões recentes de TI estão cheias de termos como “transformação digital”, “TI bimodal”, “desenvolvimento contínuo” e “agilidade”. Não há necessidade de discutir que arquiteturas monolíticas e aplicações monolíticas devem se tornar coisas do passado, cedo ou tarde – de preferência, cedo, é claro. E de fato os departamentos de TI são encorajadas a se afastar dos monolitos por causa de inúmeras razões perceptíveis e compreensíveis: manutenção complicada, muitas dependências, dificuldades de teste e implantação (o monolito só pode ser implantado como um todo.) Os monolitos são como o Triângulo das Bermudas para qualquer iniciativa ágil de TI.

Frequentemente, é sugerido trocar monolitos por microsserviços.

Microsserviços é hoje um termo bastante usado para se referir aos microsserviços quanto ao estilo de arquitetura baseado em microsserviços.

O conceito é um tanto fácil (com tradução aqui), é sobre construir uma aplicação feita de vários serviços pequenos, que podem ser implantados e mantidos independentemente, não possuem dependências mas se comunicam por mecanismos leves, e não possuem uma infraestrutura centralizada. É até possível escrever cada um desses (micro) serviços com uma linguagem diferente.

microservices-01-1

Há benefícios, sem dúvida: permitem facilmente uma implantação contínua, e algumas partes da aplicação podem ser alteradas, debugadas, e até trocadas rapidamente e sem afetar as demais partes. Com microsserviços, você não pode quebrar uma aplicação: se algo der errado, vai dar errado apenas dentro do seu microespaço, enquanto o restante da aplicação vai continuar funcionando como antes.

No entanto, como normalmente acontece com imagens brilhantes de um futuro perfeito versus a realidade sóbria, é mais fácil falar do que realmente sair do monolito para microsserviços.

Recentemente, fui para a conferência SEACON em Hamburgo (uma conferência pequena bem recomendada para pessoas de TI em um local fabuloso), onde assisti à apresentação “Uma Estrada Rochosa dos Monolitos em Direção aos Microsserviços” do Björn Kimminich, da Kuehne + Nagel.

O nome da apresentação, se você ler atentamente, já diz muito: “em direção”, mas não “para”. De fato, Björn mostrou que não faz sentido quebrar um monolito complexo em microsserviços. Ele também foi gentil em me deixar escrever sua história no blog, e aqui estou, compartilhando outra forma de se afastar dos monolitos, da forma implementada com sucesso em Kuehne + Nagel.

Apresento-lhes o Monolito KN Login

Kuehne + Nagel é uma empresa de transportes e logística fundada na Alemanha e agora com sede na Suíça. Provavelmente um dos produtos mais valiosos é a ferramenta de gerenciamento de cadeia de suprimentos chamada KM Login, construída internamente.

KN Login é uma aplicação altamente complexa que gerencia um número massivo de coisas diferentes. Para listar algumas dessas coisas, ele ajuda a rastrear seus produtos, e por “produtos”, quero dizer grandes containers; ele simplifica as operações e ajuda a gerenciar melhor seus ativos; ele garante controle proativo para ajudar a manter a integridade e a eficiência da cadeia de suprimentos; ele aprimora a comunicação e a colaboração com os parceiros; ele ajuda a rastrear se os containers com seus produtos estão expostos a condições ambientais ótimas, e, em caso contrário, avisa o pessoal responsável. Em resumo, é responsável por vários processos e operações.

KN Login foi desenvolvido desde 2007, e agora contém 1.500.000 linhas de código, e mais de 200 desenvolvedores já trabalharam nele no total. Além disso, é construído com uma variedade de linguagens: inicialmente, foi escrito com um framework Java Web construído internamente, que está profundamente incorporado na arquitetura do sistema, e portanto é impossível de ser substituído. Agora, a equipe de TI da Kuehne + Nagel recomenda usar um framework open source, como Spring, quando possível. Além disso, usa várias tecnologias de UI para realizar os requisitos e necessidades das diferentes unidades de negócio. Ao todo, o KN Login é uma mistura de JSP, jQuery, Swing/ULC, GWT/GXT. E possui um banco de dados monolítico, que é usado para operações, visibilidade e relatórios.

Como qualquer outra aplicação monolítica, o KN Login não era tão complexo lá no início (e provavelmente não se esperava que ficasse tão complexo), mas – novamente, como qualquer outra aplicação monolítica – ele cresceu para esse fardo de um milhão de linhas de código.

Agora, com essa variedade de códigos, linguagens e pessoas trabalhando nele, é bem fácil “quebrar” a aplicação. Basta usar uma classe errada no pedaço errado do código. Manter um software tão complexo é um desafio mesmo para uma TI experiente, imagine para pessoas novas na equipe. Ao mesmo tempo, o KN Login está envolvido em um número inimaginável de processos e passos, o que põe uma grande responsabilidade nas mãos dos desenvolvedores.

Na estrada para se afastar dos monolitos

A TI da Kuehne + Nagel se perguntava como deixar o software menos pesado e mais fácil de manter. De fato, Björn Kimminich compartilhou na sua apresentação algumas dicas valiosas que eu compartilho com vocês:

  1. A primeira coisa mais importante a se fazer agora é PARAR de adicionar mais coisas ao monolito, não importa quanto as unidades de negócio querem novas funcionalidades para certos módulos, ou adicionar módulos que precisam desesperadamente, ou deixar mais interativo ou amigável para o usuário. A única coisa que deve continuar é a correção de bugs e pequenas mudanças.
  2. Encontre as costuras no seu monolito. São basicamente os componentes no corpo do software que são mais desacoplados que outros. Podem até ser módulos que contêm vários componentes, mas é mais fácil falar que fazer. Você deverá procurar módulos inteiros que podem eventualmente ser cortados fora do monolito. Mas certamente depende da complexidade do software, ou quantos módulos o produto tem.
  3. Perceba que a maioria das costuras são apenas anseios, porque a dependência transitiva é tão complexa que tem todo o direito de ser chamada de inferno de dependência. Em outras palavras, os componentes são tão dependentes um do outro que é quase impossível separá-los.monolith-01
  4. Tente “dissecar” o monolito com o tempo, apesar do item número 3, nos projetos futuros que possam cobrir partes das funcionalidades do monolito. Para fazer isso, observe os alvos mais fáceis, os componentes para os quais serão adicionadas funcionalidades mais avançadas. Quando esses novos projetos entrarem no ar, você pode “desligar” os componentes do monolito, já que foram praticamente substituídos por novos projetos.
  5. Ir para microsserviços pode ser um passo muito drástico, especialmente para softwares monolitos, como o KN Login. A abordagem de “Grande Redesenho“, que é geralmente é defendida nos casos de migração para microsserviços, não vai funcionar aqui – você não pode separar tudo e construir um novo. Além disso, com um milhão e meio de linhas de código, você terminaria com centenas de microsserviços, o que não tornaria as coisas mais transparentes ou gerenciáveis.

Mas se ir para microsserviços não é a melhor forma de quebrar um monolito complexo, quais opções restaram para a TI?

Sistemas Autocontidos pode ser a solução

Geralmente, o conceito de sistemas autocontidos (SCS – Self-Contained Systems) é bem próximo dos microsserviços: você pega o monolito e quebra em partes menores e independentes. Mas diferentes dos microsserviços, eles são aplicações web autônomas e substituíveis.

A principal diferença entre os dois é que SCS são maiores que microsserviços, e dentro de um software haverão menos SCS que microsserviços. Outra diferença notável é que cada SCS possui UI, lógica de negócio e armazenamento autônomos, o que os torna bem flexível em termos de customização. A forma de integração preferida entre unidades de SCS deve acontecer no nível da UI, apesar de que também se praticam integração por APIs. Isso tudo permite construir unidades de SCS usando linguagens diferentes e mesmo bancos de dados diferentes, ajudando a resolver problemas específicos.

Assim, os sistemas autocontidos ajudam a evitar o “Grande Redesenho” e, ao invés disso, mudar para uma versão mais ágil de um software em passos pequenos e gerenciáveis, o que minimizaria o risco de falhar. A Kuehne + Nagel escolheu essa abordagem arquitetural para a plataforma de comércio eletrônico KN Freightnet.

O KN Freightnet foi um novo projeto para oferecer uma plataforma de eCommerce de logística, onde pequenos consumidores podem pedir cotações e reservas de forma fácil e guiada. A parte de cotação já estava presente no KN Login. O KN Freightnet basicamente duplicou essa funcionalidade, se tornando o projeto piloto para dissecar o monolito da forma que Kuehne + Nagel delineou: duplicar uma funcionalidade fácil fora do monolito, criar um software independente em torno dela, e desligar o componente no KN Login quando for seguro.

creating-first-scs-01-1

Inicialmente, o KN Freightnet só oferecia a funcionalidade de cotação para Frete Aéreo. Mais tarde, Frete Marítimo e Terrestre se interessaram em ter uma presença no eCommerce. Mas, em vez de adicionar os requisitos na aplicação existente, foram criadas novas unidades de SCS para cada modo de transporte, junto com unidades adicionais para interesses comuns ou funcionalidades especiais, como o Simulador de Tempo de Trânsito do Produto, totalizando 10 módulos, ou, falando em termos de SCS, totalizando 10 aplicações web autônomas, cada uma com sua UI.

Mesmo que tenha tomado 4 anos da equipe de TI da Kuehne + Nagel para que o software KN Freightnet chegar ao estado atual, a abordagem de SCS foi e ainda é, segundo Björn, a única forma viável de implementar uma aplicação complexa que se tornaria – de novo – um monolito. Atualmente, a equipe de TI da Kuehne + Nagel está trabalhando para separar mais  módulos do KN Login.

Fim. Quase

Tchau, Microsserviços,  Bem-Vindos, Sistemas Autocontidos? Talvez não tão rápido…

O exemplo da Kuehne + Nagel pode levar a conclusão de que as duas opções para quebrar um monolito são optar por microsserviços ou por sistemas autocontidos. Mas uma frase dita despreocupadamente por Björn Kimminich no fim da apresentação me fez buscar uma perspectiva mais ampla; ele disse que, talvez, quem sabe, eles partam para microsserviços depois dos SCS.

E, de fato, encontrei outro caso de uso emocionante compartilhado pela Otto, uma varejista enorme da Alemanha. Se o assunto é microsserviços, você precisa ler o artigo completo, mas aqui está o que me chamou mais a atenção:

Assim como a Kuehne + Nagel, a Otto tinha um software monolítico que cresceu sua complexidade significantemente com o tempo. E, assim como Kuehne + Nagel, a Otto decidiu quebrá-lo em sistemas autocontidos, ou, como eles chamam, “verticais“. Ao longo dos últimos anos, mais verticais ganharam vida, enquanto outras ficaram cada vez mais complexas. Então, a Otto decidiu dar mais um passo e dissecar os verticais em microsserviços. Para ver detalhes mais técnicos e, mais importante ainda, os benefícios alcançados, veja o artigo deles explicando porque escolheram microsserviços.

breaking-scs-into-m-services-01

O que é mais interessante, no entanto, é que os sistemas autocontidos podem ser um passo intermediário entre um monolito complexo e microsserviços.

Resumindo

Parabéns, se você leu o artigo do início ao fim. Mas, se não leu, aqui estão alguns pontos que você pode levar:

  1. Um software monolítico está fadado a se tornar um sofrimento de qualquer forma, mais provavelmente na manutenção. Então, mesmo como uma prova de conceito, evite começar com um monolito.
  2. Se você já tem um monolito complexo, você pode começar a pensar em quebrá-lo. Se você quiser quebrá-lo, mesmo que seu objetivo de longo prazo seja uma arquitetura de microsserviços, você pode começar com sistemas autocontidos (SCS) primeiro.
  3. Busque novos projetos que irão duplicar e, em seguida, substituir certas funcionalidades no monolito, ou seja, módulos dentro do monolito nos quais se deseja adicionar funcionalidades ou retrabalhar. Ao mesmo tempo, não adicione mais funcionalidades no seu monolito. Esteja preparado para o fato de que não conseguirá uma versão mais ágil do seu software da noite para o dia – pode tomar anos, mas vale a pena.
  4. Mesmo sistemas autocontidos podem se tornar grandes e pesados com o tempo. É quando você deve pensar em quebrá-los também, dessa vez para microserviços.
Anúncios
Marcado com: , ,
Publicado em Microsserviços

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: