Modifier

Partager via


Effectuer la migration d’une application web en utilisant Gestion des API Azure

Gestion des API Azure
Azure Monitor
Azure App Service

Dans ce scénario, une entreprise d’e-commerce du tourisme migre une application web héritée à l’aide de Gestion des API Azure. La nouvelle interface utilisateur va être hébergée en tant qu’application PaaS sur Azure et reposer sur les API HTTP nouvelles et existantes. Ces API sont fournies avec un ensemble d’interfaces mieux conçues offrant de meilleures performances, une intégration plus simple et une extensibilité future.

Architecture

Diagramme de l'architecture

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

Workflow

  1. L’application web locale existante continue d’utiliser directement les services web locaux existants.
  2. Les appels en provenance de l’application web existante vers les services HTTP existants restent inchangés. Ces appels sont internes au réseau de l’entreprise.
  3. Les appels entrants sont effectués à partir d’Azure vers les services internes existants:
  4. La nouvelle API :
  5. La nouvelle application web basée sur un navigateur repose sur l’instance Gestion des API Azure pour l’API HTTP existante et la nouvelle API.
  6. L'entreprise de commerce électronique de voyages peut désormais diriger certains utilisateurs vers la nouvelle interface utilisateur (à des fins de prévisualisation ou de test) tout en préservant l'ancienne interface utilisateur et les fonctionnalités existantes côte à côte.

L’instance Gestion des API est configurée pour mapper les services HTTP hérités à un nouveau contrat d’API. Dans cette configuration, la nouvelle interface utilisateur web n’a pas connaissance de l’intégration à un ensemble de services/d’API hérités et d’API nouvelles.

À l’avenir, l’équipe projet va progressivement étendre les fonctionnalités aux nouvelles API et supprimer les services d’origine. L’équipe gère ces modifications dans la configuration de Gestion des API, laissant l’interface utilisateur front-end non affectée et évitant le travail de redéveloppement.

Composants

  • Azure API Management fait abstraction des API dorsales et ajoute des fonctionnalités transversales et de découverte pour les développeurs et les applications. Dans ce scénario, la recomposition des API existantes et l'ajout de nouvelles fonctionnalités sont rendus possibles par l'utilisation de la gestion des API en tant que façade pour que la nouvelle application client puisse consommer les API de manière cohérente et en utilisant des normes modernes. Étant donné que la gestion des API sert de façade aux API existantes et nouvelles, les développeurs peuvent moderniser les backends existants derrière la façade de gestion des API de manière itérative et avec un impact minimal, voire nul, sur le développement du nouveau front-end.
  • Azure App Service est un service PaaS (Platform as a Service) clé en main pour l'hébergement Web qui offre des fonctionnalités prêtes à l'emploi telles que la sécurité, l'équilibrage de la charge, la mise à l'échelle automatique et la gestion automatisée. Azure App Service est un excellent choix pour les nouvelles API développées pour cette solution, car il fournit un hébergement flexible clé en main, permettant à l'équipe DevOps de se concentrer sur la fourniture de fonctionnalités.

Autres solutions

  • Si l’organisation prévoie de migrer l’ensemble de son infrastructure sur Azure, y compris les machines virtuelles hébergeant les applications héritées, le service Gestion des API Azure reste une option intéressante. En effet, il peut servir de façade pour tous les points de terminaison HTTP adressables.

  • Si l’organisation a décidé de conserver les points de terminaison existants privés et de ne pas les exposer publiquement, son instance Gestion des API peut être associée à un réseau virtuel Azure :

  • L’organisation peut conserver l’instance Gestion des API privée en la déployant en mode interne. L’organisation peut ensuite utiliser le déploiement avec une instance Azure Application Gateway pour autoriser l’accès public à certaines API tout en conservant d’autres API en interne. Pour plus d’informations, consultez Intégrer le service Gestion des API dans un réseau virtuel interne avec Application Gateway.

  • L’organisation peut décider d’héberger ses API localement. Ce changement peut être dû au fait que l’organisation n’a pas pu déplacer vers le cloud les dépendances de base de données en aval qui sont dans l’étendue de ce projet. Si tel est le cas, l’organisation peut toujours tirer parti de Gestion des API localement à l’aide d’une passerelle auto-hébergée.

    La passerelle auto-hébergée est un déploiement conteneurisé de la passerelle Gestion des API qui se connecte à Azure sur un socket sortant. La première condition préalable est que les passerelles auto-hébergées ne peuvent pas être déployées sans ressource parente dans Azure, ce qui entraîne des frais supplémentaires. La deuxième est que le niveau Premium de Gestion des API est obligatoire.

Détails du scénario

Une entreprise d’e-commerce dans le secteur du tourisme modernise sa pile logicielle héritée basée sur un navigateur. Bien que la pile existante soit essentiellement monolithique, certains services HTTP basés sur le protocole SOAP (Simple Object Access Protocol) sont issus d'un projet récent. L’entreprise envisage de créer des sources de revenus supplémentaires pour monétiser certaines données de propriété intellectuelle interne qu’elle a développées.

Les objectifs du projet incluent le traitement de la dette technique, l’amélioration de la maintenance continue et l’accélération du développement des fonctionnalités avec moins de bogues de régression. Le projet va utiliser un processus itératif afin d’éviter les risques, avec quelques étapes effectuées en parallèle :

  • L’équipe de développement va moderniser le back end de l’application, qui se compose de bases de données relationnelles hébergées sur des machines virtuelles.
  • L’équipe de développement interne va écrire de nouvelles fonctionnalités métier, exposées sur les nouvelles API HTTP.
  • Une équipe de développement externe va créer une nouvelle interface utilisateur basée sur un navigateur et hébergée sur Azure.

Les nouvelles fonctionnalités de l’application seront proposées au fur et à mesure. Ces fonctionnalités vont progressivement remplacer la fonctionnalité existante d’interface utilisateur du serveur/client basée sur un navigateur (hébergée en local) qui joue désormais un rôle essentiel dans l’activité d’e-commerce de l’entreprise.

Les membres de l’équipe de gestion ne veulent pas se moderniser inutilement. En outre, elle veut garder le contrôle sur l’étendue et les coûts. Pour ce faire, ils ont décidé de conserver ses services HTTP SOAP existants. Elle souhaite aussi ne pas apporter trop de modifications à l’interface utilisateur en place. Il peuvent utiliser le service Gestion des API Azure pour traiter la plupart des exigences et contraintes du projet.

Cas d’usage potentiels

Ce scénario met en évidence la modernisation des piles logicielles héritées basées sur un navigateur.

Vous pouvez utiliser ce scénario pour :

  • Découvrez comment votre entreprise peut tirer parti de l’écosystème Azure.
  • Planifiez la migration des services vers Azure.
  • Découvrez comment une transition vers Azure affecterait les API existantes.

Considérations

Ces considérations mettent en œuvre les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs dont l’application améliore la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Le service Gestion des API est disponible en quatre niveaux : Développeur, De base, Standard et Premium. Pour obtenir des conseils détaillés sur les différences entre ces niveaux, consultez les instructions de tarification du service Gestion des API Azure.

Vous pouvez mettre à l’échelle Gestion des API en ajoutant et en supprimant des unités. La capacité de chaque unité dépend de son niveau.

Notes

Vous pouvez utiliser le niveau Développeur pour l’évaluation des fonctionnalités du service Gestion des API. Ne l’utilisez pas pour la production.

Pour afficher les coûts prévus et effectuer une personnalisation en fonction des besoins de votre déploiement, vous pouvez modifier le nombre d’unités d’échelle et d’instances App Service dans la calculatrice de prix Azure.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

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

Étapes suivantes

Documentation du produit :

Modules Learn :