Modèle Figuier étrangleur

Migrez 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.

Il est difficile de remplacer un système complexe entier. Au lieu de cela, vous pouvez migrer vers un nouveau système progressivement et utiliser l’ancien système pour les fonctionnalités non migrées. Toutefois, si vous exécutez des versions parallèles d’une application, les clients doivent suivre la version qui contient chaque fonctionnalité. Lorsque vous migrez une fonctionnalité ou un service, vous devez diriger les clients vers le nouvel emplacement. Pour relever ces défis, adoptez une approche qui prend en charge la migration incrémentielle et réduit les interruptions aux clients.

Solution

Après avoir identifié de nouvelles limites de service, utilisez un processus incrémentiel pour remplacer des fonctionnalités spécifiques par de nouvelles applications et services. Les clients continuent d’utiliser la même interface et ne savent pas qu’une migration est en cours.

Téléchargez un fichier Visio de cette architecture.

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é.

1. 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.

2. À 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.

3. 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.

4. 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 comme adaptateur à l’usage des anciens clients pendant que vous mettez à jour le système central pour les nouveaux clients.

  Conceptualisez cette architecture en tant qu’architecture transitionnelle et équilibrez les avantages de l’atténuation des risques de cette architecture par rapport à ses coûts temporaires d’infrastructure.

• 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.

• Planifiez les dépendances entre systèmes. Pendant la migration, les deux systèmes doivent coexister et communiquer. Par exemple, le nouveau système peut avoir besoin d’appeler des fonctionnalités nonmigrates à partir du système hérité, et les composants hérités non migrés peuvent avoir besoin d’appeler des fonctionnalités migrées à partir du nouveau système. Pour gérer ces appels, utilisez le modèle de couche anti-corruption. Une couche anti-corruption agit en tant qu’adaptateur qui traduit les requêtes entre les deux systèmes. Cette couche protège la conception du nouveau système contre la sémantique héritée afin que le système hérité puisse atteindre de nouveaux services sans modifications significatives du code. Sans cet adaptateur, les dépendances entre systèmes peuvent interrompre les composants ou forcer le nouveau système à adopter des conventions héritées.

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 ne pouvez pas accéder au code source du système hérité. Pour désactiver les fonctionnalités migrées et rediriger les appels internes, vous devez être en mesure de modifier le code source du système hérité.

• 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.

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 monolithique centralisée qui sert plusieurs domaines. Au fil du temps, cette base de données partagée devient difficile à gérer et à améliorer en raison de ses dépendances inter-domaines. Pour relever ce défi, le modèle Fig Strangler extrait de manière incrémentielle des tables, des procédures stockées et des données associées de la base de données monolithique dans des bases de données de domaine isolées. Chaque base de données ne contient qu’un seul domaine. Répétez le processus d’extraction jusqu’à ce que la base de données monolithique soit entièrement décomposée.

1. Introduisez un nouveau service système, qui commence à gérer les demandes de son domaine. Le nouveau service système lit toujours depuis la base de données monolithique et y écrit pour les tables de son domaine. Le système hérité continue de servir tous les autres domaines.

2. Introduisez une base de données de domaine isolée pour le nouveau système. Migrez les tables de domaine pertinentes et leurs données historiques vers la nouvelle base de données à l’aide d’un processus d’extraction, de transformation et de chargement (ETL). Un processus de capture de données modifiées (CDC) synchronise les données de domaine de la base de données monolithique vers la nouvelle base de données de domaine. Pendant cette phase, le système hérité continue de lire et d’écrire dans la base de données monolithique, et le nouveau système écrit dans la nouvelle base de données de domaine. Validez la cohérence entre les deux bases de données avant le basculement.

3. Après validation, la nouvelle base de données de domaine est le système d’enregistrement de ce domaine. Le nouveau système effectue toutes les opérations de lecture et d’écriture sur la base de données de domaine. Supprimez les tables de domaine, les procédures stockées et les dépendances correspondantes de la base de données monolithique. Répétez ce processus pour chaque domaine jusqu’à ce que la base de données monolithique soit entièrement décomposée.

   Vous pouvez revenir à la base de données monolithique pendant la phase 2 et au début de la phase 3, lorsque les tables de domaine et les processus de synchronisation existent toujours dans la base de données monolithique. Pour revenir à la base de données monolithique après avoir supprimé les tables de domaine, les procédures stockées et les processus de synchronisation de la base de données monolithique, vous devez restaurer ces objets et relire les modifications de données. Toutefois, ce processus augmente considérablement les efforts et les risques. Traitez la suppression d’objets hérités comme une étape finale délibérée pour chaque domaine. Supprimez les objets hérités uniquement une fois le nouveau système validé.

Contributors

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

• Adnan Khan | Architecte senior des solutions cloud
• Ovais Mehboob Ahmed Khan | Architecte de solution cloud senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étape suivante

• Lire le billet de blog de Martin Fowler consacré à l’application du modèle Strangler Fig

Ressources associées

• Modèle Messaging Bridge
• Planez votre migration de charge de travail d’Amazon Web Services vers Azure