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
Téléchargez un fichier Visio de cette architecture.
Workflow
- L’application web locale existante continue d’utiliser directement les services web locaux existants.
- 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.
- Les appels entrants sont effectués à partir d’Azure vers les services internes existants:
- L’équipe de sécurité autorise le trafic en provenance de l’instance Gestion des API à traverser le pare-feu de l’entreprise vers les services locaux existants à l’aide de protocoles de transport sécurisés (HTTPS ou SSL).
- L’équipe des opérations autorise les appels entrants vers les services uniquement si ceux-ci proviennent de l’instance Gestion des API Azure. Elle remplit cette condition en ajoutant l’adresse IP de l’instance Gestion des API à la liste d’autorisation dans le périmètre du réseau de l’entreprise.
- Un nouveau module est configuré dans le pipeline de requête local pour les services HTTP (pour agir uniquement sur les connexions qui proviennent de l’extérieur). Le pipeline valide un certificat fourni par Gestion des API.
- La nouvelle API :
- Est exposée uniquement via l’instance Gestion des API, qui fournit la façade de l’API. La nouvelle API n’est pas accessible directement.
- Est développée et publiée en tant qu’application API web PaaS Azure.
- Est configurée (via les paramètres de la fonctionnalité Web Apps d’Azure App Service) pour accepter uniquement l’adresse IP virtuelle (VIP) Gestion des API.
- Est hébergée dans Web Apps avec le transport sécurisé (HTTPS ou SSL) activé.
- L'autorisation est activée, fournie par Azure App Service via Microsoft Entra ID et Open Authorization (OAuth) 2.
- 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.
- 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 :
- Lorsque API Management est lié à un réseau virtuel Azure, l'organisation pourrait s'adresser directement au service back-end par le biais d'adresses IP privées.
- Dans le scénario local, l'instance de gestion de l'API pourrait rejoindre le service interne de manière privée via une passerelle VPN Azure et une connexion VPN IPSec (Internet Protocol Security) de site à site ou Azure ExpressRoute. Ce scénario deviendrait alors un hybride d’Azure et d’un environnement local.
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é.
- Envisagez de déployer votre instance Azure API Management avec des 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 des métriques via Azure Monitor pour la supervision. Par exemple, la mesure de capacité peut être utilisée pour déterminer la charge globale sur la ressource API Management et si des unités scale-out supplémentaires sont nécessaires. 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 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 :
- Ben Gimblett | Ingénieur client senior
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
Documentation du produit :
Modules Learn :
- Explorer Azure App Service
- Déployer un site web sur Azure avec Azure App Service
- Protéger vos API sur Gestion des API Azure