La fine dei Microservizi: la rivincita del Monolite nell’era dell’AI-First

Per oltre un decennio, l'industria tech ha professato un dogma quasi incrollabile: se vuoi scalare, devi frammentare. L’architettura a microservizi è stata venduta a startup, scale-up e corporate come il biglietto di sola andata verso la flessibilità, il deploy indipendente e l'eliminazione dei single-point-of-failure.

Oggi, però, i nodi sono venuti al pettine. Tra complessità operativa ingestibile, costi cloud fuori scala e l'urgenza di sviluppare a velocità raddoppiata con strumenti potenziati da modelli di intelligenza artificiale, stiamo assistendo al più grande contrordine dell'ingegneria del software moderna: la riscoperta del Monolite (in particolare, del Monolite Modulare).

1. Il disincanto: da soluzione a "tassa architetturale"

Cosa è andato storto con i microservizi? Già nel 2015, Martin Fowler avvertiva con il suo celebre principio del MonolithFirst: "Quasi tutti i casi di successo di microservizi sono partiti da un monolite diventato troppo grande; quasi tutti i sistemi partiti da zero a microservizi sono finiti nei guai".

Nel tentativo di imitare Netflix o Google con team di 10 o 20 persone, molte aziende si sono scontrate con la cruda realtà della tassa di complessità:

• Latenza di rete e fallimenti parziali: Quella che prima era una chiamata di funzione in memoria da microsecondi è diventata una chiamata HTTP/gRPC soggetta a timeout, serializzazione JSON/Protobuf e circuit breaker.

• Consistenza dei dati compromessa: L'abbandono delle transazioni ACID native dei database relazionali per pattern complessi come Saga o Eventual Consistency ha introdotto bug complessi da replicare e debuggare.

• Overhead operativo sproporzionato: Service mesh (Istio), tracing distribuito (Jaeger, OpenTelemetry), cluster Kubernetes multi-zona: il tempo degli sviluppatori si è spostato dalla scrittura di logica di business alla manutenzione dell'infrastruttura.

2. Il campanello d'allarme: il caso emblematico di Amazon Prime Video

La crepa definitiva nella narrazione "microservizi a tutti i costi" è arrivata direttamente da casa AWS nel 2023. Nel blog ufficiale di Prime Video Tech, il team ha documentato la migrazione del servizio di monitoraggio dei flussi video (Video Quality Operations Cell) da un'architettura distribuita basata su AWS Step Functions e AWS Lambda a un monolite containerizzato su Amazon ECS/EC2.

I risultati certificati dal team di Amazon:

• Riduzione del 90% dei costi di infrastruttura cloud.

• Eliminazione dei colli di bottiglia legati ai limiti di chiamate per transazione e al passaggio di frame pesanti su bucket S3.

• Prestazioni significativamente superiori grazie all'elaborazione dei dati nella stessa memoria di processo.

Non si è trattato di un passo indietro verso codice disordinato, ma di una scelta pragmatica: quando la comunicazione ad alta frequenza è fondamentale, un monolite ben congegnato supera qualsiasi catena distribuita.

A questo si aggiunge la testimonianza decennale di David Heinemeier Hansson (DHH), fondatore di 37signals (Basecamp, HEY): con il loro celebre abbandono del cloud pubblico e l'uso continuo del monolite Ruby on Rails, hanno dimostrato come milioni di utenti e centinaia di milioni di richieste al giorno possano essere gestiti con una manciata di server dedicati e un'architettura a monolite coeso.

3. Il vero protagonista: il Monolite Modulare (Modular Monolith)

Riscoprire il monolite non significa tornare alla "Big Ball of Mud" (l'ammasso informe di codice spaghetti privo di confini). L'alternativa vincente che si è affermata è il Modular Monolith:

1. Confini di dominio netti (DDD): L'applicazione è divisa internamente in moduli con API interne ben definite e responsabilità distinte.

2. Unico repository e un unico deploy: Un singolo ciclo di CI/CD, una singola pipeline, deploy deterministico e zero disallineamenti di versione tra servizi interdipendenti.

3. Database coeso o con schemi isolati: Possibilità di sfruttare query JOIN e transazioni atomiche native dove serve, mantenendo comunque l'isolamento logico dei dati per modulo.

4. Separabilità futura a costo zero: Se un singolo modulo (ad esempio l'encoding video o l'elaborazione pesante di code) dovesse davvero richiedere scaling asimmetrico, estrarlo diventa un refactoring puntuale, non un'avventura al buio.

4. Perché l'approccio AI-First favorisce il Monolite

L'avvento di agenti software, assistenti al codice (Claude 3.7 Sonnet, GPT-4o, GitHub Copilot Workspace) e modelli linguistici su larga scala sta trasformando radicalmente il modo in cui costruiamo applicativi web. In questo contesto, il monolite è l'ambiente ideale per l'AI:

A. Ampiezza di contesto (Context Window)

Gli agenti AI ragionano al meglio quando hanno piena visibilità del flusso end-to-end: dallo schema del database al controller, dai tipi di dominio all'interfaccia frontend. In un monolite (o monorepo unificato), l'agente può analizzare, rifattorizzare e generare codice comprendendo l'intero grafo delle dipendenze in un unico prompt o workspace, riducendo le allucinazioni da contratti API disallineati.

B. Manutenibilità e refactoring assistito

Con linguaggi fortemente tipizzati (TypeScript, Go, Rust, C#) o framework maturi (Ruby on Rails, Laravel, Django, Next.js), un tool AI può ristrutturare un modulo interno garantendo che la type-safety a tempo di compilazione intercetti subito ogni regressione. Nei microservizi, un cambio di payload JSON su un servizio upstream rischia di fallire solo a runtime nell'ambiente di staging o produzione.

C. Velocità di prototipazione e Agentic Workflows

In un ecosistema AI-first, le feature vengono testate e iterate in ore, non in sprint bisettimanali. Un monolite elimina la necessità di orchestrare 5 PR contemporanee su 5 repository diversi solo per aggiungere un campo nel profilo utente e inviare una notifica.

5. Il verdetto per aziende e startup

Significa che i microservizi sono morti per sempre? No. Hanno ancora senso per organizzazioni di proporzioni enormi (migliaia di ingegneri divisi in centinaia di team indipendenti) dove il collo di bottiglia principale non è il codice, ma il coordinamento umano.

Tuttavia, per la stragrande maggioranza delle aziende, dei prodotti SaaS e dei progetti digitali:

• Scalare il traffico è un problema di macchine e caching (replicare orizzontalmente 10 istanze di un monolite dietro un load balancer è economico e banale).

• Scalare la complessità è un problema umano (mantenere 40 microservizi per gestire 5.000 utenti attivi è un autolesionismo ingegneristico).

Nel 2026 e negli anni a venire, l'eccellenza nello sviluppo web non si misura più da quanti nodi Kubernetes popolano la tua dashboard, ma da quanto velocemente riesci a trasformare un'idea in valore reale per l'utente finale. Lunga vita al Monolite.