Não comece com um monolito

…quando o seu objetivo é uma arquitetura de microsserviços.


Este texto é de Stefan Tilkov, disponível em: http://martinfowler.com/articles/dont-start-monolith.html


Nos últimos meses, ouvi repetidamente que a única forma de ter uma arquitetura bem sucedida de microsserviços é começando primeiro com um monolito. Como lembra Simon Brown: se você não consegue construir um monolito bem estruturado, o que o faz acreditar que será capaz de construir um conjunto bem estruturado de microsserviços? A mais recente, e como sempre convincente, interpretação desse argumento vem de Martin Fowler. Tomei algum tempo para pensar sobre isso. E fiz isso especialmente porque normalmente concordo com ele, e outras pessoas cujas visões eu compartilho também parecem concordar com ele.

Estou firmemente convencido de que normalmente começar com um monolito é exatamente o que você não deve fazer.

O começo da construção de um novo sistema é exatamente o momento em que você deveria pensar em quebrá-lo em pedaços. Eu discordo da ideia de que você pode adiar isso, como pensa Sam Newman, novamente alguém com quem eu concordo 95% das vezes:

Eu continuo convencido de que é mais fácil dividir um sistema velho e existente do que fazê-lo com um sistema novinho em folha. Você tem mais com o que trabalhar. Você tem um código para examinar, pode conversar com pessoas que usam e mantêm o sistema. Você também sabe como o “bom” deve se parecer – você tem um sistema funcionando para mudar, tornando mais fácil para você saber quando você tem algo errado ou quando você foi muito agressivo nas suas decisões.
— Sam Newman

Na maioria dos casos, será horrivelmente difícil, se não impossível, picotar um monolito. (Não quer dizer que seja sempre impossível, mas é um assunto para um post futuro.) Concordo que você deve conhecer muito bem o domínio para o qual você está construindo o sistema antes de tentar particioná-lo, mas o cenário ideal para particionar um monolito é quando você está construindo uma segunda versão de um sistema existente.

Se você é capaz de construir um monolito bem estruturado, você provavelmente não precisa de microsserviços. O que é ok! Eu concordo com Martin. Você não deveria introduzir complexidade de uma distribuição adicional no seu sistema se você não tiver um bom motivo para fazê-lo.

(Então, qual seria uma boa razão para usar monolitos? Há muitas, mas a mais importante para mim é permitir uma entrega rápida e independente de partes individuais dentro de um grande sistema. O benefício de microsserviços é poder desenvolver em paralelo porque estabelece uma fronteira difícil de cruzar entre as diferentes partes de um sistema. Fazendo isso, você torna difícil – ou pelo menos mais difícil – fazer a coisa errada: conectar as partes que não deveriam estar conectadas, e desacoplar aquelas que deveriam ter conexão forte. Em teoria, você não precisa de microsserviços para isso se você simplesmente tiver disciplina para seguir regras e estabelecer fronteiras claras na sua aplicação monolítica; na prática, acho que isso raramente ocorre.)

Você pode achar que há um número de microsserviços bem separados no seu monolito, só esperando para serem extraídos. Na realidade, é extremamente difícil não criar várias conexões, planejadas e não planejadas. A grande vantagem da abordagem dos microsserviços é dificultar alguém criar algo assim.

Se você começar com um monolito, as partes vão ficar extremamente acopladas entre si. É essa a definição de um monolito. As partes vão depender de características da plataforma que todos usam. Eles vão se comunicar com base nas abstrações que são compartilhadas, porque todos usam as mesmas bibliotecas. Eles vão se comunicar usando os meios que só existem quando estão rodando no mesmo processo. E esses são apenas os aspectos técnicos! Muito pior que isso, é que as partes vão (quase) livremente compartilhar os objetos de domínio, depender do mesmo modelo compartilhado de persistência, assumir que transações com bancos de dados estão prontamente disponíveis e que não há necessidade de compensação… Pode ser fácil refatorar as coisas e movê-las por aí – tudo na conveniente visão de um único projeto do IDE – mas é bem mais difícil cortar as coisas separadas novamente. É extremamente difícil separar um monolito existente em peças separadas.

Acredito – e a experiência em um número de projetos recentes confirma isso – que, quando você começa, você deve pensar nos subsistemas que você constrói, e construí-los tão independentes entre si quanto possível. Claro que você só deveria fazer isso se seu sistema for grande o suficiente para garantir isso. Se for só você e um colega de trabalho fazendo algo em poucas semanas, talvez você não tenha um sistema tão grande.

Mas, se você já começar com uma abordagem em que seu sistema é feito de partes menores, e as trata como sistemas individuais claramente separados, com seus próprios ciclos de desenvolvimento, implantação e entrega, e com a possibilidade de ter suas próprias arquiteturas internas, então você tem um conceito bem poderoso que vai ajudar a entregar um sistema.

E há alguma experiência para confirmar essa ideia? Sim, alguns sistemas com os quais estive envolvido recentemente mostraram que esse conceito funciona – considerando que estou falando de algo maior que o seu microsserviço típico. O mais proeminente é Otto.de, sobre o qual eu dei uma palestra junto com o líder de tecnologia deles (e sobre o qual você pode ler nesse resumo feito por um dos arquitetos). Também trabalhei com outros projetos assim, e continuo convencido de que é uma boa ideia começar construindo um sistema com essa abordagem – dado que você conheça o domínio muito, muito bem.

Mas há outra lição a aprender com essa discussão – uma mais geral: tome cuidado com as receitas de arquiteturas que são muito simples e muito óbvias. Essa – começar a esculpir seu domínio em partes separadas e independentes – não é uma exceção. Às vezes, um monolito é melhor, outras vezes, não. Se você decidir construir usando a abordagem de microsserviços, você precisa saber que, se, por um lado, será bem mais fácil tomar decisões locais em cada parte individual, por outro, será muito mais difícil mudar cada fronteira que permite isso. Refatorar algo pequeno se torna mais fácil, refatorar algo grande se torna mais difícil.

Como é sempre o caso com as discussões de arquitetura, não há como fugir do fato de que você precisa tomar uma decisão particular em cada caso.

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: