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 de commerce électronique dans le secteur du voyage migre une application web héritée à l’aide de Gestion des API Azure. L’entreprise héberge la nouvelle interface utilisateur en tant qu’application PaaS (Platform as a Service) sur Azure. La nouvelle interface utilisateur dépend des API HTTP existantes et nouvelles. Ces API sont déployées avec des interfaces plus efficacement conçues qui améliorent les performances, simplifient l’intégration et permettent une extensibilité future.

Architecture

Diagramme montrant les étapes de migration d’une application web à l’aide de Gestion des API.

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

Workflow

Le flux de travail suivant correspond au diagramme précédent :

  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. La gestion des API permet de faire des appels d’Azure vers les services internes existants.

  4. La nouvelle API présente les caractéristiques suivantes :

  5. La nouvelle application web basée sur un navigateur dépend de l’instance Gestion des API pour l’API HTTP existante et la nouvelle API.

  6. La société de commerce électronique de voyage peut diriger certains utilisateurs vers la nouvelle interface utilisateur pour la préversion ou les tests tout en préservant l’ancienne interface utilisateur et les fonctionnalités existantes côte à côte.

Configurez l’instance Gestion des API pour mapper les services HTTP hérités à un nouveau contrat d’API. Dans cette configuration, la nouvelle interface utilisateur web ignore l’intégration à un ensemble de services ou d’API hérités et de nouvelles API.

À l’avenir, l’équipe de projet peut déplacer progressivement les fonctionnalités vers les nouvelles API et mettre hors service les services d’origine. L’équipe gère ces modifications dans la configuration gestion des API, laissant l’interface utilisateur frontale non affectée et évitant le travail de redéveloppement.

Components

  • Gestion des API est une plateforme de gestion et une passerelle pour les API dans tous les environnements. Dans cette architecture, elle sert de façade pour les API héritées existantes et les nouvelles API. La nouvelle application cliente utilise une seule interface cohérente, et l’équipe peut moderniser les back-ends hérités de façon incrémentielle derrière cette façade avec un impact minimal sur le développement frontal.

  • App Service est une solution PaaS clé en main pour l’hébergement web qui fournit des fonctionnalités prêtes à l’emploi, telles que la sécurité, l’équilibrage de charge, la mise à l’échelle automatique et la gestion automatisée. Dans cette architecture, App Service fournit un hébergement flexible clé en main afin que l’équipe DevOps puisse se concentrer sur la livraison des fonctionnalités.

Alternatives

  • Si l’organisation envisage de déplacer son infrastructure, y compris les machines virtuelles qui hébergent les applications héritées, entièrement vers Azure, gestion des API peut servir de façade pour tout point de terminaison HTTP adressable.

  • Si l’organisation conserve les points de terminaison existants privés et ne les expose pas publiquement, l’instance gestion des API de l’organisation peut établir un lien vers 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 Azure Application Gateway pour autoriser l’accès public pour certaines API, tandis que d’autres restent internes. Pour plus d’informations, consultez Intégrer la gestion des API dans un réseau virtuel interne à l’aide d’Application Gateway.

  • L’organisation peut décider d’héberger ses API localement. Une des raisons de cette modification peut être que l’organisation ne peut pas déplacer les dépendances de base de données en aval qui sont dans l’étendue de ce projet vers le cloud. Dans ce scénario, l’organisation peut 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. Pour utiliser des passerelles auto-hébergées, vous devez respecter les conditions préalables suivantes :

    • Vous devez déployer des passerelles auto-hébergées à l’aide d’une ressource parente dans Azure, ce qui ajoute des coûts supplémentaires.

    • Vous devez utiliser le niveau Premium de Gestion des API.

Détails du scénario

Une entreprise de e-commerce dans le secteur du voyage souhaite moderniser son ancienne pile logicielle basée sur un navigateur. La pile existante est principalement monolithique, mais certains services HTTP basés sur SOAP (Simple Object Access Protocol) existent à partir d’un projet récent. La société considère la création de flux de revenus supplémentaires pour monétiser certaines de sa propriété intellectuelle interne.

Les objectifs du projet incluent la résolution de la dette technique, les améliorations de maintenance en cours et l’accélération du développement de fonctionnalités avec moins de bogues de régression. Le projet utilise un processus itératif pour éviter les risques et effectue les étapes suivantes en parallèle :

  • L’équipe de développement modernise 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 écrit de nouvelles fonctionnalités métier et l’expose sur de nouvelles API HTTP.

  • Une équipe de développement de contrats crée une nouvelle interface utilisateur basée sur un navigateur, qui héberge Azure.

L’entreprise fournit de nouvelles fonctionnalités d’application en phases. Ces fonctionnalités remplacent progressivement les fonctionnalités existantes du client et de l’interface utilisateur du serveur basées sur un navigateur hébergées localement qui alimentent l’entreprise de commerce électronique 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 atteindre ces objectifs, ils décident de préserver leurs services HTTP SOAP existants. Elle souhaite aussi ne pas apporter trop de modifications à l’interface utilisateur en place. Ils peuvent utiliser gestion des API pour répondre à la plupart des exigences et contraintes du projet.

Cas d’usage potentiels

Ce scénario met en évidence comment moderniser les piles logicielles héritées basées sur un navigateur.

Vous pouvez utiliser ce scénario pour les tâches suivantes :

  • Découvrez comment votre entreprise peut tirer parti de l’écosystème Azure.
  • Planifiez une migration de service vers Azure.
  • Découvrez comment un changement vers Azure peut affecter les API existantes.

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour la fiabilité.

  • Activez les zones de disponibilité lorsque vous déployez votre instance Gestion des API. L’option de déploiement de gestion des API dans des zones de disponibilité n’est disponible que dans les niveaux de service Premium.

  • Utilisez des zones de disponibilité qui ont des instances de passerelle supplémentaires déployées dans différentes régions. Cette combinaison améliore la disponibilité du service si une région est hors connexion. Le déploiement multirégion n’est disponible que dans le niveau de service Premium.

  • Intégrez Application Insights, qui expose les métriques par le biais d’Azure Monitor pour la supervision. Par exemple, vous pouvez utiliser la métrique de capacité pour déterminer la charge globale sur la ressource Gestion des API et si vous avez besoin d’unités de scale-out supplémentaires. Surveillez la capacité et l'état des ressources pour améliorer la fiabilité.

  • Assurez-vous que les dépendances en aval, telles que les services back-end qui hébergent les API gérées par la gestion des API, sont également résilientes.

Optimisation des coûts

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

Gestion des API comprend huit niveaux :

  • Consommation
  • Développeur
  • Basic et Basic v2
  • Standard et Standard v2
  • Premium et Premium v2

Pour plus d’informations sur les différences de ces niveaux, consultez la tarification gestion des API.

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.

Note

Vous pouvez utiliser le niveau Développeur pour évaluer les fonctionnalités gestion des API. Ne l’utilisez pas pour la production.

Pour afficher les coûts prévus pour vos besoins de déploiement, vous pouvez modifier le nombre d’unités d’échelle et d’instances App Service dans la calculatrice de prix Azure.

Contributors

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

Auteur principal :

Autre contributeur :

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

Étapes suivantes