Durante um período em que Steven Lemon e sua equipe tinha poucas funcionalidades para implementar, a liderança técnica da empresa em que trabalhava decidiu mudar o monolito existente para uma arquitetura de microservices. Após um mês de preparação, perceberam que a nova estrutura estava prejudicando o processo de desenvolvimento sem trazer nenhum benefício. Isso os surpreendeu, e consequentemente decidiram ficar com o monolito. A partir dessa experiência, Steven Lemon escreveu recentemente um estudo de caso das descobertas.
A aplicação estava funcionando com base em um produto externo de terceiros com um conjunto de serviços de backend entre o processamento de transformações das duas partes. O grande motivador das dificuldades em migrar para o microservices foi que havia uma incompatibilidade entre os domínios da própria aplicação e os domínios no produto externo. Essa incompatibilidade teve um impacto em como o domínio poderia ser dividido em microservices. Deixar os microservices seguirem os domínios no produto externo causaria duplicação da lógica. Com os microservices seguindo os próprios domínios, precisavam se comunicar com dois ou mais domínios do produto de terceiros, e para a equipe, essas formas pareciam uma violação das diretrizes de microservices, levando a um aumento na acoplamento.
Quando começaram a procurar formas de dividir o monolito, não encontraram candidatos óbvios para microservices. Portanto, começaram a dividir arbitrariamente os modelos de domínio, o que criou potencialmente uma lista de microservices, mas também muita lógica negócios compartilhada com alto acoplamento. Por isso, tentaram mitigar o problema dividindo os serviços em partes ainda menores, mas isso só aumentou os problemas.
Lemon observou que o principal motivo para não dividir o monolito foi o mesmo apenas lidava com apenas com um único negócio. Desde o início, tudo foi projetado para reunir conceitos diferentes do produto externo, algo em que vinham trabalhando há anos. A organização subestimou a importância de encontrar os limites, e com o resultado de que cada funcionalidade da aplicação estaria envolvida em mais de um microservice. No final, isso impediu que qualquer microservice pertencesse a uma equipe.
O outro problema era que não tinham uma plataforma pronta para executar os microservices e isso complicou a comunicação entre os mesmos. A solução foi duplicar a lógica compartilhada e as leituras comuns de armazenamento, o que eliminou a necessidade de comunicação, mas criou uma quantidade significativa de duplicidade.
Enfrentaram frequentes mudanças de requisitos, dificultando a localização adequada das separações dos domínios. O que estava bom em um dia, poderia ser derrubado alguns meses depois, exigindo outro conjunto de microservices. Além disso, tiveram um tempo bastante curto, impedindo-os de refletir sobre as escolhas de design, e a equipe não possuía experiência em trabalhos anteriores implementando uma arquitetura de microservices.
À medida que os problemas se acumulavam, começaram a perceber que não sabiam porque estavam tentando migrar para os microservices. Não tinham uma lista das dores e também não entendiam como todo o trabalho mitigaria os pontos que conheciam como problemas que deveriam ser resolvidos. Percebendo isso, fizeram uma pausa e analisaram quais benefícios o microservices oferecem e quais seriam realmente benéficos.
Com a arquitetura que tinham e devido aos compromissos que teriam de fazer na mudança para microservices, acabariam com um pool de microservices compartilhados por todas as equipes e recursos espalhados por vários microservices. Essa foi uma grande desvantagem que impediu muitos dos benefícios comuns.
Lemon também ressalta que já haviam muitas questões de infraestrutura resolvidas no monolito que precisariam ser abordadas novamente. Ao olhar para o monolito, observou-se que tinham muito poucos problemas. Era fácil trabalhar porque tinha uma configuração de CI/CD simplificando a implantação e a reversão. As estratégias de ramificação e teste garantiram que pouquíssimos problemas chegassem à produção.
No final, perceberam que um monolito não é por padrão algo ruim e nem sempre os microservices são algo bom. A mudança para microservices foi cancelada e começaram a procurar maneiras de melhorar o monolito. Refizeram a estrutura que tornou os modelos de domínio mais claros e indicaram áreas onde existiam acoplamento e duplicação. No final, isso também significava que, no futuro, poderiam encontrar facilmente candidatos para os microservices, caso fosse necessário.