A virada ontológica em arquitetura de software

Houve um momento, há alguns anos, em que aceitei uma narrativa que me incomodava sem que eu soubesse dizer por quê. A narrativa era sedutora, repetida em toda conferência e todo whitepaper: superamos o monólito. Onde antes havia um bloco único de software, rígido e difícil de evoluir, agora havia dezenas, centenas de microsserviços — pequenos, independentes, cada um com sua responsabilidade. A modernidade arquitetônica tinha um nome, e o nome era decomposição.

Algo me dizia que estava errado. Não a decomposição em si — essa resolve problemas reais de escala, de deploy, de organização de times. O que me incomodava era a palavra superamos. E levei tempo até ter o vocabulário para nomear o incômodo. Quando tive, ele se revelou simples, e mais radical do que eu esperava: a decomposição foi topológica, não ontológica. Quebrou-se o monólito em pedaços menores, mas cada pedaço continuou sendo um monólito. A natureza não mudou — só o tamanho.

Microsserviço é monólito distribuído

Um microsserviço, levado ao limite do conceito, não deixa de ser um monólito. Sua lógica interna continua rígida, determinística, fechada. Recebe uma entrada prevista, executa um caminho fixo, devolve uma saída especificada. Não tem variabilidade interna — não adapta o caminho à perturbação, porque não foi feito para isso. É, na sua natureza, uma máquina: o que eu chamo, no vocabulário da heteropoiese, de componente alopoiético.

Distribuir componentes alopoiéticos não os torna flexíveis. Apenas distribui a rigidez. E distribuir rigidez tem uma consequência que a indústria conhece bem, ainda que não a nomeie assim: quando um nó rígido quebra num monólito, o monólito quebra; quando um nó rígido quebra numa malha de microsserviços, o efeito cascata é pior, porque agora há dezenas ou centenas de monólitos rígidos tentando se coordenar. O que se ganhou em granularidade de deploy, perdeu-se em fragilidade de coordenação.

Não é acidente que a complexidade operacional dos microsserviços tenha explodido. É consequência estrutural. Toda a variabilidade que deveria estar dentro de cada componente — como capacidade de adaptação — foi empurrada para entre os componentes, como orquestração. E a indústria criou um arsenal inteiro de padrões para administrar essa variabilidade exilada: Circuit Breaker, Saga, Service Mesh, CQRS, retries, compensações. Cada um desses padrões é uma peça de engenharia inteligente. Mas, vistos juntos, eles revelam algo que individualmente escondem: são próteses compensatórias para a rigidez interna dos componentes.

A arquitetura inteira vira uma camada de coordenação que tenta produzir, do lado de fora, a adaptabilidade que não existe do lado de dentro. E essa camada de coordenação é, ela mesma, um monólito lógico disfarçado de infraestrutura distribuída.

Ashby, que já tinha dito

Há uma lei, formulada pelo cibernético W. Ross Ashby, que dá nome teórico ao problema: só variedade absorve variedade. Um sistema que enfrenta um ambiente variável precisa de variabilidade interna proporcional à variabilidade que enfrenta. É a Lei da Variedade Requisitada.

Componentes alopoiéticos têm variabilidade interna zero. Logo, diante de um ambiente que muda, toda a variabilidade requisitada precisa ser produzida em outro lugar — na camada de orquestração. Os padrões de microsserviços são exatamente isso: a tentativa de gerar, por coordenação externa, a variedade que os componentes não têm internamente. Funciona, até certo ponto, e ao custo de uma complexidade que cresce mais rápido do que o número de componentes.

Num mundo estável, isso seria sustentável — talvez até ótimo, porque determinismo é eficiência quando o contexto não muda. Mas num mundo em mutação, o componente sem variabilidade interna quebra, e a camada que tenta compensá-lo incha até o ponto em que a complexidade de coordená-la supera a complexidade que ela pretendia resolver. Ashby previu isso. A indústria está redescobrindo, por tentativa e erro, o que ele formalizou há mais de meio século.

A terceira natureza

A saída não é voltar ao monólito, nem abandonar a decomposição. É mudar a natureza do que está dentro do componente. E aqui é preciso uma distinção que a engenharia de software, por herança histórica, nunca precisou fazer — porque o computador sempre foi máquina determinística, e o software, instrução sequencial.

Há três naturezas possíveis para um componente, e a melhor forma que encontrei de distingui-las é viária:

O componente heteropoiético não é trilho nem campo aberto. É estrada com faixas. As entradas são acordadas. As saídas obedecem a um contrato. Mas o caminho entre entrada e saída não é determinado — é navegado. O componente tem variabilidade interna real, não simulada. E essa variabilidade é constituída, não restringida, pelos limites que o definem.

Essa é a frase que demora a fazer sentido, porque inverte uma intuição arraigada: guard rails não restringem a liberdade — constituem-na. No pensamento convencional, todo limite é uma subtração de liberdade. Mas sem a estrada, não há direção; e sem direção, não há liberdade — há apenas aleatoriedade. O probabilístico sem guard rail não é livre. É ruído. A liberdade do componente heteropoiético existe porque há faixas, não apesar delas.

Quando o componente passa a ter variabilidade interna legítima — graus de liberdade constituídos por guard rails —, a economia de complexidade inteira se inverte. Ele absorve a perturbação localmente, na faixa, sem precisar escalar cada imprevisto para a camada de orquestração. O Saga deixa de compensar uma transação errada e passa a compensar uma decisão que saiu da faixa. O Service Mesh deixa de monitorar apenas latência e passa a monitorar drift — o componente ainda está na estrada? A complexidade que crescia entre os componentes passa a ser absorvida dentro deles.

O mesmo erro, em três escalas

O mais revelador dessa lente é que o erro dos microsserviços não é um erro de software. É um erro de discriminação ontológica — e ele se repete, idêntico, em três escalas diferentes.

Em software, tratou-se todo componente como alopoiético, por herança técnica, e empurrou-se para a orquestração a variabilidade que os componentes não tinham.

Nas organizações, faz-se o mesmo, e há décadas. Planejamento estratégico rígido para um mundo volátil. Descrições de cargo determinísticas para funções que exigem adaptação. Processos fixos para contextos que mudam. O resultado é o análogo organizacional dos padrões de microsserviços: comitês para tratar exceções, workarounds informais, o "jeitinho" que faz o sistema funcionar apesar de si mesmo — toda uma camada de coordenação compensando a rigidez de componentes que deveriam ter graus de liberdade. É exatamente o que Chris Argyris descreveu como a distância entre a teoria esposada — "temos processos claros" — e a teoria em uso — "ninguém consegue trabalhar sem furá-los".

E agora, com os agentes de inteligência artificial, o mercado se prepara para cometer o erro simétrico — o inverso exato. Depois de décadas pondo rigidez onde precisava de adaptação, há o risco de pôr adaptação onde se precisa de rigidez: um agente probabilístico decidindo compliance tributário, um sistema com "graus de liberdade" processando transações financeiras, margem interpretativa onde o contexto não tolera desvio. O primeiro erro destrói por fragilidade; o segundo, por imprevisibilidade. Ambos destroem.

A sabedoria é discriminar, não escolher

Daí a tese central, e ela não é a defesa de uma natureza contra as outras. A sabedoria arquitetônica não está em escolher uma natureza sobre as demais. Está em discriminar qual natureza cada contexto exige.

Há contextos em que o determinismo é virtude, e ali o componente alopoiético — o trilho — é a resposta certa: o cálculo que não pode variar, a transação que precisa ser exata, a regra que não admite interpretação. Há contextos em que a adaptação é necessidade, e ali o componente heteropoiético — a estrada com faixas — é o correto: o agente que precisa responder ao imprevisto dentro de limites, o processo que precisa de graus de liberdade contratados. E há contextos em que o julgamento é insubstituível, e ali só o autopoiético — o humano, o campo aberto — basta: a calibração das faixas, a decisão sobre para onde a estrada vai, a escolha de qual natureza cada coisa exige.

Uma arquitetura robusta, num mundo em mutação, é quase sempre mista: componentes alopoiéticos onde o determinismo é virtude, heteropoiéticos onde a adaptação é necessidade, autopoiéticos onde o julgamento humano é insubstituível. O agente de IA não substitui o microsserviço nem o humano — ocupa a faixa do meio, que estava vazia, e que a engenharia de software nunca soube nomear porque nunca teve, antes, um material com essa natureza.

Cheguei a essa leitura de fora do mundo tech — pela ontologia, não pela engenharia. E foi justamente por estar de fora que pude ver o que, de dentro da celebração da decomposição, é difícil enxergar: decompor não é transformar. Mudar a topologia de um sistema — onde estão as fronteiras, quantos pedaços há — não muda a sua natureza. É o mesmo engano do executivo que reorganiza o organograma e acredita ter mudado a cultura. Mudou o desenho. A natureza permaneceu intacta.

O problema nunca foi o tamanho do monólito. Foi a ausência de graus de liberdade dentro dele. E isso não se resolve quebrando o monólito em pedaços menores — resolve-se mudando a natureza do que está dentro de cada pedaço.

Fundações na trilogia: Livro 2 · Cap. 13O Sistema Vivo Ampliado