Strangler Fig: sostituire il legacy senza Big Bang
Lo Strangler Fig consente di sostituire gradualmente un sistema legacy instradando capacità e traffico verso il nuovo fino al completo retirement.
Che cos'è
Lo Strangler Fig è una strategia di modernizzazione incrementale. Il sistema legacy continua a funzionare mentre nuove capacità vengono costruite accanto ad esso. Un punto di ingresso controllato decide, richiesta per richiesta o funzione per funzione, se servire il vecchio o il nuovo.
Perché è particolarmente adatto alla sanità
In un'applicazione clinico-amministrativa il Big Bang è rischioso: molte regole sono implicite, le integrazioni sono numerose e il fermo può avere impatto operativo. Lo Strangler riduce il raggio di esplosione perché permette di migrare una vertical slice, osservarla, confrontarla e fare rollback senza attendere che l'intera piattaforma sia stata riscritta.
Come funziona
Si introduce un punto di ingresso stabile: API Gateway, reverse proxy, BFF o Facade.
Si sceglie una capacità con confine riconoscibile, per esempio ricerca paziente, gestione ordine o consultazione episodio.
Il nuovo servizio viene implementato e collegato al gateway.
Una regola di routing sposta solo una parte del traffico o un sottoinsieme di casi d'uso.
Si osservano errori, prestazioni e differenze funzionali; se necessario si torna al legacy.
Quando il nuovo diventa autoritativo, la vecchia funzione viene dismessa e il perimetro del legacy si restringe.
Routing per capacità, non per tecnologia
Il criterio di instradamento dovrebbe essere espresso con concetti funzionali: «ricerca paziente nuova», «ordini del nuovo dominio», «viewer tramite adapter», non «porta 3001 invece della porta 3002». Il gateway conosce il routing, non la business logic.
Quando usarlo
Legacy grande e non completamente documentato.
Necessità di continuità operativa e rollback rapido.
Possibilità di individuare capability o vertical slice separabili.
Migrazione plurimestrale con convivenza inevitabile tra vecchio e nuovo.
Quando non basta
Se il nuovo servizio deve ancora usare dati e codici del vecchio, lo Strangler da solo non protegge il nuovo modello. In quel caso va combinato con Anti-Corruption Layer e Data Ownership. Se si cambia una singola implementazione dietro un'interfaccia già stabile, Branch by Abstraction può essere più semplice.
Criterio di successo
Ogni iterazione deve ridurre il perimetro del legacy. Se dopo mesi esistono solo nuove API davanti allo stesso database condiviso, il sistema è stato incapsulato, non realmente strangolato.