Pattern Strangler Fig: una guida pragmatica per i leader dell'ingegneria

Pattern Strangler Fig: una guida pragmatica per i leader dell'ingegneria

Il pattern strangler fig, coniato da Martin Fowler, è un approccio architetturale per sostituire gradualmente le funzionalità di un sistema legacy attraverso una facciata o un proxy che instrada il traffico verso nuovi componenti finché il vecchio sistema non può essere dismesso in sicurezza. Il nome deriva dall'albero strangler fig, che cresce intorno a un albero ospite, prendendone gradualmente il posto fino alla scomparsa dell'ospite originale. Nel software, il meccanismo è lo stesso: avvolgere, reindirizzare, sostituire, dismettere.

Tre concetti sono alla base del pattern: una facciata che intercetta tutto il traffico, l'estrazione incrementale delle funzionalità in nuovi servizi e un gate di dismissione che conferma che il sistema legacy non è più necessario. Usalo quando:

• Una riscrittura completa comporta rischi di distribuzione o aziendali inaccettabili

• Il sistema deve continuare a servire il traffico di produzione durante tutta la migrazione

• Il rilascio di funzionalità non può fermarsi per mesi mentre si completa una riscrittura

• Sia l'Azure Architecture Center sia la AWS Prescriptive Guidance lo raccomandano per la migrazione cloud a fasi di applicazioni monolitiche

Ridiculous Engineering applica questo pattern negli incarichi di modernizzazione in cui il costo di un errore è elevato e la tolleranza ai tempi di inattività è bassa.

Indice

• Perché i team scelgono il pattern strangler fig invece di una riscrittura completa

• Come funziona il pattern strangler fig a livello architetturale

• Tecniche e componenti concreti per l'implementazione

• Un playbook a fasi, dalla scoperta alla dismissione

• Come si presenta una migrazione reale: il servizio ordini

• Compromessi, insidie e quando non usare questo pattern

• Ridiculou Engineering gestisce migrazioni strangler fig end-to-end

• Punti chiave

• Fonti utili e ulteriori letture

• Domande frequenti

Perché i team scelgono il pattern strangler fig invece di una riscrittura completa

I sistemi legacy deludono i team in modi prevedibili. La base di codice è fragile, la copertura dei test è scarsa e gli ingegneri che conoscevano il design originale sono andati via. Una riscrittura completa sembra allettante finché non arriva la prima stima e l'azienda si rende conto che comporta da sei a diciotto mesi di investimenti paralleli senza rilasciare alcuna nuova funzionalità.

I problemi specifici che spingono i team verso la modernizzazione incrementale:

• Monoliti fragili in cui una modifica a un modulo rompe funzionalità non correlate

• Lacune di conoscenze nei linguaggi più datati (COBOL, PowerBuilder, prime versioni di Java EE) che rendono quasi impossibile effettuare un refactoring con sicurezza

• Vincoli normativi e di disponibilità che vietano finestre di manutenzione prolungate

• Requisiti di distribuzione continua in cui le roadmap dei prodotti non possono fermarsi per una riscrittura

• Rischio in termini di costi e tempi nelle riscritture di grandi dimensioni, che spesso superano le aspettative di budget con un margine significativo

La formulazione originale di Martin Fowler coglie bene il compromesso fondamentale:

La riduzione del rischio è il principale motore aziendale. L’approccio raccomandato da Fowler privilegia risultati costanti e visibili rispetto a un singolo evento di lancio. Per un CTO che deve difendere un budget di modernizzazione davanti al consiglio di amministrazione, “abbiamo distribuito tre nuove funzionalità questo trimestre mentre migravamo il servizio degli ordini” è una conversazione molto più semplice di “avremo qualcosa da mostrarti nel quarto trimestre del prossimo anno”.

Come funziona il pattern strangler fig a livello architetturale

L’architettura è concettualmente semplice. Ogni richiesta del client passa attraverso una facciata strangolatrice, che in genere è un gateway API, un reverse proxy o un livello di instradamento creato appositamente. La facciata analizza ogni richiesta e la instrada al sistema legacy o al nuovo servizio, a seconda delle funzionalità già migrate.

Il flusso è il seguente: client → facciata strangolatrice → monolite legacy (per le funzionalità non migrate) o nuovo microservizio (per le funzionalità migrate). Il sistema legacy e i nuovi servizi coesistono durante il periodo di migrazione. Nulla cambia nel client.

Responsabilità principali della facciata:

• Instradamento delle richieste in base al percorso, all’header, al tenant o al flag di funzionalità

• Anti-Corruption Layer (ACL) traduzione tra i modelli di dati legacy e i contratti dei nuovi servizi, come documentato dall’Azure Architecture Center

• Telemetria e registrazione dell’utilizzo per misurare quali endpoint legacy sono ancora attivi

• Instradamento A/B e canary per trasferire gradualmente percentuali di traffico ai nuovi servizi

La voce di Wikipedia sul pattern osserva che può essere applicato a più livelli di granularità, dall’avvolgimento di un singolo metodo alla migrazione di un’intera applicazione. Questa flessibilità è ciò che lo rende pratico: non è necessario impegnarsi in un’architettura completa a microservizi fin dal primo giorno.

Consiglio pratico: Strumenta la facciata prima di estrarre una singola funzionalità. La telemetria sull’utilizzo della prima settimana ti dirà quali endpoint vengono chiamati più frequentemente, quali vengono chiamati da un solo client e quali non sono stati utilizzati da mesi. Questi dati determinano l’elenco delle priorità di estrazione e spesso fanno emergere codice morto che puoi semplicemente eliminare.

Tecniche e componenti concreti per l’implementazione

Predisporre la facciata è la parte più semplice. La complessità ingegneristica risiede nella logica di instradamento, nella sincronizzazione dei dati e nel mantenimento della coerenza comportamentale tra i due sistemi durante la coesistenza.

Componenti fondamentali

1. Facciata strangolatrice (gateway API o reverse proxy): NGINX, AWS API Gateway, Azure API Management o un servizio di instradamento personalizzato. Questo è il punto di ingresso unico per tutto il traffico.

2. Anti-Corruption Layer (ACL): Un livello di traduzione che converte i modelli e la semantica dei dati legacy nel modello di dominio del nuovo servizio. Progetta gli ACL con regole di traduzione esplicite e un piano di dismissione fin dall’inizio.

3. Adattatori di servizio:Sottili wrapper che consentono al nuovo servizio di chiamare API o database legacy senza importare la logica legacy.

4. Flag delle funzionalità:Interruttori di runtime (LaunchDarkly, Unleash o un archivio di flag sviluppato internamente) che controllano quali utenti o tenant vengono instradati al nuovo servizio.

5. Punti di intercettazione:Hook all'interno del monolite che consentono alla facciata di acquisire eventi o modifiche ai dati senza modificare la logica legacy principale.

Tecniche di instradamento

• Instradamento basato sul percorso:Instrada /orders/v2/* al nuovo servizio, /orders/* al sistema legacy.

• Instradamento basato su header o tenant:Instrada tenant o client API specifici al nuovo servizio per i test con i primi utenti adottanti.

• Instradamento basato sui flag delle funzionalità:Sposta gradualmente una percentuale del traffico (1%, 10%, 50%, 100%) utilizzando un archivio di flag.

• Rilasci canary:Instrada una piccola parte del traffico di produzione al nuovo servizio e confronta i tassi di errore e la latenza prima di ampliare il rollout.

Migrazione e sincronizzazione dei dati

È nei dati che la maggior parte delle migrazioni strangler rallenta. Le opzioni, all'incirca in ordine di complessità, sono:

• Doppia scrittura:L'applicazione scrive contemporaneamente sia nel database legacy sia nel nuovo archivio dati. È semplice da implementare, ma gli errori di scrittura richiedono un'attenta logica di riconciliazione.

• Change data capture (CDC):Strumenti come Debezium trasmettono in streaming le modifiche a livello di riga dal database legacy al nuovo servizio quasi in tempo reale. È preferibile usare CDC per i sistemi con molte scritture, nei quali la latenza della doppia scrittura è inaccettabile.

• Event sourcing:Riproduci gli eventi di dominio per ricostruire lo stato nel nuovo servizio. È una soluzione potente, ma richiede che il sistema legacy emetta eventi puliti.

• Backfill in blocco:Migrazione una tantum dei dati storici, in genere eseguita prima dell'avvio in produzione e riconciliata con i delta CDC.

Consiglio dell'esperto: Per i percorsi di lettura non critici, la consistenza eventuale è generalmente accettabile. Riserva la complessità della doppia scrittura sincrona alle transazioni finanziarie, ai conteggi dell'inventario e a tutti i dati per i quali una lettura obsoleta ha una reale conseguenza aziendale.

Checklist di test e monitoraggio

• Test end-to-end che esercitano sia i percorsi del codice legacy sia quelli del nuovo codice attraverso la facciata

• Test dei contratti tra la facciata e ogni servizio downstream

• Dashboard canary che monitorano il tasso di errore, la latenza p95 e la parità delle metriche aziendali

• Avvisi sulle divergenze comportamentali: se il nuovo servizio restituisce risultati diversi rispetto al sistema legacy per lo stesso input, è necessario saperlo prima degli utenti

Playbook strutturato per fasi, dalla scoperta alla dismissione

Fase	Attività principali	Ruoli	Criterio di successo
1. Discovery	Inventaria gli endpoint, mappa le dipendenze, strumenta la telemetria	Architetto, Data Engineer	Mappa delle dipendenze completata; identificati i 10 endpoint principali per volume di chiamate
2. Identifica i punti di separazione	Definisci i confini dei servizi, identifica i punti di traduzione dell’ACL	Architetto, Product Owner	Contesti delimitati documentati; schema ACL abbozzato
3. Crea la facciata e l’ACL	Distribuisci il livello di instradamento, implementa l’ACL, convalida la parità	Architetto, SRE	Il 100% del traffico passa attraverso la facciata senza regressioni
4. Estrai la prima funzionalità	Migra un endpoint a basso rischio e alto valore verso il nuovo servizio	Team di ingegneria, QA	Il nuovo servizio gestisce l’endpoint di destinazione; il tasso di errore corrisponde alla baseline legacy
5. Instrada e monitora	Sposta il traffico gradualmente usando flag delle funzionalità e deployment canary	SRE, Responsabile della migrazione	La latenza p95 è entro il 10% rispetto alla legacy; zero alert di incoerenza dei dati
6. Itera e scala	Ripeti l’estrazione per le funzionalità rimanenti in ordine di priorità	Team completo	Ogni funzionalità estratta supera i test di contratto e il gate canary
Dismetti il sistema legacy	Conferma l’assenza di chiamate in ingresso, trasferisci la proprietà dei dati, archivia	Architetto, Data Engineer, SRE	Nessun traffico verso il sistema legacy per 30 giorni consecutivi; parità dei dati confermata; piano di rollback documentato

Il gate di dismissione merita particolare attenzione. Un modulo legacy non è pronto per essere ritirato finché non vengono soddisfatte tre condizioni: nessuna chiamata in ingresso per un periodo definito (30 giorni è un minimo ragionevole), trasferimento confermato della proprietà dei dati al nuovo servizio e dati storici archiviati o migrati con un percorso di lettura verificato. Saltare una qualsiasi di queste condizioni crea il risultato peggiore: un sistema “dismesso” che continua silenziosamente a gestire traffico.

Per quanto riguarda le tempistiche, un ambito ridotto richiede in genere alcuni mesi, un ambito medio come un intero dominio richiede meno di un anno e un ambito ampio che prevede la decomposizione completa del monolite è un programma pluriennale di lunga durata, come riconosce esplicitamente la guida di Fowler.

Come si presenta una migrazione reale: il servizio degli ordini

Un punto di partenza comune per le migrazioni strangler è il servizio degli ordini in un monolite retail o SaaS. Ecco la sequenza della migrazione:

• Passaggio 1 — Estrai il modello di lettura: Crea un nuovo microservizio di interrogazione degli ordini che legga da una copia replicata della tabella degli ordini legacy. Instrada tutte le richieste GET /orders/* attraverso la facciata verso il nuovo servizio. Il sistema legacy gestisce tutte le scritture.

• Passaggio 2 — Aggiungi l’instradamento della facciata per gli endpoint degli ordini: Distribuisci la facciata del gateway API. Conferma che il 100% del traffico degli ordini passi attraverso di essa senza regressioni della latenza.

• Passaggio 3 — Implementa l’ACL: Il modello degli ordini legacy probabilmente contiene campi denormalizzati, codici di stato espressi come numeri interi e ID cliente associati a uno schema diverso. L’ACL traduce questi elementi prima che il nuovo servizio li riceva.

• Passaggio 4 — Migrare i flussi di scrittura con il CDC: Configura Debezium (o un equivalente) per trasmettere le scritture degli ordini dal database legacy al registro degli eventi del nuovo servizio. Convalida la parità dei dati tra entrambi gli archivi.

• Passaggio 5 — Convalidare ed eseguire il canary: Instrada il 5% del traffico di scrittura al nuovo servizio. Monitora le discrepanze nel numero di ordini, le transizioni di stato fallite e gli errori nelle notifiche downstream.

• Passaggio 6 — Eseguire il cutover e dismettere il sistema legacy: Sposta il 100% del traffico al nuovo servizio. Monitora per 30 giorni. Dismetti le tabelle legacy degli ordini dopo aver confermato l'assenza di letture dirette.

L'architettura durante la coesistenza: client → façade del gateway API → monolite legacy (inizialmente per le scritture) e nuovo microservizio degli ordini (prima per le letture, poi per le scritture). Entrambi i servizi condividono un flusso di replica CDC durante la transizione. I diagrammi scaricabili dell'Azure Architecture Center illustrano chiaramente questo instradamento graduale.

Fase di migrazione	Gestisce il legacy	Gestisce il nuovo servizio	Controllo di convalida
Estrazione delle letture	Tutte le scritture, tutte le letture	Letture degli ordini (GET)	Parità dei dati nei risultati di lettura
Migrazione delle scritture (canary)	95% delle scritture	5% delle scritture	Tasso di errore, parità del numero di ordini
Cutover completo	Niente	Tutto il traffico degli ordini	Conferma di assenza di traffico per 30 giorni
Dismissione	Archiviato	Tutto il traffico degli ordini	Proprietà dei dati trasferita

Consiglio: Esegui la checklist di migrazione aziendale per qualsiasi endpoint rivolto ai clienti che influisca sulla SEO o sugli URL pubblici. Una migrazione strangler che modifica la struttura degli URL senza reindirizzamenti corretti può danneggiare il traffico organico tanto quanto una riscrittura eseguita male.

Compromessi, insidie e quando non utilizzare questo pattern

Il pattern strangler fig non è sempre la scelta giusta. Se utilizzato senza attenzione, crea una propria categoria di problemi.

Rischi e mitigazioni:

• Complessità del routing: La façade diventa una dipendenza critica nel percorso. Mitiga il rischio con circuit breaker, controlli di integrità e un fallback testato al sistema legacy per ogni route.

• Problemi di coerenza dei dati: La doppia scrittura e il CDC introducono entrambi finestre di incoerenza. I team spesso sottovalutano l'impegno ingegneristico necessario per mantenere sincronizzati i database.

• La façade come collo di bottiglia: Un API gateway sottodimensionato aggiunge latenza a ogni richiesta. Esegui test delle prestazioni sulla façade sotto il carico di produzione prima di instradare traffico reale.

• Costi della coesistenza a lungo termine: Gestire due sistemi in parallelo raddoppia il sovraccarico operativo. Prevedilo esplicitamente nel budget; alcuni moduli legacy potrebbero non giustificare mai una migrazione completa e dovrebbero rimanere isolati dietro la facciata a tempo indeterminato.

• Accoppiamento nascosto: I sistemi legacy spesso presentano effetti collaterali non documentati (trigger di audit, processi batch, integrazioni downstream) che emergono solo dopo l'estrazione. Una fase di analisi approfondita permette di individuare la maggior parte di questi elementi.

Checklist decisionale rapida — usa il pattern strangler fig quando:

1. Il sistema deve rimanere operativo per tutta la migrazione (senza finestre di manutenzione)

2. Una riscrittura big bang richiederebbe più di 6 mesi e bloccherebbe il rilascio di nuove funzionalità

3. Puoi definire confini o punti di separazione chiari nel codice esistente

4. Il team ha la capacità di gestire due sistemi in parallelo

5. La complessità della migrazione dei dati è gestibile con CDC o doppia scrittura

Non usarlo quando:

1. Il sistema legacy non presenta punti di separazione identificabili (un vero “grande groviglio di fango” senza confini di dominio)

2. Il team non dispone della capacità SRE necessaria per monitorare simultaneamente due sistemi

3. L'ambito della migrazione è così ridotto (un singolo microservizio con API pulite) che una sostituzione diretta comporta meno rischi

4. I vincoli normativi vietano di eseguire in parallelo i sistemi legacy e quelli nuovi

Per i team che affrontano le sfide più ampie dell'integrazione dei sistemi legacy il pattern è uno strumento all'interno di un più ampio toolkit di modernizzazione, non una risposta universale.

Ridiculous Engineering gestisce migrazioni strangler fig end-to-end

La maggior parte dei team intende modernizzare in modo incrementale. Meno numerosi sono quelli che dispongono dell'esperienza architetturale, della competenza nell'ingegneria dei dati e della capacità SRE necessarie per eseguire il processo senza che la migrazione si trascini per anni o che la facciata diventi silenziosamente il nuovo sistema legacy.

Ridiculous Engineering’s sviluppo software personalizzato practice gestisce incarichi di migrazione strangler fig dalla fase di analisi alla dismissione: mappatura delle dipendenze, progettazione della facciata e degli ACL, configurazione della pipeline CDC, gestione del rilascio canary e supporto a lungo termine una volta che i nuovi servizi sono operativi. Introduciamo criteri misurabili in ogni fase, così sai esattamente quando una funzionalità è pronta per il passaggio e quando è sicuro ritirare il modulo legacy. Se hai un monolite da trasformare e un'azienda che non può fermarsi durante il processo, pianifica un incarico di analisi con il nostro team.

Punti chiave

Il pattern strangler fig è la scelta giusta quando una riscrittura big bang è troppo rischiosa, il sistema deve rimanere operativo e puoi definire punti di separazione chiari nel codice esistente.

Punto	Dettagli
Strumenta prima di estrarre	Distribuisci prima la facciata e aggiungi la telemetria; i dati sull'utilizzo determinano la priorità di estrazione.
Gli ACL impediscono la contaminazione legacy	Progetta Anti-Corruption Layer con regole di traduzione esplicite e un piano di dismissione fin dal primo giorno.
La sincronizzazione dei dati è la parte più difficile	La replica basata su CDC gestisce i sistemi con molti carichi di scrittura; la doppia scrittura è adatta ai flussi più semplici, ma richiede una logica di riconciliazione.
La dismissione prevede un criterio rigoroso	Nessun traffico legacy per 30 giorni consecutivi, oltre alla conferma della parità dei dati, prima di ritirare qualsiasi modulo.
Ridiculous Engineering	Gestisce incarichi strangler fig end-to-end con criteri di fase misurabili, progettazione degli ACL e configurazione della pipeline CDC.

Fonti utili e ulteriori letture

• Martin Fowler — StranglerFigApplication: L'origine del pattern, la metafora e la logica fondamentale di riduzione del rischio. Inizia da qui.

• Azure Architecture Center — Pattern dello strangolatore: Diagrammi di instradamento per fasi, indicazioni sugli ACL e considerazioni sull’implementazione del team di architettura cloud di Microsoft.

• AWS Prescriptive Guidance — Strangolatore: Casi d’uso per l’instradamento e gli ACL con note sull’implementazione cloud-native; tratta gli approcci dual-write e CDC.

• Wikipedia — Pattern dello strangolatore: Riferimento conciso che tratta le opzioni di granularità e la registrazione dell’utilizzo come strumento di migrazione.

• Ridiculous Engineering — Integrazione di sistemi legacy: Pattern pratici per una modernizzazione non dirompente dal team Ridiculous Engineering.

• Ridiculous Engineering — Costi della modernizzazione COBOL: Lezioni su budget e tempistiche tratte da progetti di modernizzazione di linguaggi legacy.

Domande frequenti

Che cos’è il pattern dello strangolatore nell’architettura software?

Il pattern dello strangolatore è un approccio alla sostituzione incrementale di un sistema legacy, che instrada il traffico attraverso una facciata verso nuovi servizi, una funzionalità alla volta, finché il sistema legacy non può essere dismesso. Martin Fowler ha coniato il termine, traendo ispirazione dalla biologia del fico strangolatore.

In che modo il pattern dello strangolatore differisce da una riscrittura big bang?

Una riscrittura big bang sostituisce l’intero sistema in una sola volta, bloccando la distribuzione di funzionalità e concentrando tutti i rischi in un unico lancio. L’approccio dello strangolatore migra una funzionalità alla volta, distribuisce valore continuamente e consente il rollback in qualsiasi fase.

Che cos’è un Anti-Corruption Layer e perché è importante?

Un Anti-Corruption Layer (ACL) è un componente di traduzione che converte i modelli e la semantica dei dati legacy nel modello di dominio del nuovo servizio, impedendo che le decisioni progettuali legacy si infiltrino nel nuovo sistema. Senza di esso, i nuovi servizi tendono a ereditare gli stessi problemi strutturali del sistema che stanno sostituendo.

Quanto dura solitamente una migrazione con il pattern dello strangolatore?

La durata dipende dall’ambito: una migrazione di piccole dimensioni dura in genere alcuni mesi, un intero dominio come un servizio per gli ordini dura meno di un anno, mentre la decomposizione di un monolite completo è un programma pluriennale di lunga durata.

Quando non si dovrebbe usare il pattern dello strangolatore?

Evitatelo quando il sistema legacy non presenta punti di separazione identificabili, quando il team non dispone della capacità SRE necessaria per gestire due sistemi in parallelo o quando l’ambito della migrazione è abbastanza ridotto da rendere una sostituzione diretta meno rischiosa rispetto alla realizzazione e alla manutenzione di una facciata.

Consigliati

• Vibe Coding: lo stiamo facendo nel modo sbagliato? | Ridiculous Engineering

• Come l’IA sta trasformando la cultura ingegneristica e la crescita professionale | Ridiculous Engineering

• Il settore tecnologico punta sulle competenze analitiche per rafforzare la propria forza lavoro | Ridiculous Engineering

• Liberare la creatività con la teoria dei vincoli | Ridiculous Engineering