Eu realmente "quebro" um monolito em microserviços?

[kicolobo]

Direto vejo este questionamento nas redes: “quando devo quebrar meu monolito em microserviços?”

Hoje me peguei questionando se o modo como enunciamos a questão não está nos induzindo ao erro. Explico.

Normalmente a gente divide um sistema monolítico em componentes por que a manutenção do todo vai se mostrando mais complexa com o tempo. Então identificamos módulos naquela grande massa e aí, neste ponto, deixamos de ter um monolito puro e passamos a ter “fragmentos” daquele monolito original.

E então, só adiante, pensa-se em dividir estes novos componentes em componentes ainda menores e assim sucessivamente até chegarmos ao ponto de realmente podermos adotar o prefixo “micro” nestas criaturas. Micro no sentido de que “você consegue ter o sistema todo em sua mente”.

Talvez até seja possível transformar de forma direta um monolito em micro-serviços, mas é de fato viável? O que vocês pensam sobre isto?

[shikida]

Creio ser possível sim. Mas avaliar os custos e benefícios do esforço pode ser bem difícil. Um sistema distribuído não pode ser encarado da mesma forma que um sistema não distribuído.

[gutomcosta]

Opa, essa discussão é interessante. No meu trabalho atual, começamos a dividir o monolito em microsserviços, mas resolvemos voltar atrás e continuar com o monolito de maneira mais organizada.

Eu acredito fortemente que dá para manter um monolito organizado e, inclusive, tirando vantagens de alguns princípios importantes dos microsserviços. Dá para ter isolamento, baixo acoplamento e até isolamento de framework nos monolitos.

Aqui estamos usando uma abordagem chamada de Monolitos Modulares. A ideia é que podemos separar os módulos e manter o isolamento dentro de uma base de código única. Como no meu trabalho atual, temos alguns modelos de domínios bem complicados, optamos por usar boas ideias de domain driven design para fazer isso.

Agora respondendo a pergunta, eu não acho que transformar de forma direta um monolito em micosserviços seja o caso, mas é possível construir um monolito que seja bem mais fácil extrair os módulos quando for necessário. A ideia de atrasar essa decisão de ir para microsserviço é o que nos guia aqui.

Vocês acham que faz sentido?

[kicolobo]

Acho que faz todo sentido: a impressão que tenho é que muita gente confunde micro serviços com a necessidade de componentização das plataformas.

Monolitos podem ser modulares, e a gente tem até soluções interessantes pra isto. Eu penso em OSGi no mundo Java, por exemplo, ou mesmo os módulos que a gente tem nas versões mais novas do Java (que são uma versão bem empobrecida do OSGi ainda).

Ou mesmo carregamento dinâmico de código também. Mas isto acho que faz muito mais sentido (idem OSGi) quando penso em sistemas que vão ser instalados no cliente, on premise, e que cada cliente requer um ou mais módulos.

Vou até além viu… acho que a gente tem muito o que aprender na realidade é com o pessoal que desenvolve ERP e lida com este tipo de situação faz um bom tempo (décadas já)

[pedrohenriqueacruz]

Na hora de considerar microserviços, é importante levar em conta a independência das aplicações. muitas vezes a gente considera quebrar uma aplicação em microserviços e mantém alguns anti-patterns, como compartilhamento de banco de dados, aplicações interdependentes e muitas vezes, a gente acaba criando o que eu gosto de chamar de “macroserviços”.

a ideia de ser micro, tem muito a ver com responsabilidade, que podemos até fazer uma analogia ao SRP (Single Responsibility Principle) do S.O.L.I.D, que é aplicado em OO.

Microservices são lindos quando bem aplicados, mas envolvem um nível de complexidade bem diferente, principalmente em termos de comunicação

[bruno.eng.comp]

Muito legal essa discussão. Hoje a ideia que parece vigorar é que tudo tem que ser escrito em microsserviços. Essa definitivamente não é a verdade. Lembro de recentemente ter visto um vídeo sobre a arquitetura do Stack Overflow, que apesar do grande número de usuários, usa uma arquitetura monolítica.

Posto isso, acredito que a uma das vantagens dos microsserviços é justamente desde o começo tentar definir fronteiras bem claras para cada parte do domínio do negócio. Esse pensamento, como foi expresso por vários aqui, pode ser aplicado também aos monolitos, porém acredito que isso exige uma certa experiência da equipe desenvolvedora, dado que é mais fácil fazer algo mais “gelatinoso” nos monolitos, onde uma parte acaba invadindo a outra.

Sobre a migração de monolito para microsserviços, já comecei algo do tipo, mas infelizmente não houve apoio da gestão. Mas consegui perceber o seguinte. Idealmente, deve-se buscar a separação dos trechos de código com menos acoplamento em relação aos demais. Isso é intuitivo, mas nem sempre é seguido.

Os módulos mais aglutinados, devem então ser refatorados, para terem sua fronteira definida de modo mais claro ANTES da migração, pois se não, você terá que lidar com dois problemas complexos ao mesmo tempo (separação e aglutinação), e isso não é desejável.

Por fim, na migração para microsserviços, deve-se considerar que os benefícios obtidos (principalmente possibilidade de escalar partes específicas da aplicação e simplificação do código) vêm acompanhadas de uma maior complexidade na operação (necessidade de service discovery, políticas de retry, circuit breaker, orquestração de containers, etc).

Além disso, entendo que a utilização de microsserviços requer uma maior automatização dos passos, para que tudo funcione de maneira mais suave, em relação aos monolitos.