Cos'è lo strangler fig pattern?

Lo strangler fig pattern è una strategia di modernizzazione che sostituisce un sistema legacy in modo incrementale, mettendo uno strato di instradamento davanti al vecchio sistema e spostando le funzionalità una alla volta verso quello nuovo, finché il legacy non riceve più traffico e può essere spento. Il nome arriva da Martin Fowler, che lo descrisse nel 2004 in un articolo sul suo bliki personale, ispirandosi ai fichi strangolatori delle foreste pluviali australiane: piante che germinano sui rami di un albero ospite e lo avvolgono crescendo, sostituendolo gradualmente senza mai abbatterlo con un taglio netto. Fowler rinominò l'articolo nel 2009, da "strangler application" a "strangler fig application", proprio per rendere esplicita quella metafora botanica. L'idea centrale non è tecnica, è di gestione del rischio: invece di riscrivere tutto e sperare che il giorno del grande passaggio funzioni, si sposta una funzione alla volta, si verifica che regga in produzione, e solo allora si passa alla successiva.

Leggi anche: Modernizzazione AS/400 · La modernizzazione AS/400 porta le applicazioni ancora in produzione su AS/400, oggi IBM i, verso cloud e API, liberando dati isolati dal resto dell'azienda.

Il problema che nessuno racconta: dove sta la verità del dato

Tutto quello che si legge sullo strangler fig pattern si ferma alla definizione: strato di instradamento, migrazione incrementale, spegnimento finale. Quasi nessun contenuto italiano affronta cosa succede ai dati nella fase intermedia, che può durare mesi o anni: per un periodo esiste più di un sistema che scrive sulla stessa entità logica, il cliente, l'ordine, la giacenza di magazzino. La domanda che decide se il progetto riesce o si trascina all'infinito è una sola: in ogni momento, chi è la fonte di verità per ciascun dato? La risposta va scritta esplicitamente, funzione per funzione, non lasciata sottintesa. Un pattern comune è la scrittura a doppio binario temporanea: il nuovo servizio scrive sia sul proprio schema sia, tramite un adattatore, sul database legacy, così le funzioni non ancora migrate continuano a leggere dati corretti. Un secondo pattern è la sincronizzazione via change data capture, che replica le modifiche dal legacy al nuovo sistema (o viceversa) senza che le applicazioni debbano scriverle due volte a mano, riducendo il rischio di divergenza. Quello che va evitato sempre è la doppia scrittura non coordinata, due sistemi che accettano scritture indipendenti sulla stessa entità senza un arbitro: è lì che nascono i conflitti silenziosi, l'ordine aggiornato nel nuovo sistema ma non nel vecchio, letto da un report che nessuno ha ancora migrato. Serve inoltre un criterio oggettivo per dichiarare una funzione "davvero migrata": non basta che il codice nuovo sia in produzione, serve che tutte le letture a valle, report, integrazioni, job notturni, puntino al nuovo sistema, e che il vecchio percorso sia stato spento e non solo lasciato inattivo. Finché quel criterio non è verificato per iscritto, la migrazione dei dati resta a metà, e la convivenza prolungata dei due sistemi è il costo nascosto più comune di questi progetti.

Un esempio enterprise

Un'azienda di distribuzione con un gestionale ordini legacy vuole spostarsi verso un'architettura a microservizi. Invece di fermare tutto per una riscrittura, mette un proxy applicativo davanti al gestionale e sposta per prima il tracciamento spedizioni verso un nuovo servizio: il proxy instrada le richieste di tracciamento al nuovo sistema, il resto continua verso il legacy. Il nuovo servizio ha bisogno dello storico ordini per rispondere alle query, quindi un flusso di CDC replica in tempo quasi reale le tabelle rilevanti dal legacy verso il nuovo schema, mentre il gestionale resta l'unica fonte di verità per ordini e fatturazione finché anche queste funzioni non vengono spostate. Solo quando l'ultima funzione lascia il legacy, e i log confermano zero richieste residue per un periodo concordato, il vecchio gestionale viene spento.

Quando non usarlo

Lo strangler fig pattern ha senso quando il sistema legacy è abbastanza grande e critico da rendere rischiosa una sostituzione secca, e quando l'azienda può sostenere per mesi il costo di gestire due sistemi in parallelo. Se il sistema è piccolo, con poche integrazioni e un numero limitato di funzionalità, una riscrittura diretta costa quasi sempre meno della convivenza: costruire e mantenere uno strato di instradamento, gestire la sincronizzazione dei dati e coordinare due team su due sistemi ha un costo organizzativo reale, che va giustificato dalla dimensione del rischio evitato, non applicato per principio. Quando quel conto pende a favore della riscrittura, vale il rasoio di Occam: fra due strade che risolvono lo stesso problema, quella con meno parti in movimento è anche quella con meno modi di rompersi.