Zero downtime: la migrazione strangler pattern in 7 passi per architetti

Usa l'approccio della migrazione con strangler pattern quando devi sostituire un monolite grande e critico per il business senza downtime: introduci una facciata di routing, estrai un bounded context alla volta e verifica ogni fetta con traffico shadow prima del passaggio definitivo. Il compromesso è reale. Rinunci alla rapidità di un big bang in cambio di un percorso più lungo ma più sicuro, con l'onere del doppio esercizio, però ottieni valore incrementale, una via di rollback funzionante e nessuno dei rischi tutto o niente di un unico weekend di cutover.

---

In sintesi:

• La facciata iniziale deve essere un livello di routing operativo e sotto controllo di versione, che smista il traffico senza modificare le richieste; saltare questo passaggio porta a rollback complicati più avanti.

• Un anti-corruption layer e feature flag con proprietari chiari e date di scadenza evitano che le stranezze del legacy contaminino il nuovo sistema e che le impalcature diventino permanenti.

• I passi vanno affrontati in sequenza: prima scomponi il sistema in bounded context, poi migra gradualmente instradando prima le letture e solo dopo le scritture, con criteri di accettazione e condizioni di rollback definiti in anticipo.

• CDC abbinato al pattern transactional outbox è il metodo di sincronizzazione dei dati più sicuro per le migrazioni lunghe, perché la doppia scrittura espone a incoerenze e guasti silenziosi.

• Il monitoraggio continuo di latenza, tassi di errore e metriche di business con soglie predefinite è indispensabile per un passaggio sicuro, e automatizzare i rollback garantisce un ripristino rapido in caso di problemi.

---

Che cos'è lo strangler pattern e quando conviene usarlo?

Lo strangler fig pattern prende il nome dall'albero vero e proprio: un rampicante che cresce attorno a un tronco ospite e ne assume gradualmente il ruolo strutturale, finché il legno originale non serve più. In termini software, metti davanti al sistema legacy una facciata che instrada ogni richiesta in arrivo o al vecchio sistema o a un nuovo servizio, funzionalità dopo funzionalità, finché al codice legacy non resta più nulla da fare. È lo strangler fig pattern così come lo definisce l'Azure Architecture Center di Microsoft, ed è il riferimento standard per chiunque stia pianificando una migrazione di questo tipo.

Non tutte le sostituzioni di sistemi legacy richiedono tanta cerimonia. Un piccolo strumento interno con tre utenti che tollera un weekend di fermo sopravvive tranquillamente a una riscrittura. Ricorri all'architettura strangler pattern quando valgono diversi di questi punti:

• Il sistema ha requisiti di disponibilità reali e un passaggio fallito danneggerebbe il fatturato o la fiducia dei clienti.

• Riesci a individuare bounded context distinti (fatturazione, magazzino, autenticazione) invece di un unico groviglio di logica.

• Hai accesso sufficiente al codice legacy e al suo livello dati per intercettare e duplicare il traffico.

• Gli stakeholder preferiscono risultati incrementali piuttosto che aspettare un anno per un unico grande lancio a effetto.

Martin Fowler, che ha reso popolare la strangler fig metaphor, descrive la modernizzazione come un lavoro di scoperta. Difficilmente conosci in anticipo tutte le stranezze del legacy: le impari facendo girare il nuovo servizio su traffico reale e osservando dove si discosta dal vecchio.

Quali componenti di base servono prima di estrarre qualsiasi cosa?

Quattro elementi devono esistere prima di toccare il primo bounded context, e saltarne anche uno solo è il modo più sicuro per trasformare una migrazione strangler in un cantiere permanente e mai finito.

1. La facciata. Può essere un gateway API, un reverse proxy come Nginx o un router realizzato su misura. Le decisioni di instradamento possono basarsi sul percorso URL, su un header della richiesta, sul segmento di utenza o su una suddivisione canary in percentuale, e la choice of façade shapes everything downstream, incluso il livello di granularità del rollback.

2. L'anti-corruption layer (ACL). Traduce tra il modello dati del sistema legacy e quello del nuovo servizio, così le stranezze del vecchio sistema non filtrano nel codice nuovo e pulito. I contract test su questo livello intercettano le rotture prima che lo faccia la produzione.

3. I feature flag. Tieni separati i flag di rilascio (che attivano un nuovo percorso di codice per gli utenti reali), i flag operativi (che regolano il comportamento in base al carico o alla configurazione) e gli interruttori di emergenza (un ripristino totale immediato). Ogni flag ha bisogno di un proprietario con nome e cognome e di una data di scadenza, altrimenti diventa un'impalcatura permanente che nessuno ricorda di aver approvato.

4. Comparatore e strumenti per il traffico shadow. Invia il traffico di produzione a entrambi i sistemi, confronta gli output campo per campo e promuovi il nuovo percorso solo quando le discrepanze scendono sotto una soglia accettabile definita in anticipo, non improvvisata sotto pressione.

Consiglio: Metti in agenda un promemoria per la rimozione di ogni feature flag. Un flag senza data di scadenza è un flag destinato a sopravvivere all'ingegnere che lo ha scritto.

Come si imposta passo dopo passo una migrazione con strangler pattern?

L'ordine conta più degli strumenti. Gli architetti che saltano dei passaggi qui sono quelli che si ritrovano con un monolite distribuito invece che con un sistema modernizzato.

1. Fai l'inventario e scomponi per dominio. Mappa il sistema legacy in bounded context prima di scrivere una sola riga di codice nuovo. È qui che la maggior parte delle migrazioni prende slancio oppure si arena nell'analisi.

2. Installa la facciata come punto di innesto neutro. In questa fase deve instradare tutto al sistema legacy senza modifiche, e dal primo giorno deve stare sotto controllo di versione.

3. Scegli la prima fetta per valore o per basso accoppiamento. Privilegia una funzionalità che conta per il business ma che non tocca altri sei sottosistemi. Una practical migration guide for architects consiglia di partire da fette verticali di business, non da livelli tecnici orizzontali come «tutte le chiamate al database».

4. Costruisci l'ACL e il nuovo servizio, poi fallo girare in parallelo con traffico shadow e un comparatore che sorveglia le divergenze.

5. Prima le letture, poi le scritture. Porta in canary una piccola percentuale di traffico di lettura sul nuovo percorso, tieni la posizione, amplia e solo a quel punto inizia a migrare le scritture, quando le letture si sono dimostrate stabili.

6. Definisci criteri di accettazione e condizioni di rollback prima di aumentare il traffico, non dopo che qualcosa si è rotto alle due di notte.

7. Dismetti in modo formale. Rimuovi il percorso di codice legacy, pulisci lo schema e ritira la regola di routing della facciata per quella funzionalità a una data pianificata.

Fase	Rischio principale se la salti	Complessità del rollback
Installazione della facciata	Nessun punto di innesto sicuro per instradare più avanti	Bassa, basta ripristinare la configurazione
ACL + traffico shadow	Le stranezze dei dati legacy corrompono il nuovo servizio	Media
Canary sulle letture	Discrepanze silenziose negli output arrivano agli utenti	Media
Canary sulle scritture	Divergenza dei dati tra i due sistemi	Alta
Dismissione	Il debito della facciata resta a tempo indeterminato	Non applicabile, è a senso unico

Quale strategia dati scegliere: CDC, outbox o doppia scrittura?

È sulla migrazione dei dati che falliscono davvero la maggior parte dei progetti con architettura strangler pattern, non sulla logica di instradamento. Due sistemi che scrivono su due archivi dati creano un problema di sincronizzazione che non sparisce del tutto finché uno dei due archivi non viene dismesso.

La doppia scrittura, in cui l'applicazione scrive sia sul vecchio sia sul nuovo database nella stessa richiesta, sulla lavagna sembra semplice e in produzione si rompe di continuo. Se la seconda scrittura fallisce dopo che la prima è andata a buon fine, ti ritrovi con dati incoerenti in silenzio e nessun segnale integrato che qualcosa sia andato storto.

Il change data capture (CDC) abbinato al pattern transactional outbox è la strada più sicura e preferita nel settore. Il pattern outbox scrive la modifica di business e il record dell'evento nella stessa transazione di database, poi un processo di relay separato (per esempio Debezium che legge il write-ahead log del database) pubblica l'evento su un bus di messaggi in modo asincrono. Nulla va perso, perché l'evento e la scrittura di business o vengono confermati entrambi o vengono annullati entrambi.

Le indicazioni di chi lavora sul campo sono concordi su questo compromesso: la doppia scrittura è fragile e transitoria, mentre CDC più outbox è l'approccio preferito senza downtime per qualsiasi cosa debba restare in funzione più di qualche settimana.

Per domini critici come i pagamenti o i permessi, nemmeno CDC e outbox bastano da soli. Esegui scritture shadow con un confronto esaustivo campo per campo e pretendi una finestra di accettazione a zero discrepanze prima di lasciare che il nuovo sistema gestisca davvero il traffico in scrittura. Sbagliare un controllo dei permessi ha conseguenze ben diverse dallo sbagliare la descrizione di un prodotto, e il tuo piano di migrazione deve tenerne conto in modo esplicito.

Quali test e quali reti di sicurezza servono in produzione?

I comparatori del traffico shadow hanno bisogno di soglie di accettazione definite prima di portare anche solo l'uno per cento del traffico di lettura reale sul nuovo percorso, non dopo. Decidi in anticipo che cosa significa «abbastanza vicino» per l'output del comparatore, perché «lo capiremo quando lo vedremo» non è una soglia.

Una volta attivo il nuovo percorso, tieni d'occhio in continuazione questi segnali:

• I percentili di latenza (p50, p95, p99), non solo le medie, che nascondono i guasti sulla coda.

• Il tasso di errore del nuovo servizio confrontato con la linea di riferimento del legacy sulla stessa fetta di traffico.

• La parità delle metriche di business: numero di ordini, ricavi orari, tasso di accessi riusciti, insomma quello che conta davvero per l'azienda.

• Gli ID di correlazione propagati attraverso entrambi i sistemi, così puoi seguire una singola richiesta attraverso la facciata, i due backend e il comparatore.

Definisci un calendario canary con periodi di attesa reali. E non aumentare mai il traffico un venerdì pomeriggio.

Consiglio: Automatizza il rollback verso una configurazione della facciata nota come funzionante e tenuta sotto controllo di versione, poi cronometralo. Se l'esecuzione di un rollback richiede più di cinque minuti, non è ancora una vera rete di sicurezza: è una speranza.

Che cosa non deve mancare nella checklist di ogni architetto?

Ampersand Labs ha condotto migrazioni legacy per organizzazioni con eredità tecniche davvero complicate, tra cui la gestione di centinaia di siti web interconnessi per un partito politico svizzero da un unico sistema, e alcuni controlli distinguono con costanza le migrazioni che arrivano in fondo da quelle che restano in stallo per anni:

• Assegna alla facciata stessa un proprietario con nome e cognome e un obiettivo di livello di servizio. È infrastruttura di produzione, non un ponte provvisorio.

• Fissa una data di dismissione per ogni funzionalità estratta lo stesso giorno in cui inizi a estrarla, non dopo che è andata in produzione.

• Preferisci fette verticali per bounded context ai livelli tecnici orizzontali, perché è proprio con il taglio orizzontale che si costruiscono monoliti distribuiti per sbaglio.

• Tieni coinvolti ingegneri senior dalla pianificazione all'estrazione fino alla consegna, perché il contesto perso a metà progetto è esattamente il motivo per cui un debito «temporaneo» della facciata diventa permanente.

• Pretendi tre risultati per ogni estrazione: un rapporto del comparatore, un runbook di rollback scritto e la pull request di dismissione che rimuove il percorso legacy.

Senza un obiettivo di ritiro vincolante, il codice legacy resta lì e i risparmi promessi all'azienda non compaiono mai davvero nei conti di nessuno.

Fatti affiancare da ingegneri senior nella tua migrazione strangler

Le migrazioni con strangler pattern andrebbero condotte come descritto in questa guida: prima la facciata, un bounded context alla volta, i dati del comparatore prima di ogni passaggio. Il vantaggio di questo approccio è la continuità nella guida del progetto, con ingegneri senior coinvolti dalla prima conversazione sull'architettura fino all'ultima pull request di dismissione, così il piano di estrazione resta coerente.

Questa continuità conta soprattutto proprio sul lavoro di cui parla questo articolo: le migrazioni di sistemi legacy e i progetti di replatforming, dove perdere conoscenza interna a metà strada è ciò che trasforma un piano da sei mesi in una corsa affannosa di diciotto. Ampersand si occupa anche dell'integrazione di sistemi e del lavoro sulle API da cui dipendono le pipeline CDC e outbox, oltre al supporto continuativo una volta che la facciata è in produzione.

Se stai definendo il perimetro di una migrazione e vuoi il parere di un ingegnere senior sulla tua architettura prima di impegnarti, dai un'occhiata ai prezzi attuali e alle modalità di collaborazione oppure ai progetti software svizzeri più recenti per vedere come funziona l'approccio nella pratica.

Fonti

Per approfondire gli aspetti tecnici oltre questa guida, parti dalle fonti di riferimento: la scheda dell'Azure Architecture Center di Microsoft sullo strangler fig pattern, il post originale sul bliki di Martin Fowler e la Wikipedia summary per una panoramica enciclopedica rapida. Per i dettagli implementativi di CDC e outbox, l'approfondimento pratico dell'HLD Handbook tratta in profondità i compromessi tra gli strumenti. Se la tua migrazione tocca URL pubblici, vale la pena leggere una checklist SEO per le migrazioni prima di definire le regole di routing della facciata.

• strangler fig pattern

• strangler fig metaphor

• choice of façade shapes everything downstream

• practical migration guide for architects

Domande frequenti

Che cos'è lo strangler pattern nell'architettura software?

È una tecnica di migrazione in cui una facciata di routing si mette davanti al sistema legacy e invia ogni richiesta o al vecchio codice o a un nuovo servizio sostitutivo. Col tempo sempre più traffico passa ai nuovi servizi, finché il sistema legacy può essere dismesso del tutto.

Quanto dura una migrazione con strangler pattern?

Dipende dalle dimensioni e dalla complessità del sistema, ma le raccolte di casi del settore mostrano in modo costante che le migrazioni strangler longer than big-bang rewrites while carrying lower deployment risk. Aspettati tempi nell'ordine dei mesi per un singolo bounded context e potenzialmente di anni per un intero patrimonio applicativo legacy.

La doppia scrittura è mai accettabile durante una migrazione?

La doppia scrittura può funzionare come ponte a breve termine per dati poco critici, ma è fragile: un guasto parziale lascia i due sistemi incoerenti in silenzio. Per tutto ciò che resta attivo più di qualche settimana, CDC combinato con il pattern transactional outbox è lo standard più sicuro.

Qual è l'errore più grande che si commette con lo strangler pattern?

Trattare la facciata come qualcosa di provvisorio. Senza un proprietario assegnato, un SLO e una data di dismissione fissata il primo giorno, la facciata e i vecchi percorsi di codice tendono a restare per sempre invece di essere ritirati.

Ampersand Labs può seguire una migrazione strangler dall'inizio alla fine?

Sì. Ampersand Labs offre migrazione di sistemi legacy e replatforming guidati da ingegneri senior, dalla pianificazione fino alla dismissione, insieme al lavoro di integrazione dei sistemi richiesto dalle pipeline CDC e outbox. I dettagli sui prezzi attuali sono indicati nella pagina dei prezzi di Ampersand Labs.

Da leggere anche

• Migrazione di sistemi legacy e replatforming a Zurigo

• Die Mitte: oltre 600 siti web per un partito politico svizzero da un unico sistema.

• Integrazione di sistemi e sviluppo di API a Zurigo

• Habitects AG: la parte tecnica di una piattaforma per la ristrutturazione di bagni, fino alla fusione.