Migrazione da monolite a microservizi: una guida enterprise

Marcus Chen Responsabile delivery & backend, YuSMP Group · Specializzato in sistemi distribuiti e migrazioni di architetture enterprise

TL;DR — cosa implica realmente la migrazione

Migrare un monolite enterprise a microservizi non è principalmente un esercizio di codifica. È una trasformazione organizzativa, dei dati e operativa che richiede 18–36 mesi per un sistema di grandi dimensioni. Ecco a cosa ci si impegna concretamente:

• Estrazione dei servizi: identificare i bounded context ed estrarli uno alla volta usando il pattern strangler fig
• Decomposizione dei dati: suddividere il database monolitico condiviso in database di proprietà dei singoli servizi — il problema tecnico più difficile in qualsiasi migrazione
• Allineamento organizzativo: ristrutturare i team attorno ai servizi (legge di Conway), altrimenti la struttura del codice tornerà a corrispondere all’organigramma aziendale
• Maturità operativa: distributed tracing, service mesh, pipeline CI/CD indipendenti e runbook on-call — tutti prerequisiti, non elementi a posteriori
• Costo: tipicamente il 15–25 % del costo originale di sviluppo del sistema all’anno di migrazione per un monolite enterprise di grandi dimensioni

Quando migrare (e quando no)

La domanda architettonica più importante non è come migrare, ma se farlo. Molti monoliti enterprise non dovrebbero essere migrati — almeno non completamente, e non ora.

Segnali forti che giustificano la migrazione

• Il coupling del deployment blocca la velocità: i team si attendono a vicenda per rilasciare perché tutto viene deployato come un unico artefatto. Un bug di un team ritarda le funzionalità di altri cinque team.
• Lo scaling è tutto o niente: un picco in un sottosistema (elaborazione pagamenti, motore di raccomandazione) obbliga l’intera applicazione a scalare, con costi infrastrutturali non necessari.
• È richiesto l’isolamento normativo: la residenza dei dati GDPR (Regolamento UE 2016/679), l’isolamento dei dati dei titolari di carte PCI-DSS o la riduzione del perimetro SOC 2 impongono che certi flussi di dati siano fisicamente separati.
• Il lock-in tecnologico blocca le capacità: una nuova funzionalità critica richiede un runtime o un linguaggio incompatibile con lo stack del monolite, e la re-platforming dell’intera applicazione è sproporzionata.

Segnali forti per rimandare la migrazione

• Il team ha meno di 30 ingegneri — il costo di coordinamento dei microservizi supera i benefici del deployment a questa scala.
• Mancano pipeline CI/CD mature, test automatizzati con copertura superiore al 60 % o osservabilità centralizzata — si creerà un sistema distribuito caotico, non una piattaforma a microservizi.
• Nessuno è responsabile della mappatura dei bounded context — senza un chiaro modello di dominio, si estrarranno confini errati e si passeranno anni a ri-unire ciò che è stato suddiviso in modo sbagliato.
• Il monolite funziona e il dolore operativo è modesto — se il ritmo di consegna attuale è accettabile, la modernizzazione legacy incrementale può offrire più valore per euro rispetto a una decomposizione completa.

La trappola degli spaghetti distribuiti

Il fallimento più comune nelle migrazioni a microservizi enterprise è la creazione di un monolite distribuito: un sistema suddiviso in unità deployabili separate ma che conserva tutto il coupling del monolite originale, aggiungendo tutta la complessità operativa dei sistemi distribuiti.

I sintomi di un monolite distribuito includono:

• I servizi condividono un unico database o schema — le modifiche a una tabella richiedono il coordinamento dei rilasci tra cinque team
• Le catene REST sincrone attraversano 4–8 servizi per richiesta utente — un timeout nel servizio D si propaga al servizio A
• Una libreria condivisa contiene il modello di dominio, la business logic o la configurazione — ogni servizio deve rilasciare insieme quando cambia
• I servizi vengono deployati insieme sullo stesso calendario di rilascio, vanificando il beneficio del deployment indipendente

Pattern strangler fig: estrazione incrementale

Il pattern strangler fig di Martin Fowler (chiamato così per la vite tropicale che cresce attorno al suo albero ospite fino a sostituirlo) è l’approccio standard del settore per la migrazione zero-downtime di grandi sistemi di produzione. L’intuizione chiave: non si riscrive mai l’intero sistema; si reindirizzano percorsi di richiesta specifici verso nuovi servizi uno alla volta.

I meccanismi coinvolgono tre elementi:

1. Facade: un API gateway, un reverse proxy (Nginx, Envoy) o uno strato BFF si posiziona davanti sia al monolite che ai servizi emergenti, instradando le richieste in base al path, agli header o ai feature flag.
2. Estrazione: un bounded context viene estratto in un servizio standalone con il proprio codebase, pipeline di deployment e (infine) il proprio database. Il codice del monolite per quel contesto rimane in place ma il traffico viene reindirizzato attraverso la facade.
3. Verifica e strangling: una volta che il nuovo servizio gestisce il 100 % del traffico per quel contesto senza regressioni, il codice corrispondente nel monolite viene rimosso. Lo «strangling» è completo per quel contesto.

Regole pratiche per la sequenza di estrazione con il pattern strangler fig:

• Iniziate con servizi a lettura intensa e bassa scrittura — reporting, navigazione del catalogo, preferenze di notifica. Hanno meno dipendenze transazionali e sono più sicuri da estrarre per primi.
• Estraete prima i contesti foglia — servizi che non chiamano altri servizi interni. Procedere verso il nucleo riduce il blast radius delle estrazioni iniziali.
• Evitate di estrarre prima il contesto pagamento o autenticazione — si tratta di domini ad alta criticità e forte coupling. Estraeteli dopo che il team ha acquisito fiducia con contesti più semplici.
• Mantenete la facade sottile — evitate di inserire business logic nel router. Diventerebbe un nuovo monolite.

Decomposizione del database condiviso

Se il pattern strangler fig è la sfida più discussa della migrazione a microservizi, la decomposizione dei dati è quella più difficile in pratica. La maggior parte dei monoliti enterprise condivide un unico database relazionale con centinaia di tabelle, relazioni di chiave esterna tra confini di dominio e stored procedure che incorporano business logic.

La decomposizione procede per fasi:

1. Identificare la proprietà: per ogni tabella e colonna, assegnare un singolo servizio proprietario. Si tratta di un esercizio di modellazione del dominio, non tecnico. Utilizzate sessioni di event storming con gli stakeholder di business per individuare la vera proprietà.
2. Astrarre l’accesso: prima di separare fisicamente i database, introducete percorsi di lettura/scrittura a livello di servizio attraverso l’API del nuovo servizio. Gli altri servizi smettono di interrogare direttamente la tabella condivisa e chiamano invece il servizio proprietario. Questo rivela il coupling nascosto.
3. Transizione dual-write: durante la finestra di cutover, scrivete sia sulla tabella condivisa del monolite che sul nuovo schema privato del servizio simultaneamente. Verificate la consistenza prima di impegnarsi con il nuovo schema come canonico.
4. Migrazione e cutover: una volta che il dual-write è stabile e le query di lettura vengono instradate attraverso il nuovo servizio, promuovete lo schema privato a canonico e rimuovete il dual-write. La tabella condivisa diventa di sola lettura, per poi essere infine eliminata.

Struttura organizzativa e legge di Conway

La legge di Conway afferma che le organizzazioni progettano sistemi che rispecchiano la propria struttura di comunicazione. L’implicazione pratica per la migrazione: se si estraggono microservizi senza modificare l’organizzazione dei team, i servizi evolveranno gradualmente verso la forma dell’organigramma aziendale — e si ricostruirà il monolite in forma distribuita.

Una migrazione efficace richiede la manovra inversa di Conway: ristrutturare intenzionalmente i team per corrispondere ai confini di servizio desiderati, in modo che la proprietà del team, i pattern di comunicazione e la proprietà del servizio siano allineati.

Questo significa:

• Ogni servizio ha un singolo team proprietario — non un «platform team» che possiede tutto
• I team sono dimensionati per possedere 1–3 servizi end-to-end (sviluppo, deployment, on-call)
• La comunicazione inter-servizio diventa un contratto API formale di proprietà del team produttore, non un join informale del database
• I platform team possiedono le primitive infrastrutturali (service mesh, template CI, osservabilità) ma non i servizi di dominio

È qui che conta anche la strategia di system integration enterprise: i contratti tra servizi diventano la superficie di integrazione a lungo termine, non lo schema del database.

Benchmark di costo e tempistiche

I benchmark di costo realistici per le migrazioni di monoliti enterprise variano ampiamente in base alle dimensioni del sistema e al coupling, ma i seguenti range sono coerenti con i dati del settore e con la nostra esperienza nei progetti:

Queste cifre presuppongono che la migrazione sia condotta in parte con il team esistente (conoscenza del dominio) e in parte con un partner specializzato esterno (pattern architetturali, tooling). Si noti che la «decomposizione completa» è raramente l’obiettivo — la maggior parte delle imprese punta a una decomposizione selettiva dei bounded context ad alto valore e lascia indefinitamente i sottosistemi stabili e poco modificati nel monolite.

Anche i costi infrastrutturali aumentano significativamente durante la migrazione: eseguire monolite e servizi in parallelo, oltre al nuovo tooling per service mesh, distributed tracing e gestione dei segreti, aggiunge tipicamente il 30–50 % alla spesa operativa per l’infrastruttura per tutta la durata della transizione.

Osservabilità e strategia di rollback

Non si può gestire in modo sicuro un sistema distribuito che non si riesce a osservare. Prima di estrarre il primo servizio, devono essere in atto i seguenti elementi:

• Distributed tracing: OpenTelemetry con un backend (Jaeger, Tempo, Datadog APM) per tracciare una singola richiesta utente attraverso i confini dei servizi. Questo è non negoziabile.
• Aggregazione centralizzata dei log: log JSON strutturati da tutti i servizi inoltrati a un unico store interrogabile (Loki, Elasticsearch, CloudWatch Logs).
• SLI/SLO a livello di servizio: definire target di error rate, latenza p95 e disponibilità per servizio prima che riceva traffico di produzione. Gli alert si attivano sul burn rate degli SLO, non sulle metriche grezze.
• Feature flag nella facade: mantenere la capacità di reindirizzare istantaneamente il traffico al monolite per qualsiasi contesto estratto. Il pattern strangler fig funziona solo se si può invertirlo rapidamente.

La strategia di rollback deve essere esplicita per ogni fase di estrazione. Per ogni estrazione di servizio, documentate:

• La specifica regola di instradamento della facade da ripristinare (modifica a una riga nella configurazione dell’API gateway)
• Lo stato del dual-write — se i dati sono stati scritti su entrambi gli schemi, quale è canonico
• La finestra di obsolescenza dei dati accettabile se il database del nuovo servizio ha divergito
• L’ingegnere on-call che gestisce la decisione di rollback e la soglia temporale che attiva il rollback automatico

Roadmap di migrazione a fasi

Una roadmap strutturata in quattro fasi riduce il rischio e garantisce che ogni fase generi valore misurabile prima che inizi la successiva.

1. Fase 1 — Fondamenta (mesi 1–3): Non estraete ancora alcun servizio. Investite nei prerequisiti: osservabilità centralizzata (tracing, logging, alerting), template di pipeline CI/CD indipendenti, una container platform (Kubernetes o ECS), un catalogo di domain event e workshop di boundary mapping con stakeholder di business e ingegneria. Deliverable: un backlog di estrazione prioritizzato con mappa dei bounded context.
2. Fase 2 — Prima estrazione (mesi 3–6): Estraete un bounded context a basso rischio e alto impatto usando il pattern strangler fig. Validate il playbook di estrazione (instradamento facade, dual-write, migrazione dati, monitoraggio SLO, rollback). Questa fase è tanto una prova del processo quanto una consegna tecnica. Deliverable: un servizio deployato indipendentemente in produzione, runbook di estrazione documentato.
3. Fase 3 — Decomposizione sistematica (mesi 6–24+): Applicare il playbook validato in modo iterativo ai bounded context prioritari rimanenti. Ogni team di estrazione segue lo stesso pattern. La decomposizione dei dati accelera man mano che la proprietà del database condiviso diventa più chiara. La ristrutturazione organizzativa (manovra inversa di Conway) avviene in parallelo. Deliverable: il 60–80 % della business logic ad alta modifica in esecuzione come servizi indipendenti.
4. Fase 4 — Residualizzazione del monolite: Il monolite rimanente contiene sottosistemi stabili e poco modificati raramente toccati. Decidete esplicitamente se ogni contesto residuo giustifica ulteriori costi di estrazione. Per la maggior parte delle imprese, lasciare il 20–30 % del sistema originale in un «monolite residuale» è la decisione economicamente corretta. Deliverable: policy del monolite residuale documentata, piano di dismissione per le tabelle del database condiviso non più in uso.

FAQ

Dovremmo migrare il nostro monolite a microservizi?

Non automaticamente. Migrate quando avete problemi organizzativi concreti: team bloccati dal coupling del deployment, servizi che devono scalare in modo indipendente o requisiti di isolamento normativo (come quelli previsti dal Regolamento UE 2016/679 / Garante per la protezione dei dati personali). Se il team ha meno di 30 ingegneri, la CI/CD non è matura o il monolite funziona bene e il dolore operativo è modesto, la migrazione costerà più di quanto risparmierà. Iniziate con un audit onesto dei bounded context e un elenco chiaro dei problemi specifici che intendete risolvere.

Che cos’è il pattern strangler fig?

Il pattern strangler fig prevede di posizionare una facade di instradamento davanti al monolite e di reindirizzare incrementalmente percorsi di richiesta specifici verso nuovi microservizi, mentre il monolite continua a gestire tutto il resto. Nel tempo si estrae contesto dopo contesto finché il monolite gestisce così poco traffico da poter essere dismesso. È l’approccio più sicuro per migrare un sistema di produzione live perché è completamente incrementale e reversibile in ogni fase.

Che cos’è un monolite distribuito?

Un monolite distribuito è il risultato peggiore di una migrazione mal pianificata: più servizi che condividono ancora un unico database, catene di chiamate sincrone che attraversano l’intero sistema o una libreria condivisa che obbliga tutti i servizi a fare il deploy insieme. Si ottiene tutta la complessità operativa dei sistemi distribuiti senza alcuna indipendenza di deployment. La causa principale è quasi sempre la decomposizione dei dati ignorata o differita indefinitamente.

Quanto tempo richiede una migrazione?

Un valore significativo — un servizio deployato e scalabile in modo indipendente — può essere consegnato in 3–6 mesi con il pattern strangler fig. La decomposizione completa di un monolite enterprise di grandi dimensioni richiede 18–36 mesi. I tempi sono guidati più dalla complessità del coupling dei dati e dalla gestione del cambiamento organizzativo che dal lavoro di codifica. Pianificate che il cambiamento organizzativo richieda tanto tempo quanto il lavoro tecnico.

Come si evitano i tempi di inattività durante la migrazione?

La facade di instradamento del pattern strangler fig è il meccanismo principale: il traffico può essere reindirizzato al monolite in pochi secondi se il nuovo servizio ha problemi. Completate con dual-write durante le fasi di cutover del database, blue-green deployment a livello di servizio, feature flag nella facade e distributed tracing completo per individuare le regressioni prima che impattino tutti gli utenti. Non eseguite mai un cutover big-bang del database su un sistema live — eseguite sempre il dual-write con una finestra di validazione.

Ultimo aggiornamento: 6 giugno 2026. I benchmark di costo riflettono i dati degli ingaggi di YuSMP Group e i report di settore disponibili pubblicamente (Gartner, CNCF, ThoughtWorks Technology Radar). I costi individuali di migrazione variano in base alle dimensioni del monolite, al coupling, alla struttura del team e alla maturità dell’osservabilità.