Come decidere se spacchettare un monolite: segnali e falsi positivi

Capire quando il monolite non fa più al caso per la nostra situazione.

I microservizi sono come le caramelle: non bisogna esagerare, altrimenti ci si ritrova con un problema più grande di quello che avevamo prima.

Il monolite non è sempre male, quando e come usarlo

Il monolite è spesso dipinto come un mostro da combattere, ma la verità è che nella fase iniziale di un prodotto resta il modo più solido, economico e veloce per evolvere software.
Un monolite:

• è semplice da capire: un unico codice, un’unica pipeline, un unico deploy;
• è efficiente per team piccoli, che non possono sostenere la complessità dei microservizi;
• riduce i costi iniziali di infrastruttura, osservabilità e orchestrazione;
• facilita decisioni rapide, perché la conoscenza del sistema è concentrata.

Il monolite è la scelta giusta quando:

• il business model non è ancora chiaro;
• le funzionalità cambiano rapidamente;
• è necessario ottimizzare la velocità del team;
• non esistono colli di bottiglia tecnici reali ma solo timori futuri.

Molti CTO iniziano a parlare di microservizi troppo presto. Se non c’è ancora complessità, introdurla è uno spreco.

Quando il monolite comincia ad andare stretto

Il segnale migliore non è tecnico: è organizzativo.
Un monolite diventa un limite quando crea attrito tra team, rallentamenti e interdipendenze.

Segnali affidabili (“veri positivi”)

• Team che si bloccano a vicenda perché lavorano sullo stesso modulo.
• Release rischiose o lente, dove ogni deploy sembra una lotteria.
• Aree del codice stabilizzate e aree in continua evoluzione che si influenzano troppo.
• Performance critiche localizzate, non risolvibili solo con scaling verticale.
• Domini di business distinti, con roadmap autonome difficili da portare avanti in un unico codebase.

Falsi positivi più comuni

• “I microservizi sono moderni, dobbiamo farli.”
• “Facciamo più assunzioni, quindi servono microservizi.”
• “Ci serve scalare ogni feature indipendentemente” (spesso non è vero: si scala l’intero monolite senza drammi).

I microservizi non risolvono problemi culturali, mancanza di ownership, processi lenti o debito accumulato.
Se il problema è umano o organizzativo, spacchettare il monolite lo peggiora.

Come pianificare la decomposizione

La decomposizione non è un big bang: è una strategia evolutiva.
Qui entra in gioco uno dei pattern più efficaci: Strangler Fig (il ficus strangolatore).

Perché il pattern Strangler Fig funziona

• permette di sostituire parti del monolite gradualmente, senza bloccare lo sviluppo;
• consente di spostare funzionalità in servizi esterni solo quando sono “mature”;
• garantisce rollback semplici, perché il monolite resta attivo finché la “nuova radice” non è solida.

Cosa partire a estrarre

• funzionalità con confini chiari e basso rischio;
• moduli già quasi isolati;
• parti del codice che il team conosce bene e può migrare senza sorprese;
• componenti stabilizzate nel business (es. billing, autenticazione, reporting).

Cosa NON estrarre all’inizio

• componenti “core” ancora turbolenti;
• parti con forte accoppiamento non compreso;
• funzionalità ad alta velocità di modifica (domini in evoluzione).

In questa fase, la domanda da farsi è:
“Sto migrando per risolvere un problema reale o per inseguire una moda architetturale?”

Come assicurare uptime durante lo shotgun surgery

Ogni migrazione rischia di introdurre regressioni, downtime e incoerenze.
La parola d’ordine è stratificazione, non chirurgia esplosiva.

Ecco i pilastri per mantenere uptime:

🔹 Edge adaptors

Specchiano le call del monolite verso il nuovo servizio, e permettono di cambiare implementazione senza toccare i client.

🔹 Contract-first

Definire prima le API, poi implementarle.
Evita che microservizi nascano come “copie stoviglie” del vecchio monolite.

🔹 Feature flags

Attivazione graduale, rollback immediati.

🔹 Osservabilità minima necessaria

• log strutturati
• tracing distribuito
• metriche business-driven
  Non serve un’astronave: serve visibilità.

🔹 Deploy frequenti e piccoli

La decomposizione è una maratona fatta di tanti sprint sicuri.

Come rendersi conto quando fermarsi

Non tutto deve diventare un microservizio.
Uno degli errori più grandi è la decomposizione infinita, motivata dall’idea che più è frammentato, più è moderno.

Saprai che è il momento di fermarti quando:

• ogni dominio ha un team proprietario, autonomo e responsabile;
• i servizi sono pochi, stabili e con confini chiari;
• il TTM (time-to-market) torna competitivo;
• la complessità marginale di ogni nuovo servizio supera il beneficio;
• il monolite residuo è piccolo, stabile e fa bene quello che deve fare.

Il risultato ottimale non è un sistema tutto microservizi, ma un ecosistema bilanciato, dove ogni pezzo ha dimensioni e responsabilità sensate.

Conclusione

La domanda giusta non è “Quando devo passare ai microservizi?”, ma:
“Il mio monolite è ancora lo strumento migliore per continuare a crescere?”

La decomposizione è un percorso, non un obiettivo.
Richiede disciplina, consapevolezza e la capacità di distinguere tra necessità e moda.
E soprattutto richiede di ricordare che l’architettura deve servire il business, non il contrario.