Ao longo do tempo, temos apresentado e discutido que há muitas razões para desenvolvedores escolherem microservices, e boas razões para evitá-los. Recentemente, Gene Hughson, experiente arquiteto de soluções e aplicações, escreveu um artigo mostrando como melhorar a modularidade de uma solução, provavelmente, não é uma das boas razões para a adoção de microservices. Opinião compartilhada pelo autor Simon Brown:
Você não precisa introduzir limitações relacionadas à rede com uma desculpa para escrever um código melhor.
.png)
Hughson disse:
Acredito que se você tem problemas para construir adequadamente um monolito, tentar implementar uma arquitetura distribuída para forçar modularidade pode, na prática, piorar o resultado.
De fato, como publicado em 2014, Brown e Hughson já debateram microservices e a analogia da Grande Bola de Barro (Big Ball of Mud). Na época, Brown disse:
Se você está construindo um sistema monolítico e ele está se tornando uma "grande bola de barro", talvez seja necessário você avaliar se está cuidando o suficiente de sua arquitetura de software. Você realmente entende quais são as abstrações estruturais fundamentais em seu software? Suas interfaces e responsabilidades estão claras? Se a resposta é não, por que acredita que ir para uma arquitetura de microservices irá ajudar? Claro, a separação física dos serviços vai te forçar a evitar atalhos, mas você pode conseguir a mesma separação entre componentes de um monolito.
Hughson compara um desenvolvimento utilizando microservices a icebergs, com muito mais acontecendo sob a superfície do que parece à primeira vista:
Se um time de desenvolvimento não consegue ou escolhe não seguir as orientações de design (por exemplo, requerimentos de modularidade), adicionar complexidade não deve proporcionar a solução adequada. Distribuir uma aplicação torna mais difícil reunir diferentes requisitos, apesar de não tornar impossível.
E Hughson ilustra o último ponto com uma link para outro tweet de Brown.
A discussão sobre monolíticos versus microservices é composta de diversos aspectos… Isso não engloba todos os aspectos, mas é um jeito de se olhar para a questão.
.png)
Voltando a se referir a seu comentário sobre equipes de desenvolvimento que não conseguem ou escolhem não seguir orientações de design, Hughson continua:
Afirmo que tornar mais difícil a quebra acidental de modularidade não endereça nenhum dos grupos que mencionei antes: aqueles que não podem seguir ou que escolhem não seguir as orientações. É irônico, mas aqueles que não conseguem entender a necessidade de modularidade podem ser muito criativos em suas "soluções", independente dos obstáculos. Aqueles que se recusam a seguir orientações também.
Hughson afirma que a distribuição (microservices são naturalmente distribuídos) como meio para a modularidade não é adequada. Também acredita que as preocupações não estão limitadas à arquitetura da aplicação, mas se aplicam da mesma forma à arquitetura dos dados.
Uma equipe disciplinada que constrói um monolito pode manter a modularidade numa arquitetura de dados monolítica. Equipes múltiplas separadas, tentando compartilhar uma arquitetura de dados monolítica, sentirão um nível insuportável de tempo gasto com governança ou uma quebra completa da modularidade.
No ano passado, Christian Posta mencionou o quanto gerenciar questões relacionadas aos dados de aplicações pode ser a parte mais difícil quando se muda para microservices. Na época, o InfoQ publicou sobre o assunto.
Ao construir microservices para um domínio razoavelmente complexo de uma empresa, precisamos encontrar as fronteiras entre as diferentes responsabilidades dentro deste domínio. Dentro de cada fronteira criamos um modelo do domínio, projetado para e representando esta responsabilidade. O modelo de cada área deve ser determinado pelo modelo do domínio desta área. Usando DDD (Domain Driven Design) podemos encontrar os limites e criar um contexto para cada área, com cada contexto se tornando um microservice.
Em resposta a um comentário sobre seu artigo, que sugere que algum tipo de governança deva existir, Hughson concorda:
Medidas passivas, sejam estruturais ("vamos distribuir os componentes de forma que ninguém possa quebrar a modularidade") ou procedurais (exemplo: "ser disciplinado") não serão suficientes. A governança no nível da aplicação (que é, na minha humilde opinião, o papel do arquiteto da aplicação) e mais acima são absolutamente necessárias para ajudar a reconciliar interesse concorrentes e garantir que o design não derive para caminhos obscuros. É indispensável ter em mente que isto pode ocorrer por mal-entendidos, falta de experiência, não seguir diretrizes ou mesmo incoerência no design. Alguém deve monitorar o que está acontecendo, e, tão importante quanto, o por quê dos acontecimentos.
Concluindo, é importante entender que Hughson acredita que microservices tem um papel na construção de aplicações que precisam ter componentes gerenciados, escalados e implantados independentemente. No entanto, as razões para seguir a estrada dos microservices devem ser bem entendidas.