Skip to main content
ilustração monolitico e microsserviços

Arquitetura de microsserviços x Arquitetura Monolítica

Ao longo da carreira de desenvolvedor enfrentamos diversas disputas de tecnologia.

Java vs C#, SQL vs NoSQL e Server-side VS Client-side são apenas alguns exemplos.

Eu pessoalmente achava que ficaria ileso dessas disputas, quando, há um ano, foi decidido o uso de microsserviços em um sistema que foi designado a mim e a uma equipe desenvolver.

Antes tínhamos uma grande arquitetura monolítica e pisávamos em um terreno relativamente tranquilo, mas como é de praxe no mercado de TI, muitas vezes, quando um conceito entra na hype, é necessário dar atenção para ele e novamente entrar em uma nova disputa.

A arquitetura de microsserviços estava com tudo, deixando para trás a antiga forma de arquitetar sistemas grandes e robustos, concentrados num grande “bolo” chamado de aplicação monolítica.

Hoje, gigantes do mercado como Netflix e Spotify, divulgam a receita do sucesso ao transformar sua gigante aplicação em mais de 500 microsserviços.

Por outro lado, alguns velhos conhecidos do mercado ficam indiferentes à nova hype, permanecendo com apenas um grande monolítico.

O que é arquitetura de microsserviços?

Quando alguém fala em microsserviços está falando basicamente em uma arquitetura. Claro, a Arquitetura de Microsserviços.

Com eles, as aplicações são desmembradas em componentes mínimos e independentes.

Diferentemente da abordagem tradicional monolítica em que toda a aplicação é criada como um único bloco, os microsserviços são componentes separados que trabalham juntos para realizar as mesmas tarefas.

Cada um dos componentes ou processos é um microsserviço. A vertente da arquitetura de microsserviços valoriza a granularidade e, claro, uma aplicação bem mais leve.

>> Leitura recomendada:
Como orquestrar contêineres? Na prática com Docker, Swarm e Portainer.

Microsserviços na Netflix

Josh Evans, da Netflix, explica certinho no vídeo abaixo como eles trabalham com microsserviços:

Neste vídeo, Josh Evans fala sobre como microsserviços podem ser caóticos, mas ao mesmo tempo abrem um universo inteiro de possibilidades.

Josh começa do básico, explicando a anatomia de um microsserviço e os principais desafios e oportunidades.

Se a sua decisão pende mais para a implementação de microsserviços, vale a pena ouvir o que ele tem a dizer.

Microsserviços: como foi a experiência?

Com toda essa febre por microsserviços ‘contaminando’ o mercado de TI, a equipe queria tomar logo a decisão e encarar esse novo desafio.

Esse foi o assunto em todos os momentos, durante uma semana.

Chegando ao trabalho, durante o almoço, durante o cafezinho pós-almoço, nos botecos de saideira e às vezes até na madrugada, quando surgiam novos tópicos para incrementar o tema.

Antes de me posicionar, busquei informações para entender melhor o assunto.

Li artigos e fóruns, assisti a vídeos e conferências internacionais. Todos os ventos apontavam para o uso da arquitetura de microsserviços.

Microsserviços era a resposta para praticamente tudo que viria pela frente, quase não havia pontos de vista que contrariassem seu uso. Era praticamente unânime!

“Ser Microsserviços ou não, eis questão!” 

A princípio, me senti atraído pela ideia e, junto com um time de desenvolvedores, trabalhamos para transformar nossa grande arquitetura monolítica em pequenos pedaços de microsserviços.

O caminho foi árduo e levou quase que um ano.

O processo foi gradativo. Criávamos um serviço para substituir aquele que estava no monolítico, jogávamos em produção e, quando estava pronto para funcionar, mudávamos a rota da url específica para atingir apenas o microsserviço, e não mais o da aplicação CORE.

O ano todo nos propusemos a retirar uma parte do CORE para virar um microsserviço separado.

Às vezes tínhamos domínios da nossa aplicação que tinham menos de 100 linhas escritas, que mesmo separadas se tornavam microsserviços.

A febre ainda estava alta, mas, naquele momento, comecei a me questionar se era a arquitetura de microsserviços, de fato, a resposta para nós.

Arquitetura de microsserviços x Arquitetura Monolítica

Não podemos deixar de atribuir vários ganhos que tivemos com a escolha de partir para a arquitetura de microsservicos, mas, ao mesmo tempo, muitos obstáculos tiveram que ser vencidos para viabilizá-lo no nosso projeto.

Além disso, os motivos ainda não eram o suficiente para resolver quebrar a aplicação em vários pedaços.

Antes de apontar alguns motivos importantes para tomar a decisão de transformar a aplicação monolítica em microsserviços é importante pontuarmos os pontos positivos de usar um ou outro.

Por que usar arquitetura de microsserviços?

Definição clara de domínios

Se você possui um microsserviço responsável pelo usuário, ele será a única referência para mexer em um dado do usuário, ou performar qualquer operação sobre ele.

Se outro serviço responsável pelo login precisa da informação do usuário, ele tem que estritamente buscá-lo a partir do microsserviço de usuário.

Escalabilidade

Quando quebramos uma aplicação monolítica e grande em várias pequenas, possivelmente conseguimos escalá-las de forma separada.

Supondo que um serviço de autenticação seja chamado várias vezes durante a sessão de um usuário, com certeza o stress sobre ele é maior.

Com microsserviços, podemos escalar apenas uma parte, ao invés de ter que escalar a aplicação como um todo, como ocorre em uma arquitetura monolítica.

A diversificação de tecnologia

Os microsserviços não necessariamente precisam ser escritos usando a mesma linguagem de programação.

Se cabe o uso de Python em determinado microsserviço, digamos que seja algo ligado a processamento de dados, por que não usar?

Por que usar arquitetura monolítica?

Fácil de desenvolver

O desenvolvimento é simples, principalmente quando ainda não são claros os domínios da aplicação.

Fácil manutenção

A manutenção também é simples, principalmente para quem gosta de debugar código. Fazer isso com microsserviços é difícil quando não se tem a ferramenta certa.

Apenas um deploy

Existe apenas um sistema para subir e nenhuma preocupação se este pode quebrar outros sistemas que consomem dele, simplesmente por não existir outros. É apenas um.

Além disso, configurar uma esteira de CI/CD para monolítico também é mais simples.

Fácil de escalar

Só existe uma forma de escalar um monolítico horizontalmente: aumentando o número de máquinas.

Tráfego de rede baixo

Pois como não há outros serviços para se comunicar, o uso de rede é bem menor. Notou que o principal ponto positivo de uma arquitetura monolítica é a facilidade de lidar com ela?

Exemplos de união de microsserviços e arquitetura monolítica

Sim, é possível ter microsserviços, ou serviços maiores, que são consumidos pela sua arquitetura monolítica.

Pode fazer muito sentido em diversas situações. Imagine que seu monolítico tenha um processo batch que roda assíncrono em um determinado horário.

Por que manter esse tipo de serviço dentro do seu código core? Ele pode, muitas vezes, ser responsável por gerar memory leak na sua aplicação, dependendo da quantidade de memória que ele usa.

Também por prejudicar o tempo de resposta, dependendo do processamento que ele consome na máquina.

Outro caso que faria sentido é um serviço que costuma realizar grandes processamentos.

Este serviço poderia ser apartado como outro serviço para ser escalado separadamente, muitas vezes gerando grandes economias no gasto com servidor.

Outro exemplo é com códigos legados, ou que seriam melhores se fossem escritos em outra linguagem. Nesses casos os microsserviços seriam uma possibilidade, mas não a única solução.

Transformar meu monolítico em 
microsserviços?

Para saber se é a hora certa de transformar sua aplicação monolítica em arquitetura de microsserviços você tem que entender um pouco da situação do seu projeto, ver se vale a pena trocar a facilidade por uma arquitetura mais robusta.

Para isso, tem que mensurar o quanto seu processo de CI/CD está automatizado.

Se não houver nem o processo, esta é uma tarefa que tem que ser consolidada antes de mais nada, antes de cogitar a arquitetura de microsserviços.

Digo isso pois lidar com o gerenciamento de inúmeros serviços, tanto na esteira, quando no deploy e monitoramento, exige um processo quase que totalmente automatizado.

Se você ainda está num ponto que julga não ser totalmente necessário usar arquitetura de microsserviços, por quê não fazer o meio termo dos dois?

A união de arquitetura de microsserviços e arquitetura monolítica

aperto de mãos

Como vemos, ambas as arquiteturas têm suas vantagens. É importante entender como você consegue o melhor de cada uma e, de certa forma, diversificar a composição dos seus serviços.

Se não for necessário ser exclusivamente microsserviço, então que não seja.

Se for interessante ter uma arquitetura monolítica por inteiro, pois o processo é consolidado e não gera falta de recursos no servidor, ou má produtividade da equipe, então continue deste jeito.

Não há necessidade de mudar apenas por estar dentro da hype, certo?

Atualmente gosto de levar essa discussão para frente com meus amigos desenvolvedores. Não costumo ser fanático, nem tomar nenhum partido extremo.

Eu sou Java ou C# dependendo do contexto e sempre penso: qual vai me atender melhor no que eu preciso?

Sou SQL quando a relação e modelo o faz diferença no projeto. Sou ServerSide quando preciso de simplicidade.

Em resumo, gosto da arquitetura de microsserviços quando há carência de recursos e tenho bem definidos os domínios. Caso o contrário, sei que meu enorme monolítico pode dar conta do recado.

E vocês, o que tem usado por aí? 🙂


Arquitetura de microsserviços x Arquitetura Monolítica
5 (100%) 18 votes