Ao estruturar um novo produto que inevitavelmente necessita de suporte tecnológico, como uma série de APIs, banco de dados, websites e aplicativos, devemos selecionar um padrão arquitetural adequado. Dois dos padrões mais conhecidos são a Arquitetura Monolítica e a Arquitetura em Microsserviços.

Importante ressaltar que não existe um certo ou errado absoluto; cada padrão tem seus trade-offs.

Decidi escrever esse artigo para exemplificar alguns desses trade-offs, pois é muito comum vermos empresas adotando a Arquitetura em Microsserviços de forma precipitada e, por vezes, falhando devido à escolha de um padrão arquitetural inadequado para o momento atual da empresa.

Monólitos são frequentemente mal interpretados. Geralmente, ouvimos:

• Monólitos não escalam.
• Monólitos utilizam tecnologias ultrapassadas.
• Monólitos são lentos.
• Monólitos são pesados.
• Monólitos são caros para hospedar na Cloud.

O que não passa de grandes equívocos. Uma Arquitetura Monolítica bem feita consegue escalar perfeitamente tanto horizontal, quanto verticalmente, empregar tecnologias de ponta, ser extremamente rápida e, em muitos casos, ser mais eficiente do que invocar múltiplos microsserviços.

Em contrapartida, é comum ouvirmos tais afirmações sobre Microsserviços.

• Os microsserviços são rápidos.
• Os microsserviços são escaláveis.
• Os microsserviços são mais baratos.

Nada disso está errado, mas se você não seguir as boas práticas de programação e Devops nenhuma arquitetura se sustenta.

Dito isso, antes de aprofundar, aproveito para esclarecer que não estou aqui para defender Monólitos e nem Microsserviços. A minha ideia é apresentar alguns prós e contras de cada solução, além de casos de sucesso de cada uma das arquiteturas citadas.

Arquitetura de Monólitos (Monolítica)

 Em resumo, um Monólito é executado em um único processo e, geralmente, os códigos desse processo estão em uma única base de código, ou seja, um único repositório git (ou outro versionador de código).

Vantagens de uma Arquitetura de Monólitos

• É mais simples de fazer a implantação (deployment) no servidor, uma vez que pode ser somente um arquivo executável ou apenas um diretório de binários (dll’s, .exe) para copiar para o servidor.
• Fácil de fazer o build e executar testes, visto que é apenas um repositório de código para processar.
• Mais fácil de depurar (fazer o debug), identificar gargalos e erros, uma vez que precisa executar apenas uma solução / projeto / processo.
• Menor latência, pois tudo está no mesmo processo, compartilhando memória e não dependendo de fazer comunicações de rede (http) entre um ou mais serviços.
• Controle de transações (ACID) é muito mais fácil e seguro de implementar, pois a transação será gerenciada por um único processo.
• Monitoria e observabilidade são muito mais fáceis de implantar, pois bastará monitorar um único processo.

Desvantagens de uma Arquitetura de Monólitos

• Embora seja possível desfrutar de um desenvolvimento mais fácil ao trabalhar com esta arquitetura, é comum experimentar um tempo de desenvolvimento mais lento, uma vez que toda a base de código e componentes do aplicativo estão todos agrupados, principalmente quando temos muitos desenvolvedores atuando no mesmo código.
• A escalabilidade pode ser um pouco mais trabalhosa, pois todos os módulos do monólito vão escalar de forma igual.
• Se um módulo do monólito falhar, pode causar downtime na aplicação inteira.
• Uma vez definido a stack (linguagem / tecnologia) do monólito é mais difícil de trocar e de atualizar, pois tem um impacto sobre todos os módulos.
• A implantação (deployment) de novas versões e funcionalidades podem gerar downtime em toda aplicação.

Casos de Sucesso de Grandes Monólitos

Stack Overflow

O Stack Overflow é um exemplo clássico de um grande monólito que escala eficientemente para atender milhões de usuários. A arquitetura monolítica permitiu ao Stack Overflow manter a agilidade e a eficiência sem sacrificar a performance.

Amazon Prime

A Amazon Prime é um exemplo interessante de uma plataforma que migrou parte de seus microsserviços, anteriormente operando em uma infraestrutura serverless e enfrentando altos custos e problemas de performance, de volta para uma arquitetura monolítica. Isso evidencia que, em certas circunstâncias, monólitos podem ser mais eficientes e econômicos. Saiba mais detalhes sobre esse case aqui.
‍

Arquitetura em Microsserviços

A Arquitetura em Microsserviços consiste em dividir uma aplicação em serviços menores e independentes que podem ser desenvolvidos, mantidos e implantados separadamente. Aqui cada serviço possui sua própria lógica de negócios e banco de dados e tem uma finalidade específica. Atualizações, testes, implantação e escalonamento ocorrem dentro de cada serviço. 

Vantagens da Arquitetura em Microsserviços

• O desenvolvimento pode ser mais rápido se tiver equipes pequenas trabalhando em microsserviços diferentes ou bases de códigos diferentes.
• É possível escalar ou dimensionar os serviços de formas diferentes dependendo da carga e da necessidade de cada microsserviço.
• É mais fácil experimentar e implantar novas funcionalidades e recursos sem causar downtime em todo produto.
• Implantação (deployment) de novas versões e funcionalidades são feitas de forma independente, sem causar downtime em toda a aplicação.
• É possível ter diferentes stacks (linguagem/tecnologia) em cada serviço atendendo a necessidade de cada um.

Desvantagens da Arquitetura em Microsserviços

• Devido à quantidade de serviços diferentes, podemos enfrentar alguns problemas na gestão da grande quantidade de equipes. O uso de microsserviços adiciona mais complexidade em comparação com um monólito.
• Cada microserviço possui seu próprio conjunto de logs, o que torna a depuração mais complicada. Além disso, um único processo de negócios pode ser executado em diversas máquinas, complicando ainda mais a depuração.
• As diferentes equipes precisarão de um melhor nível de compreensão, colaboração e comunicação para coordenar atualizações e interfaces de cada microserviço.
• A comunicação entre os microsserviços utiliza processo de rede, como Http, Filas ou Streams e essa comunicação pode falhar em algum momento. Ou seja, é preciso ter processos de contingência e outros controles para que a informação não seja perdida e garantir a consistência dos dados.

Casos de Sucesso em Arquitetura de Microsserviços

Netflix

Essa é uma visão muito simplificada da Netflix, pois ela tem mais de mil microsserviços, e mais de dois mil engenheiros, divididos em mais de 100 times, servindo mais de 220 milhões de usuários.

Essa abordagem permitiu à Netflix inovar e escalar de forma independente entre os diferentes aspectos de seu serviço.

Uber

A Uber opera com mais de 4.500 microsserviços e mais de 4 mil engenheiros, facilitando a escalabilidade e a manutenção de sua vasta operação global. Eles separam esses serviços por domínios e essa arquitetura é o que permite que diferentes equipes na Uber desenvolvam, testem e escalem seus serviços de forma independente e eficaz. Mais detalhes é possível ver no blog da Uber. 

‍

Principais diferenças entre Monólitos vs Microsserviços
‍
1. Complexidade

Arquitetura Monolítica: Alta complexidade interna, implantação mais simples.
Arquitetura de microsserviços: Menor complexidade interna, implantação mais complexa

‍2. Design

Arquitetura Monolítica: Base de código única com várias funções interdependentes.
Arquitetura de microsserviços: Componentes de software independentes com funcionalidade autônoma que se comunicam entre si usando APIs.

3. Desenvolvimento

Arquitetura Monolítica: requer menos planejamento no início, mas fica cada vez mais complexo de entender e manter.

‍Arquitetura de microsserviços: requer mais planejamento e infraestrutura no início, mas fica mais fácil de gerenciar e manter com o tempo.

‍4. Implantação

Arquitetura Monolítica: Aplicação inteira implantada como uma única entidade.

‍Arquitetura de microsserviços: Cada microserviço é uma entidade de software independente que requer implantação individual.

5. Depuração

Arquitetura Monolítica: Rastreie o caminho do código no mesmo ambiente.

‍Arquitetura de microsserviços: Requer ferramentas avançadas de depuração para rastrear a troca de dados entre vários microsserviços.

‍6. Modificação

Arquitetura Monolítica: Pequenas mudanças introduzem riscos maiores, pois afetam toda a base de código.

‍Arquitetura de microsserviços: Você pode modificar microsserviços individuais sem afetar toda a aplicação.

‍7. Escala

Arquitetura Monolítica: Você precisa escalar toda a aplicação, mesmo que apenas determinadas áreas funcionais tenham um aumento na demanda.

‍Arquitetura de microsserviços: Você pode escalar microsserviços individuais conforme necessário, o que economiza custos gerais de escalabilidade.

‍8. Escolha da tecnologia

Arquitetura Monolítica: Geralmente limitada a apenas uma tecnologia.

‍Arquitetura de microsserviços: Possível escolher diferentes tecnologias para cada microserviço.

9. Consistência dos dados

Arquitetura Monolítica: Fácil de manter uma consistência forte

Arquitetura de microsserviços: Exige técnicas para garantir consistência eventual entre os microsserviços.

10 . Comunicação

‍Arquitetura Monolítica: As chamadas entre os métodos estão no mesmo processo

Arquitetura de microsserviços: Chamadas de rede, pode ser necessário de outras camadas de infraestrutura como Gateways de API ou Malha de Serviços (Service Mesh)

11. Estrutura de time

Arquitetura Monolítica: Equipes centralizadas trabalhando em toda a aplicação

Arquitetura de microsserviços: Permite que times pequenos, estejam focados em apenas um microserviço, mas, esses times precisam ter uma boa documentação e comunicação para entenderem as fronteiras de cada microserviço.

12. Investimento

Arquitetura Monolítica: Baixo investimento inicial à custa de maiores esforços contínuos e de manutenção.

Arquitetura de microsserviços: Investimento adicional de tempo e custo para configurar a infraestrutura necessária e desenvolver a competência da equipe. No entanto, economia de custos, manutenção e adaptabilidade a longo prazo.

Quem desejar se aprofundar um pouco mais nas nuances de cada um, indico esse vídeo da Zup Innovation:

Como podem ter percebido, a escolha entre monólitos e microsserviços depende de vários fatores, incluindo a escala do projeto, o tamanho e experiência da equipe e a infraestrutura disponível.

Uma Arquitetura de Monólitos Modulares pode ser ideal para startups, enquanto organizações com equipes estabelecidas e robustas práticas de DevOps podem se beneficiar mais da arquitetura em microsserviços.

Espero que esse artigo tenha te ajudado a entender melhor as vantagens de cada uma para tomar uma decisão. Caso você precise de um suporte extra e aprofundamento em cada uma delas, eu indico as Mentorias IFTL.

O Tech Lead Program possui uma aula destinada para o tema com casos de usos reais, onde é possível entender melhor os reais impactos de cada uma, além de ter acesso a um framework que auxilia na escolha da arquitetura.

Entre os tópicos, essa aula também aborda:

• Principais padrões de arquitetura
• Event Driven
• Serverless
• Critérios para definir arquitetura para seus projetos