Olá pessoal, hoje vou falar um pouco sobre um padrão detalhado pelo Fowler meses depois da minha saída do iMusica. Por sinal, há algo de interessante com esse padrão, pois era algo que alguns membros do meu time reclamavam e consideravam um anti-pattern. Vou aproveitar esse post vou tentar usar uma linguagem ainda mais informal que a de praxe.

O nascimento dos padrões

Na real, uma máxima você não pode ter fora da sua cabeça:

Padrões são escritos por pessoas que interpretam situações, problemas e soluções recorrentes e resolvem escrever sobre o tema.

Um padrão nasce da observação de um grupo de pessoas ou projetos que fazem algo de uma determinada forma (parecida ou idêntica) e que chamam a atenção do observador. O observador identifica o “jeitão”, técnica ou solução para escrever sobre aquilo. Assim nasce um padrão.

Se você não entendeu as implicações disso, pense:

• Pessoas erram
• Muitas pessoas erram menos
• Várias pessoas chegam às mesmas conclusões

Os padrões são amadurecidos com o tempo, com a discussão, e com a notoriedade do próprio padrão, que quanto mais famoso, chama mais a atenção daqueles que de alguma forma compartilham daquele mindset, mas por sua vez, podem contribuir com algo diferente da versão original.

Contextualizando

Durante todos esses anos trabalhando com arquitetura de sistemas e soluções, cometi erros, mas os maiores erros cometidos foram em função de premissas equivocadas. Essas premissas geralmente eram trazidas em um telefone-sem-fio, onde na prática, seu eu revalidasse-as, com quem toma as decisões sobre cada uma delas, elas não existiriam ou seriam diferentes. Geralmente tornariam as coisas mais simples ou mais fáceis.

Para o iMusica, como tratava-se de uma restruturação de uma plataforma de backoffice grande, interdependente, a utilização do que mais tarde havia sido chamado de MicroServices era super interessante. Não havia um padrão definido, Fowler (que confesso não morrer de amores, mas respeito-o, e muito) não havia escrito em sua pedra de mandamentos o post microservices. Mas hoje, ao rever um texto bem interessante sobre Monolith Microservices, me deparei com um novo pattern do Fowler, dessa vez senti conforto na literatura do Fowler, algo tão corriqueiro quanto um eclipse lunar.

MonolithFirst

Nesse artigo, Fowler começa lembrando:

Quando ouço histórias sobre equipes que usam microservices, tenho notado um padrão comum:

Quase todas as histórias de sucesso de implantações de microservices começaram com um monolito que ficou grande demais e foi quebrado.

Quase todos os casos em que eu ouvi de um sistema que foi construído como Microservices a partir do zero, ele acabou em sérios apuros.

Este padrão tem levado muitos dos meus colegas para argumentar quando você não deve começar um novo projeto com microservices, mesmo se você tiver certeza de sua aplicação vai ser grande o suficiente para fazer valer a pena.

Esse artigo traz, a reboque, a lembrança de que existe mais de uma forma de se fazer Neston (e essa referência/trocadilho tem pelo menos 20 anos), assim como a necessidade de se repensar o que já foi pensado e sempre buscar formas mais eficazes para se gerar resultado com tecnologia.

O que eu tenho a acrescentar ao artigo, é uma característica inerente às restruturações. Para estas, não creio em modelo mais sadio do que usando MonolithFirst. E há diversos motivos para pensar assim:

• A maior parte das restruturações acontecem em virtude de demandas mal planejadas, pouca visibilidade e crescimento desordenado tanto das soluções, quanto das empresas ou projetos em si.
• A maioria das baselines de código legado não oferecem coesão suficiente para ser tomada como parâmetro para a separação e isolamento dos serviços.
• A reescrita e reengenharia de serviços demanda não somente conhecimento específico, mas conhecimento estratégico, que só se amadurece com o decorrer do tempo.
• O time que escreveu aquele código legado provavelmente irá te passar informações equivocadas, baseadas em premissas não muito bem fundamentadas. Será necessário revalidar todas, para garantir o sucesso da restruturação.

Ao passo que acredito que restruturações devam nascer de forma monolíticas, acredito que o know how sobre o projeto e o negócio, deva dar o norte para a separação de cada serviço. Nos últimos anos posso considerar facilmente 75% dos projetos que trabalhei baseados em Microservices.

O que eu uso

Em vez de abordar como deve ser feito, e como já disse, há diversas formas de se fazer a mesma coisa, gosto da abordagem monolítica com o isolamento e distribuição de serviços já na baseline inicial. Isso quer dizer que embora você tenha uma base de código unificada, talvez acesso a dados unificado, e talvez até desenvolver sem nenhum serviço (remoto), você terá em produção, serviços individuais, que carregam consigo as mesmas dependências. A escolha sob a utilização de um serviço remoto ou local gosto de que fique a cargo de configurações. Para o código de negócio isso precisa ser indiferente. Acredito que com o passar das releases, todo o desenho necessário para o isolamento definitivo, deva fazer parte do seu roadmap de evolução. Somente com esse know how, da nova plataforma, será possível avaliar com mais clareza como cada cooperação será coordenada e isolada, serviço-a-serviço.

Conclusão

SOA deixa seu legado, e MicroServices não é nada mais do que o resultado da escolha, quase que mediúnica e uníssona, dos mesmos subsets de conceitos e padrões remanescentes do soa. Assim, é possível concluir que diversas pessoas ao redor do mundo terão visões parecidas sobre o mesmo assunto.

A utilização de MonolithFirst é uma estratégia carregada de conservadorismo, mas se baseia nas premissas de que não há todo o conhecimento necessário durante a construção do projeto. E considero essa uma verdade quase universal. Acredito que não há uma forma universal para pensarmos um novo projeto Microservices, mas estou certo de que se você não possui uma visão extremamente clara, objetiva e detalhada do escopo, direção e design, você provavelmente cometerá erros extremamente caros. Sempre que você comete esse tipo de erro, o projeto paga com um conjunto de gambiarras irreparáveis.