Modello Fig strangler

Azure Migrate

Migrare in maniera incrementale un sistema legacy, sostituendo gradualmente parti specifiche di funzionalità con nuove applicazioni e servizi. Mano a mano che le funzionalità del sistema precedente vengono sostituite, il nuovo sistema sostituisce tutte le funzionalità del sistema precedente fino a quando non è possibile effettuarne la completa dismissione.

Contesto e problema

Con l'invecchiamento dei sistemi, gli strumenti di sviluppo, le tecnologie di hosting e perfino le architetture con cui sono stati compilati possono diventare obsoleti. Con l'aggiunta di nuove caratteristiche e funzionalità, la complessità delle applicazioni può aumentare notevolmente, rendendo i sistemi più difficili da gestire o ostacolando l'aggiunta di nuove funzionalità.

La sostituzione totale di un sistema complesso può rappresentare un impegno notevole. Spesso è necessario migrare con gradualità verso il nuovo sistema, conservando quello precedente per gestire le funzionalità di cui non è stata ancora eseguita la migrazione. Tuttavia, l'esecuzione di due versioni distinte di un'applicazione implica che i client sappiano dove si trovano le singole funzionalità. Ogni volta che viene eseguita la migrazione di una funzione o di un servizio, i client devono essere aggiornati affinché puntino alla nuova posizione.

Soluzione

Sostituire gradualmente parti specifiche di funzionalità con nuove applicazioni e servizi. Creare un'interfaccia che intercetta le richieste inviate al sistema back-end legacy. L'interfaccia indirizza tali richieste all'applicazione legacy o ai nuovi servizi. Le funzionalità esistenti possono essere migrate nel nuovo sistema gradualmente, e i consumer possono continuare a usare la stessa interfaccia senza percepire l'avvenuta migrazione.

Diagram of the Strangler Fig pattern

Questo modello contribuisce a ridurre i rischi implicati dalla migrazione e a diluire l'attività di sviluppo nel tempo. Grazie all'interfaccia che indirizza gli utenti in modo sicuro all'applicazione corretta, è possibile aggiungere le funzionalità al nuovo sistema al ritmo preferito, assicurando al contempo il funzionamento continuo dell'applicazione legacy. Nel tempo, le funzionalità vengono migrate nel nuovo sistema e il sistema legacy viene sostituito fino a non essere più necessario. Una volta completato questo processo, sarà possibile ritirare il sistema legacy in modo sicuro.

Considerazioni e problemi

  • Considerare la modalità di gestione di archivi dati e servizi che possono essere potenzialmente usati tanto dai sistemi legacy quanto da quelli nuovi. Verificare che entrambi possano accedere a queste risorse simultaneamente.
  • Strutturare nuove applicazioni e servizi in modo che possano essere facilmente intercettati e sostituiti in future migrazioni fig strangler.
  • A un certo punto, al termine della migrazione, la facciata figa strangolante andrà via o si evolverà in un adattatore per i client legacy.
  • Verificare che l'interfaccia mantenga il passo con la migrazione.
  • Verificare che l'interfaccia non diventi un singolo punto di guasto o un collo di bottiglia delle prestazioni.

Quando usare questo modello

Usare questo modello quando si migra gradualmente un'applicazione back-end in una nuova architettura.

Questo modello potrebbe non essere adatto nelle situazioni seguenti:

  • Quando non è possibile intercettare le richieste inviate al sistema back-end.
  • Per i sistemi di piccole dimensioni in cui la complessità della sostituzione su larga scala è bassa.

Passaggi successivi