O problema não é cloud nem microserviços: É a ilusão de escala

Marcelo Scheidt
Marcelo Scheidt
Autor verificado Autor verificado
25 junho

Depois de discutir como a cloud não resolve a imaturidade de um time nos artigos anteriores, surge uma pergunta quase inevitável: se não é a tecnologia, então onde está o problema?

A resposta costuma ser menos confortável do que parece. Na maioria das vezes, o problema é a forma como pensamos sobre escala.

A pressa de parecer grande

Existe um padrão que se repete em muitos times. Antes mesmo de resolver o básico, já existe uma preocupação em escalar: arquitetura distribuída, infraestrutura elástica, pipelines complexos, observabilidade completa. Tudo isso antes de ter clareza sobre o produto, do conhecimento de negócio, sobre o domínio e, principalmente, sobre o próprio fluxo de entrega.

É como tentar otimizar um sistema que ainda não funciona bem. Só que com mais tecnologia envolvida.

  • Escalar o quê, exatamente?

Essa é uma pergunta que raramente aparece. Quando falamos em escalar, estamos falando de quê? Usuários? Requisições? Times? Complexidade? Ou só estamos replicando um modelo que vimos em empresas que já estavam em outro estágio? O que realmente significa escalar?

Porque existe uma diferença enorme entre escalar volume e escalar problemas. E muitos times acabam fazendo o segundo sem perceber.

  • A arquitetura vira um objetivo (E agora a IA vira objetivo)

Em algum momento, a arquitetura deixa de ser meio e vira fim. Microserviços passam a ser adotados não porque existe uma necessidade clara, mas porque representam um padrão moderno. A cloud entra na mesma lógica: não como uma decisão estratégica baseada em contexto, mas como um movimento esperado.

Esse é um dos sinais mais claros da ilusão de escala. O sistema fica mais sofisticado, mais distribuído, mais tecnológico. Mas o valor entregue não cresce na mesma proporção.

Na prática, o time começa a gastar mais energia mantendo a estrutura do que evoluindo o produto. E nesse ponto, a arquitetura deixa de ser um facilitador e passa a ser um peso.

Escala não é o próximo passo natural

Existe uma narrativa implícita de que todo sistema precisa escalar. Mas isso não é verdade. Muitos sistemas precisam, antes de tudo, funcionar bem, ser previsíveis e ser fáceis de manter.

Escala é consequência de necessidade real: não um estágio obrigatório.

Antes de qualquer decisão técnica, existem outras coisas que deveriam escalar: clareza de domínio, capacidade de tomada de decisão, responsabilidade dentro do time, qualidade de entrega.

Sem isso, qualquer tentativa de escalar tecnologia só aumenta a superfície do problema.

Cloud não é o problema. Microserviços também não. Eles só tornam mais visível uma decisão que foi tomada cedo demais. O problema é a ilusão de que escalar é sempre o próximo passo, quando, na prática, a maioria dos times ainda precisa evoluir na base.

Antes de crescer para os lados, é preciso crescer para dentro. Senão, a escala não amplia o sucesso. Ela amplia o erro.

Marcelo Scheidt
Marcelo Scheidt
Autor verificadoAutor verificado

Senior Principal Engineer na Zallpy, Engenheiro de software com mais de 15 anos de experiência em engenharia de sistemas, arquitetura e infraestrutura, atuando na definição de visão técnica e estratégias arquiteturais para soluções complexas e de larga escala. Atualmente é Senior Principal Engineer na Zallpy, onde lidera a evolução arquitetural de múltiplos domínios, apoia executivos na tomada de decisão técnica, conduz análises de maturidade e risco, e desenvolve liderança técnica por meio de mentoria a engenheiros seniores, sempre conectando arquiteturas cloud-native, práticas modernas de DevOps e excelência em engenharia aos objetivos de negócio.

Senior Principal Engineer na Zallpy, Engenheiro de software com mais de 15 anos de experiência em engenharia de sistemas, arquitetura e infraestrutura, atuando na definição de visão técnica e estratégias arquiteturais para soluções complexas e de larga escala. Atualmente é Senior Principal Engineer na Zallpy, onde lidera a evolução arquitetural de múltiplos domínios, apoia executivos na tomada de decisão técnica, conduz análises de maturidade e risco, e desenvolve liderança técnica por meio de mentoria a engenheiros seniores, sempre conectando arquiteturas cloud-native, práticas modernas de DevOps e excelência em engenharia aos objetivos de negócio.