Faites migrer un système hérité de façon incrémentielle en remplaçant progressivement des parties spécifiques des fonctionnalités par de nouveaux services et applications. Lorsque les fonctionnalités d’un système hérité sont remplacées, le nouveau système finit par remplacer toutes les fonctionnalités de l’ancien système. Il étrangle alors l’ancien système et vous permet ainsi de le désactiver.
Contexte et problème
À mesure que les systèmes vieillissent, les outils de développement, la technologie d’hébergement et même les architectures système sur lesquels reposent ces systèmes peuvent devenir de plus en plus obsolètes. L’ajout progressif de nouvelles fonctions et fonctionnalités peut considérablement accroître la complexité de ces applications et compliquer ainsi la mise à jour ou l’enrichissement de ces dernières.
Le remplacement complet d’un système complexe peut constituer un défi de taille. Vous serez généralement contraint d’effectuer une migration progressive vers un nouveau système, tout en conservant l’ancien système pour gérer les fonctionnalités qui n’ont pas encore fait l’objet d’une migration. Toutefois, l’exécution de deux versions distinctes d’une application signifie que les clients doivent connaître l’emplacement des différentes fonctionnalités. Chaque fois que vous faites migrer une fonctionnalité ou un service, vous devez donc mettre à jour les clients pour qu’ils pointent vers le nouvel emplacement.
Solution
Remplacez progressivement des parties spécifiques des fonctionnalités par de nouveaux services et applications. Créez une façade qui intercepte les requêtes destinées au système hérité principal. La façade route ces requêtes soit vers l’application héritée, soit vers les nouveaux services. Les fonctionnalités existantes peuvent faire l’objet d’une migration progressive vers le nouveau système, et les clients peuvent continuer à utiliser la même interface sans savoir qu’une migration a été effectuée.
Ce modèle contribue à minimiser les risques liés à la migration et à étaler l’effort de développement dans le temps. Étant donné que la façade route les utilisateurs en toute sécurité vers l’application adéquate, vous pouvez ajouter des fonctionnalités au nouveau système à votre rythme, tout en ayant l’assurance que l’application héritée continue à fonctionner. Avec le temps, à mesure que les fonctionnalités font l’objet d’une migration vers le nouveau système, le système hérité finit par être « étranglé » et par devenir inutile. Une fois ce processus terminé, le système hérité peut alors être mis hors service sans problème.
Problèmes et considérations
- Déterminez comment gérer les services et les magasins de données potentiellement utilisés à la fois par un nouveau système et par un système hérité. Assurez-vous que les deux systèmes peuvent accéder à ces ressources côte à côte.
- Structurez les nouveaux services et applications de façon à faciliter leur interception et leur remplacement dans les futures migrations de type Figuier étrangleur.
- À un moment donné, une fois la migration terminée, la façade de figuier étrangleur finit soit par disparaître, soit par évoluer sous la forme d’un adaptateur pour les clients hérités.
- Assurez-vous que la façade suive le rythme de la migration.
- Assurez-vous que la façade ne devienne pas un point de défaillance unique ou un goulot d’étranglement.
Quand utiliser ce modèle
Utilisez ce modèle lorsque vous faites migrer progressivement une application principale vers une nouvelle architecture.
Ce modèle peut ne pas convenir :
- lorsque les requêtes adressées au système principal ne peuvent pas être interceptées ;
- pour les systèmes plus modestes dont le remplacement global présente peu de difficultés.
Conception de la charge de travail
Un architecte devrait évaluer comment le modèle Strangler Fig (Figuier Étrangleur) peut être utilisé dans la conception de sa charge de travail pour répondre aux objectifs et principes couverts par les piliers de Azure Well-Architected Framework. Par exemple :
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| Les décisions relatives à la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à s’assurer qu’elle retrouve un état de fonctionnement optimal après une défaillance. | L’approche incrémentale de ce modèle peut contribuer à limiter les risques lors d’une transition de composants par rapport à de grands changements systémiques. - RE:08 Test |
| L’optimisation des coûts est axée sur le maintien et l’amélioration du retour sur investissement de votre charge de travail. | L’objectif de cette approche est de maximiser l’utilisation des investissements existants dans le système actuellement en fonctionnement tout en modernisant de manière incrémentale, ce qui vous permet d’effectuer des remplacements à haut ROI avant ceux à faible ROI. - CO :07 Coûts composants - Coûts de l’environnement |
| L’excellence opérationnelle permet de fournir une qualité de charge de travail grâce à des processus standardisés et à la cohésion d’équipe. | Ce modèle fournit une approche d’amélioration continue, dans laquelle le remplacement incrémental avec de petits changements au fil du temps est préféré plutôt que de grands changements systémiques qui sont plus risqués à mettre en œuvre. - OE:06 Développement de la charge de travail - OE :11 Pratiques de déploiement sécurisé |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Étapes suivantes
- Billet de blog de Martin Fowler sur StranglerFigApplication