Monolite vs microservizi: quale architettura scegliere davvero

Per qualche anno "microservizi" è stata la risposta standard a qualunque domanda sull'architettura, e il monolite è diventato una parolaccia. Poi diverse aziende hanno fatto marcia indietro, pubblicamente, spiegando quanto era costata quella scelta. In questo articolo ti spiego cosa sono davvero le due architetture, cosa risolvono e — soprattutto — quale conviene a te.

Le due architetture in parole semplici

In un monolite tutta l'applicazione è un unico programma che viene sviluppato, testato e messo online come un blocco solo. Nei microservizi l'applicazione è spezzata in molti servizi indipendenti, ciascuno con il proprio database, che comunicano tra loro via rete.

Un esempio concreto, un e-commerce:

Monolite — un'unica applicazione che contiene catalogo, carrello, pagamenti, utenti e spedizioni. Un database, un deploy.

Microservizi — cinque servizi separati, ognuno con il proprio database, che si parlano tramite API REST o code di messaggi. Cinque deploy indipendenti.

Il monolite: cosa lo rende ancora valido

Il monolite ha una qualità che si sottovaluta sempre: è semplice.

• Una sola cosa da eseguire. Avvii il progetto in locale e hai tutto funzionante.
• Le chiamate sono chiamate a funzione. Immediate, affidabili, senza rete di mezzo.
• Le transazioni funzionano. Se un ordine tocca tre tabelle, una transazione del database garantisce che o riesce tutto o non cambia nulla.
• Il debug è lineare. Un errore ti dà uno stack trace che parte dalla richiesta e arriva al punto esatto.
• Rifattorizzare è facile. Sposti una funzione e il compilatore ti dice subito cosa si è rotto.

Il termine "monolite" viene usato come sinonimo di codice caotico, ma sono due cose diverse. Un monolite può essere ottimamente organizzato, con moduli separati e confini chiari — è quello che si chiama monolite modulare, ed è oggi l'architettura di default consigliata per la quasi totalità dei progetti.

Dove il monolite fa fatica

• Il deploy mette online tutto: una modifica minima richiede di ridistribuire l'intera applicazione
• Scala solo per intero: se serve più potenza per l'elaborazione immagini, devi replicare tutto
• Con decine di sviluppatori sullo stesso codice, i conflitti aumentano
• Sei legato a un linguaggio e a un ecosistema
• Un bug grave può far cadere tutto

I microservizi: cosa risolvono davvero

I microservizi nascono per un problema molto specifico: permettere a molti team di lavorare e rilasciare in modo indipendente.

• Deploy indipendenti. Il team pagamenti rilascia senza coordinarsi con il team catalogo.
• Scalabilità mirata. Repliche solo del servizio sotto carico.
• Isolamento dei guasti. Se cade il servizio recensioni, il resto del sito continua a vendere.
• Libertà tecnologica. Ogni servizio può usare il linguaggio e il database più adatti.

Nota una cosa: sono soprattutto benefici organizzativi, non tecnici. I microservizi risolvono un problema di coordinamento tra persone. Se le persone sono tre, quel problema non ce l'hai.

Il prezzo, che è alto

Questa è la parte che si racconta poco.

La rete non è affidabile. Una chiamata a funzione o riesce o solleva un'eccezione. Una chiamata di rete può andare a buon fine, fallire, andare in timeout o riuscire senza che tu riceva la risposta. Ogni chiamata tra servizi va gestita con retry, timeout e circuit breaker.

Le transazioni distribuite sono un problema serio. Se l'ordine sta in un servizio, il pagamento in un altro e il magazzino in un terzo, non esiste una transazione che li copra tutti. Servono pattern come le saga, con logica di compensazione: se il pagamento fallisce dopo che il magazzino è stato scalato, qualcuno deve rimetterlo a posto. È codice complesso, ed è dove nascono i bug più difficili.

Il debug diventa un mestiere a parte. Un errore attraversa sei servizi. Senza tracing distribuito e log centralizzati non capisci più dove è successo cosa.

Serve infrastruttura. Orchestrazione (Kubernetes o equivalente), service discovery, pipeline CI/CD multiple, monitoraggio, gestione dei segreti. È lavoro a tempo pieno per qualcuno.

I confini sbagliati costano carissimo. Se dividi male i servizi ottieni un monolite distribuito: tutti gli svantaggi della rete, nessuno dei vantaggi dell'indipendenza. Ogni modifica richiede di toccare quattro servizi e rilasciarli in ordine. È il peggiore dei mondi possibili, ed è l'esito più frequente quando si parte con i microservizi troppo presto.

Confronto diretto

Aspetto	Monolite	Microservizi
Ambiente locale	Un comando	Docker Compose, se va bene
Deploy	Uno, tutto insieme	Indipendenti per servizio
Transazioni	Native del database	Saga, compensazioni
Debug	Stack trace lineare	Tracing distribuito
Scalabilità	Per intero	Mirata
Team ideale	1-20 persone	Più team autonomi
Infrastruttura	Minima	Consistente
Velocità iniziale	Alta	Bassa
Costo di un errore di design	Contenuto	Molto alto

Come scegliere

Il consiglio che darei a chiunque parta oggi è netto: inizia con un monolite modulare.

Non è conservatorismo: è il consiglio che danno oggi anche molte delle aziende che i microservizi li hanno adottati per prime, dopo averne pagato il conto. Diversi casi noti di ritorno al monolite hanno riportato riduzioni di costi infrastrutturali nell'ordine di grandezza di un'intera cifra percentuale a due zeri.

Il punto chiave è organizzare bene il monolite fin dall'inizio. Moduli con confini netti, comunicazione tra moduli solo tramite interfacce esplicite, nessun accesso diretto alle tabelle di un altro modulo. Fatto così, il giorno in cui un modulo dovrà diventare un servizio a sé, il taglio sarà quasi indolore.

Considera i microservizi solo se ti riconosci in almeno due o tre di questi punti:

• Hai più team che si ostacolano a vicenda sui rilasci
• Una parte specifica del sistema ha un carico enormemente diverso dal resto
• Hai vincoli reali di isolamento (normativi, di sicurezza, di disponibilità)
• Hai chi si occupa dell'infrastruttura a tempo pieno
• I confini del dominio sono chiari e stabili da tempo

Se sei solo o in un team piccolo, i microservizi sono quasi certamente la scelta sbagliata, per quanto la cosa sia poco entusiasmante da sentirsi dire. Passerai più tempo a far parlare i servizi tra loro che a costruire il prodotto.

La via di mezzo che funziona

Nella pratica, l'architettura più sensata per un progetto che cresce è ibrida: un monolite ben modularizzato, più uno o due servizi separati per quello che ha esigenze davvero diverse.

Tipici candidati all'estrazione: elaborazione di immagini o video, invio massivo di email, lavori pesanti in background, integrazioni con sistemi esterni instabili. Sono parti con carico diverso e confini naturalmente netti.

Questo ti dà i vantaggi concreti senza pagare l'intero conto della complessità distribuita. E vale la pena ricordare che Docker e i container non implicano affatto i microservizi: un monolite containerizzato è una scelta perfettamente moderna.

In sintesi

Il monolite e i microservizi non sono uno l'evoluzione dell'altro: sono due risposte a problemi diversi. Il monolite ottimizza per la semplicità e la velocità di sviluppo; i microservizi ottimizzano per l'indipendenza tra team, pagandola con una complessità operativa notevole.

La domanda giusta non è "quale è più moderno", ma "ho davvero il problema che i microservizi risolvono?" Nella grande maggioranza dei casi la risposta è no — e adottarli comunque significa importare tutti i costi senza nessuno dei benefici.

Parti da un monolite modulare, tieni i confini puliti, ed estrai un servizio solo quando un problema concreto te lo chiede.

Se stai progettando l'architettura di un nuovo prodotto e vuoi evitare scelte che poi costano anni, la consulenza per nuovi progetti serve esattamente a questo.