Esta semana iniciei em uma nova empresa e ouvi, de um desenvolvedor mais experiente da equipe, que o principal produto que vou trabalhar havia sido desenvolvido como um Monólito e agora estavam sendo iniciados os esforços a fim de migrá-lo para uma arquitetura de Microsserviços. Eu já havia escutado esses termos mas não entendia bem o que eles implicavam, então fui buscar entendê-los melhor... Agora com esse conhecimento adquirido, venho compartilhar as diferenças que vi entre esses dois tipos de arquitetura.
O que é um Monólito?
A palavra monólito faz referência a um monumento formado por um único bloco de pedra e isso nos explica muita coisa!
Um software que adota uma arquitetura Monolítica tem todo seu código e funcionamento concentrados em um só processo. Logo, todas as funções do negócio estão dividindo os mesmos recursos de uma mesma máquina.
Vantagens
- Novos desenvolvedores vão ter uma maior facilidade de entender o projeto, pois todo o código se concentra em um único lugar.
- O desenvolvimento inicial é mais fácil e rápido. Além de, enquanto pequeno, possuir baixa complexidade.
Desvantagens
- Acarreta a uma difícil manutenção no futuro, quando ao alterar parte de uma funcionalidade é criado um efeito cascata (que pode causar comportamentos inesperados) em outras funções que estão ligadas de alguma forma. Afinal, há uma alta dependência de componentes do código.
- Seu principal ponto negativo: escalabilidade. Ou melhor, a falta dela... Por todo o funcionamento estar integrado, não podemos escalar uma função individualmente, é necessário que todo o produto se expanda em conjunto.
O que é um Microsserviço?
Um sistema que utiliza uma arquitetura de Microsserviços é composto por partes menores. Enquanto o Monólito é uma grande e única pedra, aqui temos diversas pedrinhas.
Nesse tipo de software vamos ter um código dividido em vários projetos que se comunicam entre si formando o produto final. Assim, cada serviço é criado de acordo com um conjunto de regras de negócio específicas, sendo implementado de forma independente.
Vantagens
- A manutenção se torna mais fácil por se trabalhar com partes menores de código e que não vão gerar problemas nos outros serviços do sistema.
- Cada parte do software pode ser desenvolvida com a tecnologia que melhor se encaixa nela, sem a necessidade de ter o projeto todo usando uma única linguagem, por exemplo.
- Fazer o deploy de um microsserviço é muito mais simples, facilitando a chegada de atualizações à produção.
- A escalabilidade está presente, de forma que se torna possível expandir apenas os microsserviços desejados conforme a necessidade daquele momento.
Desvantagens
- Como temos um sistema distribuído, deve haver alguma forma de conectá-lo e trabalhar nisso traz uma dificuldade adicional ao projeto.
- O aprendizado é dificultado para desenvolvedores que entrarem no projeto ao longo de sua criação tendo que compreender o funcionamento de diversos serviços.
Suas diferenças
Acredito que agora você já tenha entendido o conceito dessas arquiteturas e caso não, podemos resumir "Monólito vs Microsserviços" como "Centralizado vs Descentralizado". De um lado temos um grande bloco de código e, em outro, pequenos blocos interligados por conexões.
Ao olhar as vantagens e desvantagens de cada arquitetura entendemos que:
- Enquanto Monólito é fácil de um novo integrante do time aprender, o Microsserviços pode complicar o aprendizado, inclusive na maneira que foi escolhida fazer a ligação entre os serviços.
- Monólitos são eficientes para POCs (Prove of Concept) por terem baixa complexidade inicial. Porém, como não possuem boa escalabilidade, caso queira levar o projeto a frente faz sentido convertê-lo para microsserviços.
- Prestar manutenção em um Monólito é mais trabalhoso, enquanto nos microsserviços a independência do código leva vantagem.
Conclusão
Se você está na dúvida entre qual arquitetura seu produto deve utilizar, acredito que uma boa alternativa é aproveitar o melhor dos dois mundos, iniciando o sistema com a utilização de uma arquitetura monolítica e tornando-a descentralizada quando a necessidade de escalabilidade chegar.
É isso que ocorreu com o produto da nova empresa em que estou trabalhando e após meus estudos somado à escrita desse artigo entendi o por quê dessa mudança estar sendo feita.
Este é o primeiro artigo que escrevo e o conhecimento compartilhado foi adquirido do meu próprio estudo então caso tenha algo a acrescentar ou corrigir, não hesite.
Espero que esse artigo contribua com a comunidade e até a próxima! 😉
Top comments (4)
Oi Vitor,
Alguns contrapontos sobre as vantagens the micro serviços que vejo repetidas mas nao sao necessariamente "bem assim":
Isso pode ser uma desvantagem, pois em micro serviços realmente desacoplados, não temos visibilidade dos impactos que uma mudança pode acarretar. E quando problemas acontecem, temos agora a complexidade adicional de debuga-los em um ambiente distribuido. Entao nao e necessariamente uma vantagem. A forma de se mitigar isso e ter uma suite de testes robusta, o que se aplica a monolitos ou microsserviços, o que não é exclusividade de uma arquitetura ou outra.
Imagine que você é responsável pela equipe que suporta tal solucao. Mesmo com microsserviços, se o stack eh consistente (mesma linguagem/ferramentas/infra), então em teoria todo o time pode suportar toda a solucao, e mudanças no time sao mais faceis de se lidar. Agora, se apenas Bob conhece a tecnologia do serviço X, e Bob fica doente, ou se muda para Tonga, você necessariamente terá de procurar alguém para substituir Bob.
E claro, existem raríssimas exceções em que faz sentido otimizar um serviço para tecnologias especificas, mas (em minha parca experiência) não é um fator especialmente comum.
Fazer deploy de um microsserviço não elimina a necessidade de coordenar com servicos upstream/downstream, que podem não tolerar a indisponibilidade do microsserviço em questão, o que no caso nao depende de o serviço ser micro ou monolito, mas de outras considerações que independem dessa escolha. Algo que facilita o deploy de um serviço, seja mono ou micro, eh que o ecosistema seja construido para tolerancia a falhas, onde a indisponibilidade de um componente, por exemplo, não afeta o funcionamento de outros.
Ha 20 anos atras, escalabilidade era realmente um bicho papão, segundo o qual se um erro na capacidade necessária para um sistema teríamos que comprar novos servidores, o que levava semanas (meses), e era um processo realmente burocratico. Nos vivemos a era de cloud, escalabilidade e também elasticidade.
É incomparavelmente mais simples escalar sistemas em nuvem, tanto vertical quanto horizontalmente.
Isso sem citar que escalabilidade não é inerente a micro servicos. Já vi exemplos de soluções que faziam apenas uma coisa, em um unico processo, mas funcionava com bloqueios que efetivamente impedia sua escalabilidade horizontal (que é preferida em um número considerável de casos)
O que quero dizer aqui é que a margem que se tem entre uma versão inicial de um monolito e o momento em que sua escalabilidade se torna um problema dificil de se resolver na nuvem é consideravelmente maior hoje em dia.
Em tempo, gostei da estrutura do artigo, espero que continue escrevendo, e recomendo escrever em inglês também, pois a audiência aqui é maior.
Cheers !!
Olá dmondev!
Fico feliz que tenha gostado da estrutura do artigo e agradeço também por compartilhar suas opiniões e informações.
Como eu disse durante o texto, o que escrevi foi resultado do meu estudo então de fato não tenho todos conhecimentos sobre o assunto. Entendi seus contrapontos e acredito que realmente nenhuma arquitetura vai ser perfeita para 100% dos casos, sempre haverá desvantagens e situações onde as vantagens não são tão efetivas...
Mas enfim, novamente agradeço por participar da discussão e trazer novas informações :)
Tenho gostado de monólito modular!
Conhece essa arquitetura?
É bem interessante e não tem alguns dos problemas dos microserviços! Gerenciar as conexões entre eles por exemplo!
Pelo que ando percebendo, microserviços são o último recurso!
Uriel, ainda não tinha parado pra estudar esse tipo de arquitetura!
Agora com certeza vou dar uma olhada. Obrigado por comentar :)