Microservizi vs Monolite: quando vale la pena e quando no – Guida operativa per team senior

La telefonata arriva sempre nello stesso modo: «Il nostro monolite non ce la fa più. Dobbiamo passare ai microservizi». Sentiamo questa frase da anni, da ogni tipo di cliente: startup in serie A, PMI manifatturiere, negozi di abbigliamento passati all'e-commerce. Il problema non è il monolite: il problema è che quasi sempre chi lo dice non ha ancora misurato il costo reale della migrazione.

Noi, di Meteora Web, ragioniamo in numeri. Veniamo dalla contabilità, abbiamo gestito bilanci e partita doppia. Un'architettura software non è una scelta filosofica: è un investimento. Se non sappiamo quanto costa e quanto rende, non partiamo. In questa guida ti portiamo dentro il nostro processo decisionale: quando il monolite regge, quando invece soffoca, e come riconoscere il falso mito dei microservizi.

Il monolite non è il nemico. L'accoppiamento sì

Un'applicazione monolitica significa un singolo processo deployabile, con tutto il codice impacchettato insieme. Funziona benissimo per anni. Noi abbiamo clienti con monoliti PHP fatti bene che fatturano milioni e girano su un solo server con 4 GB di RAM. Perché funzionano? Perché il dominio è coeso, il team è piccolo, e il deploy è una procedura collaudata.

Il vero problema non è la grandezza del codice, ma quanto le parti sono accoppiate. Puoi avere 500 mila righe di codice con coupling basso se hai seguito Domain-Driven Design e hai tenuto i bounded context separati a livello logico anche dentro lo stesso deployable. Puoi avere 10 microservizi con coupling altissimo perché condividono lo stesso database o chiamate sincrone in cascata.

La domanda giusta non è «monolite o microservizi?» ma «come riduciamo l'accoppiamento a costo accettabile?».

Segnali che il monolite è ancora la scelta migliore

• Team sotto le 8-10 persone: un monolite ben organizzato è più facile da capire, deployare e debuggare. Con microservizi devi moltiplicare CI/CD, logging centralizzato, orchestrazione. Il costo mentale schizza.
• Deploy multipli al giorno con build sotto i 2 minuti: se il tuo ciclo di deploy è veloce e affidabile, il monolite non ti sta rallentando.
• Prodotto in fase esplorativa: i requisiti cambiano ogni settimana. Cambiare un monolite è molto più veloce che modificare interfacce e contratti tra servizi.
• Budget di infrastruttura limitato: microservizi = almeno un cluster Kubernetes o un orchestrator. È un costo di gestione che non compare in fattura iniziale ma diventa voce pesante dopo tre mesi.

Il mito della scalabilità orizzontale facile

Molti pensano: «Con i microservizi, se un modulo va in overload, lo replico». Vero, ma solo se hai effettivamente carichi diversi. Nel 90% dei progetti che vediamo, il collo di bottiglia è il database, non il codice applicativo. Scalare orizzontalmente il database è il vero problema, e l'architettura a microservizi non lo risolve magicamente. Anzi, lo peggiora: distribuisci i dati su più DB e poi devi gestire transazioni distribuite, consistenza eventuale, saga pattern. Siamo passati da un problema semplice (lento) a 5 problemi medi (complessi).

Il momento del ribaltone: quando il monolite diventa un freno

Lo capisci da tre indicatori concreti:

1. Il deploy dura più di 30 minuti e ogni merge è un incubo. Se il team cresce e i conflitti diventano quotidiani, la dimensione del monolite ha superato la capacità di gestione del codice. Non è l'accoppiamento: è la quantità di persone che toccano la stessa base di codice.
2. Non puoi più sperimentare con stack diversi. Se un team vuole usare Python per un modulo di ML e il monolite è in Java, deve aspettare il grande rewrite. Con microservizi, ogni servizio può essere scritto nel linguaggio più adatto.
3. Il single point of failure è reale. Un bug in una funzione di logging fa crashare tutto il sistema. Un deployment sbagliato butta giù fatturazione, catalogo e checkout insieme.

Noi abbiamo seguito un cliente e-commerce di abbigliamento che aveva un monolite PHP/MySQL con 300 tabelle. Ogni deploy in produzione richiedeva 45 minuti, il test era manuale. Il turnover era alto perché gli sviluppatori passavano più tempo a risolvere conflitti che a scrivere codice. Lì la scelta di estrarre un bounded context (la gestione del catalogo) come microservizio ha dimezzato i tempi di rilascio e ridotto i bug. Ma lo abbiamo fatto su un solo dominio alla volta, con attenta pianificazione dei contratti.

Il framework decisionale che usiamo con i clienti

Ecco lo schema che applichiamo prima di ogni migrazione. Non serve software fancy: carta e penna bastano.

• Mappa i bounded context: con DDD, disegna i confini naturali del tuo dominio. Ogni contesto potrebbe diventare un microservizio indipendente.
• Misura il coupling attuale: strumenti come jdepend per Java, phpmd per PHP, o semplicemente un'analisi delle chiamate tra moduli. Se il coupling è alto, spezzare senza un refactoring preliminare è un fallimento annunciato.
• Identifica il collo di bottiglia: è il deploy? Il carico? La velocità di sviluppo? Spesso il problema non è l'architettura ma processi interni (mancanza di test automatici, branch strategy sbagliata).
• Calcola il costo dell'orchestrazione: Kubernetes non è gratis. Servono specialisti, monitoring (Prometheus, Grafana), service mesh (Istio/Linkerd), logging centralizzato (Loki, Elastic). Il costo operativo annuo può superare lo stipendio di un senior developer.

Un esercizio operativo per il tuo team

Prendi la tua applicazione attuale e cronometra il tempo di build pulito (senza cache). Se supera i 10 minuti, è un problema. Poi conta quante dipendenze esterne carica quel build (JAR, npm, Composer). Se hai più di 50 pacchetti, la complessità di build sta già indicando che il monolite è diventato una palla di fango. Non è ancora un motivo per passare ai microservizi, ma è un segnale per iniziare a modularizzare dentro il monolite, con pacchetti interni ben separati.

Casi concreti dal nostro lavoro

Il cliente che non doveva migrare

Azienda SaaS B2B con 5 sviluppatori, fattura 2M€ annui. Monolite Laravel, database PostgreSQL. Carico stabile, pochi picchi. Il CTO voleva Kubernetes e microservizi «per scalare». Abbiamo fatto i conti: l'infrastruttura AWS passava da 800€/mese a oltre 4.000€/mese con Kubernetes, più il tempo interno per gestirlo. Il bottleneck era una query SQL non ottimizzata. Abbiamo risolto con un indice e una cache Redis: risparmio netto di 3.200€/mese e nessun cambiamento architetturale. Il cliente ci ringrazia ancora.

Il cliente che doveva migrare (ma gradualmente)

E-commerce moda con 15 sviluppatori, monolite Magento 2. Deploy settimanali da 2 ore. Ogni release rompeva qualcosa. Abbiamo estratto il modulo dei pagamenti come microservizio indipendente, con un contratto API REST ben definito. Dopo 3 mesi, l'estrazione ha permesso rilasci giornalieri sul pagamento senza toccare il resto. Dopo quell'esperienza, abbiamo estratto la gestione delle recensioni. La regola è: un bounding context alla volta, con metriche precise su ogni deploy.

Le architetture alternative che spesso funzionano meglio

Prima di dichiarare guerra al monolite, considera queste opzioni intermedie:

• Modular monolith: tenere un solo deployable ma con moduli fortemente incapsulati, comunicazione via interfacce interne, test isolati. Kevlin Henney e Simon Brown lo hanno teorizzato per anni. Funziona.
• Vertical slice architecture: organizzare il codice per feature, non per layer. Riduce l'accoppiamento e permette di estrarre un microservizio in futuro senza stravolgere tutto.
• Microservizi solo per i colli di bottiglia: estrai solo il modulo che deve scalare indipendentemente (es. processo di notifica, rendering di documenti). Il resto resta monolitico.

Noi abbiamo usato il modular monolith per un progetto di gestione presenze per una cooperativa siciliana: 40.000 dipendenti, carico prevedibile. Con PHP e moduli separati via namespace e dependency injection, abbiamo ottenuto prestazioni eccellenti e manutenibilità senza pagare il canone Azure Kubernetes. Il divario digitale è anche geografico: le imprese del Sud meritano tecnologia di serie A, ma con costi sostenibili.

In sintesi – Cosa fare adesso

1. Non ascoltare le mode. I microservizi risolvono problemi organizzativi, non tecnici. Se hai un team piccolo e un dominio coeso, tieni il monolite.
2. Misura prima di tagliare. Tempo di build, coupling, numero di conflitti git al mese, frequenza di deploy. Ogni dato è più prezioso di un diagramma di architettura.
3. Prova il modular monolith come primo passo. Separa i bounded context a livello di codice, con interfacce nette. Quando senti il bisogno di scalare solo un modulo, estrailo.
4. Calcola il costo totale di ownership. Includi ore di DevOps, infrastruttura, monitoring, formazione. Se non superi il break-even in 12 mesi, non conviene.
5. Affidati a chi ha visto entrambi i mondi. Noi abbiamo costruito monoliti che fatturano e piattaforme a microservizi per gestire decine di clienti contemporaneamente. Sappiamo dove si nascondono i costi nascosti.

Se stai valutando una migrazione, parti da qui: il tuo monolite è un patrimonio, non un problema. Impara a conoscerlo prima di demolirlo.