Il problema: il sistema legacy che non puoi spegnere
Hai un gestionale PHP 5.6 con 200.000 righe di codice, nessun test, query SQL inline ovunque, e HTML mescolato con logica di business. Il sistema funziona, 50 utenti lo usano ogni giorno, e il business dipende da esso. Riscrivere da zero richiederebbe 12 mesi e nessuno può permettersi di restare senza sistema per un anno. Ma ogni modifica al codice esistente e un rischio: il codice e fragile e imprevedibile.
Lo Strangler Fig Pattern, proposto da Martin Fowler, prende il nome dal fico strangolatore: una pianta tropicale che cresce attorno a un albero esistente, lo avvolge gradualmente, e alla fine lo sostituisce completamente. Il vecchio albero muore, ma il nuovo e già al suo posto.
Come funziona: tre fasi
1. Intercetta (Proxy/Facade)
Metti un proxy davanti al sistema legacy: un reverse proxy (Nginx), un API gateway, o un middleware applicativo. Inizialmente, il proxy inoltra tutte le richieste al sistema legacy senza modifiche. Il sistema continua a funzionare identicamente, ma ora hai un punto di intercettazione.
2. Sostituisci un pezzo alla volta
Scegli una funzionalita — la più semplice, la meno rischiosa — e reimplementala nel nuovo sistema. Configura il proxy per instradare le richieste di quella funzionalita al nuovo sistema invece che al legacy. Tutte le altre richieste continuano ad andare al legacy. Il vecchio e il nuovo coesistono.
3. Ripeti fino al completamento
Funzionalita dopo funzionalita, il nuovo sistema cresce e il legacy si restringe. Ogni migrazione e indipendente, testabile e reversibile (basta cambiare la regola del proxy per tornare al legacy). Quando l'ultima funzionalita e migrata, il sistema legacy viene spento.
Esempio pratico: migrare un gestionale
- Mese 1: metti Nginx come proxy. Tutto va al legacy. Zero rischio.
-
Mese 2: reimplementa la pagina "lista clienti" nel nuovo sistema (PHP 8.4, framework moderno, test). Il proxy instrada
/cliential nuovo sistema. -
Mese 3: reimplementa la "scheda cliente". Il proxy instrada
/clienti/*al nuovo sistema. -
Mese 4: reimplementa il modulo fatturazione. Il proxy instrada
/fatture/*al nuovo. - Mese 8: l'ultima funzionalita viene migrata. Il legacy viene spento.
In ogni momento, il sistema funziona. Gli utenti non notano interruzioni. Se una migrazione ha problemi, il proxy torna a instradare al legacy in secondi.
Strategie di condivisione dati
Il punto più delicato e il database. Due approcci:
- Database condiviso: vecchio e nuovo sistema leggono e scrivono sullo stesso database. Più semplice, ma il nuovo sistema deve convivere con lo schema legacy.
- Database separati con sync: il nuovo sistema ha il proprio database. Un meccanismo di sincronizzazione (eventi, trigger, ETL) tiene i due allineati. Più complesso, ma il nuovo sistema ha uno schema pulito.
Errori comuni
- Migrare troppo in una volta: la forza dello Strangler Fig e la gradualita. Blocchi piccoli, rilasci frequenti.
- Non avere il proxy dall'inizio: senza un punto di intercettazione, non puoi instradare le richieste selettivamente.
- Ignorare i dati: il codice si migra, ma i dati devono essere consistenti tra vecchio e nuovo.
Quando usare lo Strangler Fig
- Usa Strangler Fig quando il sistema legacy deve restare operativo durante la migrazione
- Usa Strangler Fig quando la riscrittura completa e troppo rischiosa o troppo lunga
- Usa Strangler Fig quando vuoi rilasciare valore incrementalmente, non tutto alla fine
- Non usare Strangler Fig se il sistema e piccolo e la riscrittura richiede poche settimane
- Non usare Strangler Fig se non puoi mettere un proxy davanti al sistema legacy
Lo Strangler Fig Pattern non e solo una tecnica di migrazione: e una filosofia del cambiamento incrementale. Non serve il coraggio di buttare via tutto e ripartire da zero. Serve la disciplina di sostituire un pezzo alla volta, validando ogni passo, senza mai perdere il terreno sotto i piedi.