Ogni scale-up arriva a un punto in cui il monolite inizia a frenare. Le feature si accumulano, i rilasci diventano rischiosi, i team si pestano i piedi. La tentazione è forte: "passiamo ai microservizi e risolviamo tutto".
La risposta onesta: i microservizi risolvono problemi di scala organizzativa, non di scala tecnica. Se il tuo team non riesce a rilasciare in modo indipendente sul monolite, non riuscirà con i microservizi — avrà solo più servizi da coordinare. La migrazione ha senso quando i confini del dominio sono chiari, i team possono lavorare in parallelo senza interferenze, e il monolite è il collo di bottiglia reale. Non prima.
Questo articolo è una roadmap pratica per chi sta valutando la migrazione: quando ha senso, quando no, e come farla senza paralizzare la delivery.
Il monolite non è il nemico
Un monolite ben strutturato, con confini interni chiari, moduli indipendenti e una pipeline di rilascio efficiente, può sostenere un'organizzazione per anni. Aziende con decine di sviluppatori lavorano efficacemente su monoliti: la chiave non è la topologia architetturale ma la qualità dei confini.
Il problema emerge quando il monolite diventa un monolite accoppiato: ogni modifica tocca componenti non correlati, ogni rilascio richiede il coordinamento di più team, ogni test richiede l'intero sistema. A quel punto non è il monolite in sé a frenare; è l'accoppiamento.
Prima di decidere di migrare, la domanda giusta non è "monolite o microservizi?" ma "i confini nel nostro sistema sono nel posto giusto?"
Quando i microservizi risolvono il problema
I microservizi sono la risposta giusta quando il problema è strutturale, non qualitativo. Tre segnali che indicano che la migrazione ha senso:
- Team bloccati dalle dipendenze: i gruppi non riescono a rilasciare in autonomia perché ogni modifica attraversa confini di responsabilità. Il coordinamento tra team diventa il collo di bottiglia principale (approfondimento sulle dipendenze tra team)
- Parti del sistema che cambiano a velocità diverse: il modulo pagamenti cambia ogni settimana, il modulo reportistica ogni trimestre. Rilasciarli insieme è uno spreco di tempo e di rischio
- Scalabilità selettiva necessaria: una parte del sistema richiede risorse computazionali 10 volte superiori alle altre. Scalare tutto il monolite per una sola funzionalità è costoso e inefficiente
Se nessuno di questi segnali è presente, il problema probabilmente si risolve con un refactoring strategico interno al monolite: meno rischioso, meno costoso e più rapido.
Quando i microservizi peggiorano le cose
I microservizi non sono gratuiti. Ogni servizio estratto aggiunge complessità operativa: monitoring, deployment, networking, gestione degli errori distribuiti, consistenza dei dati. Se l'organizzazione non è pronta a gestire questa complessità, il risultato è un monolite distribuito: tutti gli svantaggi del monolite più tutti gli svantaggi dei sistemi distribuiti.
Segnali che la migrazione è prematura:
- Il team non ha esperienza con sistemi distribuiti
- Non esiste una pipeline CI/CD automatizzata e affidabile
- Il monitoraggio in produzione è assente o rudimentale
- I confini del dominio non sono chiari: nessuno sa dove finisce un modulo e inizia l'altro
- Il problema è la qualità del codice, non l'architettura
In questi casi, la priorità è consolidare le fondamenta: test, CI/CD, monitoring, ownership dei moduli. Solo quando queste basi sono solide la migrazione diventa un'opzione praticabile.
La roadmap: come migrare in modo incrementale
La migrazione ai microservizi non è un progetto big-bang. È un percorso incrementale che si misura in mesi, a volte anni, e che produce valore a ogni passo.
Passo 1: mappare i confini del dominio. Prima di estrarre qualsiasi cosa, serve capire dove sono i confini naturali del business. Tecniche come l'Event Storming o il Domain Storytelling aiutano a far emergere i bounded context: le aree del sistema che dovrebbero poter evolvere indipendentemente. Questa mappa guida tutte le decisioni successive.
Passo 2: identificare il candidato giusto. Non estrarre il modulo più grande o il più importante: estrarre quello con il rapporto migliore tra attrito attuale e rischio di estrazione. Tipicamente è un modulo che cambia spesso, ha confini relativamente chiari e non è al centro di troppe dipendenze.
Passo 3: isolare il confine. Prima di estrarre il modulo, definire l'interfaccia tra il modulo e il resto del sistema. Questo confine, il cosiddetto anti-corruption layer, è il contratto che permette al vecchio e al nuovo di convivere. Il monolite chiama il nuovo servizio attraverso questa interfaccia; se il nuovo servizio fallisce, il vecchio codice può ancora rispondere.
Passo 4: migrare gradualmente. È il pattern Strangler Fig: il nuovo servizio gestisce una percentuale crescente del traffico mentre il vecchio codice viene progressivamente dismesso. Nessun big switch: una transizione controllata e reversibile.
Passo 5: validare e ripetere. Dopo ogni estrazione, misurare l'impatto: il team rilascia più velocemente? Le dipendenze sono diminuite? Il sistema è più stabile? Se sì, procedere con il prossimo candidato. Se no, capire cosa è andato storto prima di continuare.
L'errore più comune: confini sbagliati
Il rischio più grande nella migrazione non è tecnico; è concettuale. Se i confini tra servizi non rispecchiano i confini del dominio di business, il risultato è un sistema distribuito dove ogni funzionalità richiede chiamate a 5 servizi diversi, le transazioni diventano distribuite e il debugging diventa un incubo.
I confini architetturali devono seguire i confini organizzativi. Ogni servizio dovrebbe essere di proprietà di un singolo team; ogni team dovrebbe poter rilasciare il proprio servizio senza coordinamento con altri team. Se questo non è possibile, i confini sono nel posto sbagliato.
È la legge di Conway in azione: la struttura del software riflette la struttura dell'organizzazione. Ridisegnare l'architettura senza ridisegnare l'organizzazione produce risultati temporanei; nel giro di pochi mesi il sistema torna a riflettere la vecchia struttura. Ne parliamo in dettaglio nell'articolo sull'architettura evolutiva.
Cosa fare concretamente
Se stai valutando la migrazione, queste sono le tre azioni da fare prima di scrivere una riga di codice:
L'errore che vediamo più spesso nelle scale-up che ci contattano per una migrazione è questo: vogliono passare ai microservizi perché "il monolite è diventato difficile da gestire", ma quando analizziamo il sistema scopriamo che il problema non è il monolite — è che non ci sono confini chiari tra i moduli. Un monolite modulare, con ownership chiara per dominio, risolve il 70% dei problemi di coordinamento che vengono attribuiti all'architettura monolitica. La migrazione a microservizi viene dopo, se e quando serve davvero.
- Mappare le dipendenze reali: non quelle che credi di avere, quelle che emergono dal codice e dalle comunicazioni tra team. Chi parla con chi? Quale modulo cambia ogni volta che un altro cambia? Il calcolatore di impatto può aiutarti a quantificare l'attrito
- Validare i confini con il business: i confini tecnici devono rispecchiare i confini del dominio. Se il team pagamenti e il team ordini lavorano sullo stesso modulo, il confine è nel posto sbagliato
- Iniziare dal modulo con meno rischio: non dal più critico. Il primo servizio estratto è quello dove impari il processo; il secondo è quello dove generi valore
Se il quadro è complesso, se le dipendenze sono intrecciate e i confini non sono chiari: è esattamente il tipo di situazione in cui un intervento mirato fa la differenza. Identificare il punto giusto da cui partire è spesso la decisione più importante dell'intero percorso.