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 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 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’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
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 :
- Dans un scénario lift and shift Azure associé à un réseau virtuel Azure déployé, l’organisation peut répondre directement au service back end via des adresses IP privées.
- Dans le scénario local, l’instance Gestion des API peut communiquer avec le service interne de façon privée via une passerelle VPN Azure et une connexion VPN IPSec de site à site ou via 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.
Notes
Pour des informations générales sur la connexion de Gestion des API à un réseau virtuel, consultez cet article.
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. Même si la pile existante est en grande partie monolithique, certains services HTTP basés sur SOAP sont présents en raison 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.
Disponibilité et extensibilité
- Vous pouvez effectuer un scale-out du service Gestion des API Azure en choisissant un niveau tarifaire, puis en ajoutant des unités.
- La mise à l’échelle peut également se produire automatiquement avec la mise à l’échelle automatique.
- Le déploiement dans plusieurs régions permet de bénéficier d’options de basculement et peut être effectué dans le niveau Premium.
- Envisagez d’intégrer Azure Application Insights qui expose également des métriques via Azure Monitor pour la supervision.
Optimisation des coûts
L’optimisation des coûts consiste à trouver les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’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.
Déployer ce scénario
Pour commencer, créez une instance Gestion des API Azure dans le portail.
Vous pouvez également choisir un modèle de démarrage rapide Azure Resource Manager qui correspond à votre cas d’usage spécifique.
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