Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Ce modèle migre de façon incrémentielle un système hérité en remplaçant progressivement des éléments de fonctionnalité spécifiques par de nouvelles applications et services. Lorsque vous remplacez les fonctionnalités du système hérité, le nouveau système comprend finalement toutes les fonctionnalités de l’ancien système. Cette approche supprime l’ancien système pour pouvoir le désactiver.
Contexte et problème
À mesure que les systèmes vieillissent, les outils de développement, la technologie d’hébergement et les architectures système qu’ils reposent peuvent devenir obsolètes. À mesure que de nouvelles fonctionnalités sont ajoutées, ces applications deviennent plus complexes, ce qui peut les rendre plus difficiles à gérer ou à étendre.
Le remplacement d’un système complexe est une entreprise énorme. Au lieu de cela, de nombreuses équipes préfèrent migrer vers un nouveau système progressivement et conserver l’ancien système pour gérer les fonctionnalités nonmigrates. Toutefois, l’exécution de deux versions distinctes d’une application force les clients à suivre quelle version possède des fonctionnalités individuelles. Chaque fois que les équipes migrent une fonctionnalité ou un service, elles doivent diriger les clients vers le nouvel emplacement. Pour surmonter ces défis, vous pouvez adopter une approche qui prend en charge la migration incrémentielle et réduit les interruptions aux clients.
Solution
Utilisez un processus incrémentiel pour remplacer des éléments de fonctionnalité spécifiques par de nouvelles applications et services. Les clients peuvent continuer à utiliser la même interface, sans savoir que cette migration est en cours.
Le modèle Strangler Fig fournit une approche contrôlée et progressive de la modernisation. Elle permet à l’application existante de continuer à fonctionner pendant l’effort de modernisation. Une façade (proxy) intercepte les requêtes destinées au système hérité principal. La façade achemine ces requêtes vers l’application héritée ou vers les nouveaux services.
Ce modèle réduit les risques liés à la migration en permettant à vos équipes de progresser à un rythme adapté à la complexité du projet. Lorsque vous migrez des fonctionnalités vers le nouveau système, le système hérité devient obsolète et vous désaffectez le système hérité.
Le modèle Fig Strangler commence par introduire une façade (proxy) entre l’application cliente, le système hérité et le nouveau système. La façade agit en tant qu’intermédiaire. Elle permet à l’application cliente d’interagir avec le système hérité et le nouveau système. Initialement, la façade achemine la plupart des requêtes vers le système ancien.
À mesure que la migration progresse, la façade déplace de façon incrémentielle les demandes du système hérité vers le nouveau système. Avec chaque itération, vous implémentez davantage de fonctionnalités dans le nouveau système.
Cette approche incrémentielle réduit progressivement les responsabilités du système hérité et étend l’étendue du nouveau système. Le processus est itératif. Elle permet à l’équipe de traiter les complexités et les dépendances en phases gérables. Ces étapes aident le système à rester stable et fonctionnel.
Une fois que vous avez migré toutes les fonctionnalités et qu’il n’existe aucune dépendance sur le système hérité, vous pouvez désactiver le système hérité. La façade achemine toutes les demandes exclusivement vers le nouveau système.
Vous supprimez la façade et reconfigurez l’application cliente pour communiquer directement avec le nouveau système. Cette étape marque l’achèvement de la migration.
Problèmes et considérations
Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :
Envisagez de gérer les services et les magasins de données que le nouveau système et le système hérité peuvent utiliser. Assurez-vous que les deux systèmes peuvent accéder à ces ressources en même temps.
Structurez de nouvelles applications et services afin que vous puissiez facilement les intercepter et les remplacer dans les futures migrations de figuier étrangleur. Par exemple, essayez d’avoir des démarcations claires entre les parties de votre solution afin que vous puissiez migrer chaque partie individuellement.
Une fois la migration terminée, vous supprimez généralement la façade de figuier étrangleur. Vous pouvez également conserver la façade en tant qu'adaptateur pour que les clients existants puissent l'utiliser pendant que vous mettez à jour le système principal pour les clients plus récents.
Assurez-vous que la façade suit la migration.
Assurez-vous que la façade ne devient pas un point de défaillance unique ou un goulot d’étranglement des performances.
Quand utiliser ce modèle
Utilisez ce modèle dans les situations suivantes :
Vous migrez progressivement une application principale vers une nouvelle architecture, en particulier lors du remplacement de systèmes volumineux, de composants clés ou de fonctionnalités complexes.
Le système d’origine peut continuer à exister pendant une période prolongée pendant l’effort de migration.
Ce modèle peut ne pas convenir lorsque :
Les demandes adressées au système principal ne peuvent pas être interceptées.
Vous migrez un petit système, et remplacer l'ensemble du système est simple.
Vous devez rapidement mettre hors service la solution d’origine.
Conception de la charge de travail
Évaluez comment utiliser le modèle Strangler Fig dans la conception d’une charge de travail afin de satisfaire aux objectifs et aux principes des piliers Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.
| 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émentielle de ce modèle peut aider à atténuer les risques lors d’une transition des composants par rapport à l’élaboration de modifications systémiques importantes en même temps. - Test RE:08 |
| L’optimisation des coûts se concentre sur le maintien et l’amélioration du retour sur investissement (ROI) de votre charge de travail. | L’objectif de cette approche est de maximiser l’utilisation des investissements existants dans le système en cours d’exécution tout en modernisant de façon incrémentielle. Il vous permet d’effectuer des remplacements de retour sur investissement élevés avant les remplacements à faible retour sur investissement. - CO :07 Coûts composants - CO:08 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. Les remplacements incrémentiels qui apportent de petites modifications au fil du temps sont préférables aux changements systémiques importants qui sont plus risqués à implémenter. - OE:06 Chaîne d'approvisionnement pour le développement de la charge de travail - OE :11 Pratiques de déploiement sécurisé |
Considérez tous les compromis contre les objectifs des autres piliers que ce modèle pourrait introduire.
Exemple :
Les systèmes hérités dépendent généralement d’une base de données centralisée. Au fil du temps, une base de données centralisée peut devenir difficile à gérer et à évoluer en raison de ses nombreuses dépendances. Pour relever ces défis, différents modèles de base de données peuvent faciliter la transition de ces systèmes hérités. Le modèle Fig Strangler est l’un de ces modèles. Appliquez le modèle Fig Strangler en tant qu’approche progressive pour passer progressivement d’un système hérité à un nouveau système et réduire les perturbations.
Vous introduisez un nouveau système et le nouveau système commence à gérer certaines demandes de l’application cliente. Toutefois, le nouveau système dépend toujours de la base de données héritée pour toutes les opérations de lecture et d’écriture. Le système hérité reste opérationnel, ce qui facilite une transition fluide sans changements structurels immédiats.
Dans la phase suivante, vous allez introduire une nouvelle base de données. Vous migrez l’historique de chargement des données vers la nouvelle base de données à l’aide d’un processus d’extraction, de transformation et de chargement (ETL). Le processus ETL synchronise la nouvelle base de données avec la base de données héritée. Pendant cette phase, le nouveau système effectue des écritures en mode furtif. Le nouveau système met à jour les deux bases de données en parallèle. Le nouveau système continue de lire à partir de la base de données héritée pour valider la cohérence.
Enfin, la nouvelle base de données devient le système d’enregistrement. La nouvelle base de données prend en charge toutes les opérations de lecture et d’écriture. Vous pouvez commencer à déprécier la base de données héritée et le système hérité. Après avoir validé la nouvelle base de données, vous pouvez mettre hors service la base de données héritée. Cette mise hors service termine le processus de migration avec une interruption minimale.
Étape suivante
Lisez le billet de blog de Martin Fowler sur l’application Strangler Fig pattern.