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.
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.
Progettazione del carico di lavoro
Un architetto deve valutare il modo in cui il modello Strangler Fig può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resilienti a malfunzionamenti e di assicurarsi che venga ripristinato in uno stato completamente funzionante dopo che si verifica un errore. | Questo approccio incrementale di questo modello può contribuire a ridurre i rischi durante una transizione dei componenti rispetto a modifiche sistemiche di grandi dimensioni. - Test RE:08 |
| L'ottimizzazione dei costi è incentrata sul mantenimento e sul miglioramento del ritorno del carico di lavoro sugli investimenti. | L'obiettivo di questo approccio è ottimizzare l'uso degli investimenti esistenti nel sistema attualmente in esecuzione durante la modernizzazione incrementale, in quanto consente di eseguire sostituzioni con roi elevato prima delle sostituzioni a basso roi. - Costi dei componenti CO:07 - Costi dell'ambiente CO:08 |
| L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. | Questo modello offre un approccio di miglioramento continuo, in cui la sostituzione incrementale con piccole modifiche nel tempo è preferibile anziché modifiche sistemiche di grandi dimensioni più rischiose da implementare. - Sviluppo del carico di lavoro OE:06 - Procedure di distribuzione di OE:11 Cassaforte |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Passaggi successivi
- Post di blog di Martin Fowler su StranglerFigApplication