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 est hébergée en tant qu’application PaaS (Platform as a Service) sur Azure et dépend des API HTTP existantes et nouvelles. Ces API sont fournies avec un ensemble d’interfaces mieux conçu, ce qui permet une meilleure performance, une intégration plus facile et une extensibilité future.

Architecture

Diagramme d’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 dépend de 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 de projet peut transférer 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

  • Azure API Management extrait les API principales, ainsi que l’ajout de fonctionnalités et de découvertes croisées pour les développeurs et les applications. Dans ce scénario, la recomposition des API backend héritées existantes et l’ajout de nouvelles fonctionnalités d’API sont rendus possibles grâce à la gestion des API jouant le rôle de façade pour que la nouvelle application cliente puisse consommer 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 clé 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. 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.

Alternatives

  • 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 avait décidé de conserver les points de terminaison existants privés et de ne pas les exposer publiquement, l’instance gestion des API de l’organisation peut être lié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 Azure Application Gateway pour activer 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 à 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 c’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 principalement monolithique, certains services HTTP basés sur SOAP (Simple Object Access Protocol) existent à partir 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 utilise un processus itératif pour éviter les risques, avec certaines étapes effectuées 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 exposées sur de nouvelles API HTTP.
  • Une équipe de développement de contrats crée une nouvelle interface utilisateur basée sur un navigateur, qui est hébergée dans Azure.

Les nouvelles fonctionnalités d’application sont fournies en phases. Ces fonctionnalités remplacent progressivement les fonctionnalités existantes de l’interface utilisateur client/serveur basée sur le navigateur (hébergée localement) qui alimentent désormais 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 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. Ils peuvent utiliser Gestion des API Azure pour répondre à 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.

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

  • Envisagez de déployer votre instance Gestion des API Azure avec les zones de disponibilité activées. L'option de déploiement d'API Management dans des zones de disponibilité est uniquement disponible dans le niveau de service Premium.
  • Les zones de disponibilité peuvent être utilisées conjointement avec des instances de passerelle supplémentaires déployées dans différentes régions. Cela permet d'améliorer la disponibilité du service si une région est hors ligne. Le déploiement multirégional est également disponible uniquement dans le niveau de service Premium.
  • Envisagez d’intégrer Azure Application Insights, qui expose également les métriques par le biais d’Azure Monitor pour la surveillance. Par exemple, la métrique de capacité peut être utilisée pour déterminer la charge globale sur la ressource Gestion des API et déterminer si des unités de scale-out supplémentaires sont requises. Le suivi de la capacité et de l'état de santé de la ressource améliore la fiabilité.
  • Veillez à ce que les dépendances en aval, par exemple les services dorsaux hébergeant les API que la gestion de l'API prend en charge, soient é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.

Le service Gestion des API est disponible en quatre niveaux : Développeur, De base, Standard et Premium. Pour plus d’informations sur les différences de ces niveaux, consultez les conseils de tarification 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.

Note

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 projetés et personnaliser en fonction de 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

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 :