Introdução
Dentro do meu time de desenvolvimento, costumo utilizar analogias com a construção civil quando trato de questões arquiteturais de sistemas. E não sou o único: diversos arquitetos com quem já tive o prazer de trabalhar também recorrem a esse tipo de comparação.
Construir software e construir uma casa têm muito em comum. Se você inicia uma obra com uma base frágil e paredes desalinhadas, tudo o que vier depois já estará comprometido desde a fundação.
E cabe a nós, pedreiros digitais, a responsabilidade de garantir que nossos sistemas não desabem em produção.
Neste artigo, vou abordar três estilos arquiteturais amplamente utilizados atualmente: Monolítico, Microserviços e Serverless.
Monolítico
A arquitetura monolítica é, provavelmente, a mais antiga e conhecida no desenvolvimento de software.
O primeiro ponto que precisamos quebrar é o preconceito: monolítico não significa errado.
Não há problema algum em utilizar um monólito. Pelo contrário, para projetos menores ou que ainda buscam tração, essa abordagem é extremamente comum e, muitas vezes, a mais adequada.
De forma simplificada, um sistema monolítico consiste em um único codebase, um único banco de dados e um único artefato de deploy.
Internamente, o código costuma ser organizado em módulos técnicos ou de negócio, sendo bastante comum a separação em camadas como DAOs, Services e Controllers.
O problema começa a aparecer quando o sistema cresce e passa a lidar com requisitos modernos, como alta disponibilidade e resiliência a falhas.
Imagine um cenário onde múltiplos desenvolvedores trabalham em funcionalidades distintas dentro do mesmo monólito. Após o deploy em produção, uma única funcionalidade com problema pode comprometer todo o sistema.
Nesse caso, a solução mais rápida costuma ser o rollback completo e, com isso, o trabalho de todo o time é impactado por um único ponto de falha.
Microserviços
A arquitetura de microserviços é uma evolução do modelo de serviços, amplamente difundido com conceitos como SOA, REST e WebServices, e ganhou força com iniciativas como o Netflix OSS.
Diferentemente do monólito, aqui o sistema é dividido em múltiplos serviços independentes, organizados de acordo com o domínio do negócio.
Por exemplo, em um sistema da área de saúde, poderíamos ter microserviço de relatórios médicos, microserviço de agendamento de consultas e microserviço de compras de medicamentos.
Cada serviço possui seu próprio repositório, seu próprio banco de dados e seu próprio ciclo de deploy.
Voltando ao cenário anterior: se um problema ocorrer, apenas o serviço afetado precisa ser corrigido ou sofrer rollback. As demais partes do sistema continuam operando normalmente.
No entanto, microserviços não são gratuitos em termos de complexidade. Eles exigem um nível maior de maturidade da equipe.
Alguns desafios comuns incluem maior complexidade no gerenciamento de deploys, necessidade de orquestração de serviços, definição clara de contratos e comunicação entre serviços, custos com infraestrutura (API Gateway, malha de serviços, etc.), maior exigência técnica da equipe e gestão de transações distribuídas (consistência eventual).
Serverless
O conceito de serverless está associado ao uso de serviços gerenciados por provedores de nuvem, como AWS, Google Cloud Platform (GCP) e Azure.
Ele se popularizou com soluções como o AWS Lambda, onde você deixa de gerenciar servidores e passa a trabalhar diretamente com funções.
Nesse modelo, seu deploy pode ser simplesmente uma função executável.
O poder do serverless aumenta ainda mais quando combinado com serviços gerenciados, como S3, DynamoDB, Aurora e SNS.
Nesse cenário, você deixa de se preocupar com capacidade de processamento, provisionamento de infraestrutura e escalabilidade, e passa a focar exclusivamente na lógica de negócio.
No entanto, é importante destacar: serverless não é uma bala de prata.
Uma utilização inadequada pode resultar em custos elevados, dificuldades de observabilidade e acoplamento excessivo a um provedor.
Conclusão
Escolher uma arquitetura vai muito além de decidir qual linguagem usar, qual banco de dados escolher ou qual framework adotar.
As decisões arquiteturais exigem respostas para perguntas mais profundas: quantos usuários o sistema precisa suportar? Qual nível de disponibilidade é necessário (24/7 ou horário comercial)? Quais são os possíveis gargalos? As transações precisam ser imediatas ou podem ser eventualmente consistentes?
Não existe arquitetura melhor ou pior.
Existe a arquitetura mais adequada para o problema que você está tentando resolver.