Le motif de figue étrangleur - AWS Directives prescriptives

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Le motif de figue étrangleur

Le modèle de figue étrangleur a été introduit par Martin Fowler afin de gérer les risques lors de la modernisation ou de la réécriture de grands systèmes monolithiques. Le modèle est une analogie avec un type de plante qui commence sa vie sous la forme d'une vigne poussant à côté d'un arbre plus âgé et bien établi. Au fur et à mesure que la vigne grandit, elle se répand pour consommer complètement et finalement remplacer l'arbre hôte, laissant un nouveau figuier plus étrange à sa place. Dans le contexte de la modernisation des services Web ASP.NET, ce modèle remplace progressivement les fonctionnalités du système en établissant des proxys lorsque d'autres systèmes dépendent des services Web. Dans un premier temps, vous pouvez considérer que ces proxys ont un comportement de transmission, car leur implémentation est assurée par le service d'application monolithique existant. Dans l'analogue naturel, c'est à ce moment que le figuier étrangleur envoie initialement une vigne sur le tronc de l'arbre hôte. Ensuite, un nouveau service, découplé du monolithe, est créé et l'implémentation du proxy est reportée à ce nouveau service. Dans l'analogue naturel, c'est lorsque le figuier étrangleur enroule autour de l'une des branches de l'arbre et la dépasse. Ce modèle de proxy puis de remplacement de l'implémentation du proxy par un nouveau service se poursuit jusqu'à ce que toutes les fonctions de l'ancien système soient migrées vers de nouveaux services. À ce stade, le figuier étrangleur consomme complètement l'arbre et l'ancien système peut être mis hors service.

Suivez ces bonnes pratiques lorsque vous utilisez le modèle Strangler Fig, afin de pouvoir dimensionner et déployer votre application de manière indépendante de manière plus fluide :

  • Choisissez un composant qui offre une bonne couverture des tests et qui présente moins de dettes techniques. Commencer par cette composante peut donner beaucoup de confiance aux équipes pendant le processus de modernisation.

  • Sélectionnez les composants qui ont des exigences d'évolutivité et commencez par l'un de ces composants.

  • Sélectionnez un composant qui change fréquemment les exigences de l'entreprise et qui est fréquemment déployé.

  • Pour implémenter ce modèle à grande échelleAWS, déployez les services ASMX refactorisés dans un conteneur Windows exécuté dans Amazon Elastic Container Service (Amazon ECS) et publiez votre API REST modernisée à l'aide d'Amazon API Gateway.