Escrito por: Jean Carlos M. da Silva
Outro dia, eu estava liderando uma sessão de mentoria para um grupo de arquitetos de software aqui na empresa, falando sobre system designs complexos. No meio da conversa, um dos questionamentos levantados foi “Como os sistemas eram construídos antigamente? Por que mudamos tanto?”.
Essa pergunta me fez parar e refletir. É fácil se perder no jargão do dia a dia – microsserviços, serverless, microfrontends – e esquecer a jornada que nos trouxe até aqui. A verdade é que não chegamos ao modelo atual porque ele é inerentemente “melhor”. Chegamos aqui porque cada arquitetura que criamos foi uma tentativa de resolver os problemas da anterior, e no processo, acabamos criando um novo conjunto de desafios.
A popularização de sistemas distribuídos, com “micro” serviços e “micro” frontends, não foi um almoço grátis. Ela trouxe consigo uma explosão de complexidade. De repente, uma simples chamada de função virou uma chamada de rede, sujeita a latência e falhas. O que antes era um stack trace simples para depurar um problema, virou uma caça ao tesouro distribuída por dezenas de serviços, exigindo um nível de observabilidade (logs, métricas e traces) que era impensável há uma década.
Começamos a ter que pensar obsessivamente em:
- Resiliência e idempotência, garantindo que uma falha em um pequeno serviço não derrubasse o castelo de cartas inteiro e que operações pudessem ser repetidas sem causar estragos. E, claro, a necessidade de uma cultura e práticas de DevOps maduras deixou de ser um diferencial para se tornar um pré-requisito de sobrevivência.
Então, que tal fazermos essa viagem no tempo juntos? Vamos pegar um café e desvendar como saímos de blocos de código gigantescos para essa galáxia de pequenos serviços, e o mais importante: o que aprendemos no caminho.
A Jornada no Tempo: Uma Breve História da Arquitetura Web
A evolução da arquitetura de software não foi uma linha reta, mas um pêndulo que oscila entre centralização e distribuição. Cada balanço foi impulsionado por novas demandas de negócio e novas capacidades tecnológicas.
A Era da União: Quando Frontend e Backend Eram Um Só
No início, a vida era (aparentemente) mais simples. Tínhamos o que hoje chamamos de arquitetura monolítica.Uma única aplicação, um único executável, era responsável por tudo: acessar o banco de dados, processar as regras de negócio e renderizar o HTML que o seu navegador exibia.
Pense em tecnologias clássicas que muitos de nós usamos:
- .NET Full Framework com MVC e Razor: Um controller em C# recebia a requisição, buscava dados no banco, montava um model e o passava para uma view Razor (.cshtml). O servidor, então, processava essa view, misturando código C# com HTML para gerar a página final que era enviada ao cliente. Tudo acontecia no mesmo processo, no mesmo servidor.
- Java com JSF e PrimeFaces: O mundo Java tinha uma abordagem similar com o JavaServer Faces (JSF). A lógica da interface era controlada no servidor, baseada em componentes e eventos.Bibliotecas como o PrimeFaces ofereciam um arsenal de componentes de UI prontos, como tabelas e gráficos, que aceleravam o desenvolvimento, mas a renderização final ainda era uma responsabilidade do servidor.
- Python com Django: O padrão MVT (Model-View-Template) do Django funcionava de forma parecida. Uma requisição chegava, uma view (que no Django age como um controller) orquestrava a lógica, e um template era renderizado no servidor com os dados do model antes de ser enviado como HTML puro para o navegador.
O trade-off aqui era claro: a simplicidade inicial era uma grande vantagem. O desenvolvimento era rápido, e o deploy era “só copiar os arquivos”.O problema era o acoplamento. Uma pequena mudança no CSS poderia exigir um deploy completo de toda a aplicação. As equipes de frontend e backend viviam em uma dança desajeitada, frequentemente pisando no pé um do outro.
A Grande Separação: O Advento das APIs e SPAs
A web começou a exigir experiências mais ricas e fluidas, parecidas com as de aplicativos desktop. Recarregar a página inteira a cada clique se tornou inaceitável. Foi nesse cenário que ocorreu a grande separação do frontend e do backend.
A revolução veio com as Single-Page Applications (SPAs). Frameworks e Bibliotecas como Angular, React e Vue.js mudaram o jogo. Agora, o servidor enviava uma página “casca” quase vazia e um grande pacote de JavaScript. O navegador do cliente se tornava o responsável por renderizar a interface, buscar dados e atualizar a tela dinamicamente, sem recarregar a página.
Isso forçou o backend a evoluir. Ele não precisava mais se preocupar em gerar HTML. Sua nova função era fornecer dados. Nasceu a era das APIs RESTful, que expunham recursos através de endpoints HTTP, geralmente retornando dados em formato JSON. O backend se tornou um provedor de serviços agnóstico, capaz de servir dados para um SPA, um aplicativo mobile ou qualquer outro cliente.
O benefício foi uma explosão de autonomia para as equipes e experiências de usuário incrivelmente ricas. Mas, como sempre, havia um preço: a complexidade foi transferida para o cliente, os tempos de carregamento iniciais aumentaram (o famoso “download de megabytes de JS”), e a otimização para motores de busca (SEO) se tornou um grande desafio.
Quebrando o Backend: A Ascensão da SOA e dos Sistemas Distribuídos
Enquanto o frontend se libertava, o backend monolítico continuava a crescer e a se tornar um monstro difícil de manter, testar e escalar.A solução foi aplicar o mesmo princípio de separação. A primeira grande onda nessa direção foi a
Arquitetura Orientada a Serviços (SOA).
A ideia da SOA era organizar a lógica de negócio em serviços reutilizáveis e independentes, que se comunicavam através de um barramento de serviços corporativos (ESB).Era uma tentativa de trazer modularidade para o nível da empresa.
Os microsserviços são, na verdade, uma evolução natural e mais leve dessa ideia. Enquanto a SOA era frequentemente mais pesada, focada em reuso corporativo e com compartilhamento de recursos (como um banco de dados central), os microsserviços levaram a autonomia ao extremo: cada serviço tem seu próprio processo, seu próprio banco de dados e é totalmente independente. Eles não surgiram do nada, mas sim dos ombros de gigantes como a SOA.
O Big Bang dos Microsserviços e o Efeito Netflix e a temida “Estrela da Morte”
Então veio o boom. Empresas como a Netflix se tornaram o pôster de sucesso da arquitetura de microsserviços. Eles migraram de um monolito que sofria com interrupções para uma arquitetura distribuída na nuvem, ganhando uma agilidade e resiliência sem precedentes. A promessa era contagiante: equipes pequenas e autônomas, escalabilidade infinita para cada funcionalidade e a liberdade de usar a melhor tecnologia para cada problema.
Mas o hype também teve seu lado sombrio. Muitas equipes, seduzidas pela promessa, começaram a quebrar seus sistemas sem um entendimento profundo de seus domínios de negócio. O resultado foi o que muitos chamam de “Monolito Distribuído” ou a temida “Arquitetura Estrela da Morte”.Em vez de serviços independentes, criaram uma teia de aranha de serviços altamente acoplados, onde uma mudança em um serviço exigia mudanças em dezenas de outros.
Isso é um exemplo clássico de entropia de software. A entropia, em software, é a tendência natural de um sistema caminhar para a desordem e o caos à medida que é modificado. A “Estrela da Morte” é a manifestação física dessa entropia arquitetural, onde a complexidade acidental gerada pelas más decisões de decomposição supera em muito os benefícios da distribuição.
A Vingança do Frontend: Microfrontends e o Retorno do SSR
O ciclo evolutivo, inevitavelmente, chegou ao frontend. As SPAs, que antes eram a solução, se tornaram os novos monolitos – “frontend monoliths” gigantescos e difíceis de manter. A resposta? Aplicar os mesmos princípios de decomposição, dando origem aos Microfrontends.
A ideia é quebrar a interface do usuário em funcionalidades que podem ser desenvolvidas, testadas e implantadas de forma independente por equipes diferentes.Isso resolve problemas de escala organizacional, mas, como era de se esperar, introduz uma nova camada de complexidade técnica na composição, comunicação e roteamento no cliente.
E aqui o pêndulo dá uma de suas oscilações mais interessantes. Para resolver os problemas de performance e SEO criados pelas SPAs pesadas, a indústria está voltando para o… Server-Side Rendering (SSR). Sim, a renderização no servidor está de volta, mas de uma forma moderna. Frameworks como Next.js (para React) e Nuxt.js (para Vue) combinam o melhor dos dois mundos: renderizam a página inicial no servidor para um carregamento ultrarrápido (ótimo para o usuário e para o SEO) e depois “hidratam” a página no cliente para que ela se torne uma SPA interativa. É o ciclo completo.
A Mesa de Trade-offs: Não Existem Balas de Prata, Apenas Escolhas
Fica claro que cada passo na evolução da arquitetura foi uma troca. Não existe uma “bala de prata”. Como Martin Fowler aponta, os microsserviços vêm com um “prêmio” de complexidade que muitas vezes não é considerado. A decisão de usar uma ou outra abordagem é um dos trade-offs mais críticos que fazemos.
O Valor do Monolito e o Custo da Distribuição
Para muitos projetos, especialmente no início, um monolito bem estruturado é a escolha mais inteligente. A abordagem “Monolith First” defende que se comece com um monolito e só se parta para microsserviços quando a complexidade do sistema realmente justificar.Os benefícios são inegáveis: desenvolvimento inicial mais rápido, depuração simplificada e uma sobrecarga operacional muito menor.
O custo da distribuição é real e multifacetado:
- Complexidade Operacional: Gerenciar centenas de serviços é um desafio monumental que exige automação pesada e equipes de operações maduras.
- Confiabilidade da Rede: Chamadas de rede falham. Isso é um fato. Sua arquitetura precisa ser projetada com isso em mente.
- Consistência de Dados: Manter os dados consistentes entre múltiplos bancos de dados é um dos problemas mais difíceis da computação distribuída.
O Pêndulo Oscila de Volta: Por Que os Monolitos Estão na Moda de Novo
Depois de anos de euforia com os microsserviços, a indústria está amadurecendo. Estamos vendo um movimento de reavaliação, um reconhecimento de que a arquitetura monolítica, quando bem-feita, tem um valor imenso.
O caso mais emblemático é o da Amazon Prime Video. A equipe responsável pela análise de qualidade de vídeo havia construído sua solução em uma arquitetura de microsserviços serverless. No entanto, eles enfrentaram custos operacionais altíssimos e gargalos de escalabilidade devido ao tráfego de dados entre os serviços. A solução? Eles migraram de volta para uma arquitetura monolítica. O resultado foi uma redução de mais de 90% nos custos de infraestrutura e um aumento na capacidade de escala. O problema deles não era inerentemente escalável de forma distribuída da maneira que foi modelado.
Essa história ecoa a filosofia do “Majestic Monolith” (Monolito Majestoso), popularizada por David Heinemeier Hansson (DHH), o criador do Ruby on Rails. A ideia é abraçar o monolito com orgulho, mas construí-lo de forma intencional e modular. Um “Monolito Majestoso” não é um “Big Ball of Mud” (grande bola de lama). Ele é bem estruturado, com componentes internos bem definidos e baixo acoplamento. Para equipes pequenas e médias, essa abordagem evita a complexidade acidental da distribuição, permitindo focar na entrega de valor.
Isso nos leva ao conceito de Monolito Modular. É o melhor dos dois mundos: a simplicidade de implantação e operação de um monolito, com a organização e os limites claros de uma arquitetura de microsserviços.
Conclusão: As Marés do Hype e a Rocha dos Fundamentos
Se há uma coisa que essa viagem pela história da arquitetura de software nos ensina, é que as tendências vêm e vão como as marés. O que hoje é a “melhor prática” amanhã pode ser um “antipattern”.
Arquiteturas são ferramentas, não religiões. Não existe uma solução universal. A escolha entre um monolito, microsserviços ou qualquer outra coisa depende do contexto: o problema a ser resolvido, o tamanho e a maturidade da sua equipe, e as necessidades do seu negócio.
O que não muda? Os fundamentos. Os princípios de bom design de software são a sua rocha, a sua bóia de salvação no meio do oceano de hypes. Independentemente de você estar construindo um monolito ou uma galáxia de microsserviços.
Hoje, vemos uma nova onda de hype com a Inteligência Artificial. Todos querem “usar IA”.
A lição que aprendemos com os microsserviços se aplica perfeitamente aqui: mantenha os pés no chão. O valor não virá de adotar a tecnologia pela tecnologia, mas de aplicá-la de forma ponderada para resolver problemas reais, com uma base sólida de engenharia.
No final das contas, nosso trabalho não é construir microsserviços ou monolitos. É resolver problemas e entregar valor. Domine os fundamentos, escolha suas ferramentas com sabedoria e nunca pare de questionar o hype.
Apoio: 5by5 | Soluções em Sistemas