Choisir une option de calcul Azure pour les microservices

Cet article vous aide à choisir une plateforme de calcul Azure pour une charge de travail basée sur une architecture de microservices. Une architecture de microservices se compose de petits services déployables indépendamment qui communiquent sur le réseau. Votre plateforme de calcul doit prendre en charge une mise à l’échelle indépendante, un déploiement indépendant et une communication interservice fiable entre de nombreux services.

Pour connaître les facteurs de décision qui s’appliquent à n’importe quelle charge de travail, comme les compétences d’équipe, la mise en réseau et la portabilité, consultez Choisir un service de calcul Azure. Cet article se concentre sur les facteurs qui importent spécifiquement pour les microservices.

Plateformes de calcul Azure pour les microservices

Les plateformes Azure suivantes prennent en charge les charges de travail de microservices. Ils diffèrent dans la quantité d’orchestration, de communication interservice et de comportement de mise à l’échelle qu’ils fournissent.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) est un service Kubernetes managé qui fournit un accès direct aux API Kubernetes et au plan de contrôle. AKS fournit la gestion des nœuds, la mise à jour corrective et les mises à niveau automatiques facultatives. Vous configurez les stratégies de cluster, de mise en réseau et de mise à l’échelle.

Pour les microservices, AKS prend en charge les maillages de service comme Istio pour la gestion du trafic et la sécurité mutuelle des couches de transport (mTLS), la mise à l’échelle par déploiement via hpA (Horizontal Pod Autoscaler) et la mise à l’échelle automatique pilotée par les événements Kubernetes (KEDA) et les stratégies de déploiement natives Kubernetes, telles que les mises à jour propagées et les versions canary.

AKS Automatic est un mode AKS qui préconfigure la gestion des nœuds, la mise à l’échelle, la sécurité et l’observabilité en fonction des recommandations bien conçues AKS, afin que les équipes obtiennent un cluster prêt pour la production sans configuration par capacité.

Azure Container Apps (Applications de Conteneur Azure)

Azure Container Apps est un service managé basé sur Kubernetes qui extrait la gestion des clusters.

Container Apps fournit des fonctionnalités intégrées pour les microservices, notamment la découverte de services, l’intégration de Dapr pour les appels de service à service avec mTLS, la messagerie de l’abonné aux éditeurs et la gestion de l’état. La mise à l’échelle automatique basée sur KEDA permet la mise à l’échelle pilotée par les événements, notamment la mise à l’échelle à zéro. Container Apps prend également en charge le fractionnement du trafic entre les révisions pour les déploiements canary et tâches à la demande, planifiées ou pilotées par des événements.

Container Apps n’expose pas les API Kubernetes. Si votre configuration d’outils de déploiement ou de maillage de service dépend des primitives Kubernetes, utilisez AKS à la place.

Azure Functions

Azure Functions est un service de calcul serverless piloté par les événements adapté aux microservices qui répondent aux déclencheurs tels que les requêtes HTTP, les messages de file d’attente ou les minuteurs. Functions met à l’échelle chaque application de fonction indépendamment et peut être mise à l’échelle à zéro. Pour les microservices, déployez chaque service en tant qu’application de fonction.

Functions ne fournit pas de découverte de service au niveau de la plateforme ni une communication interservice. Implémentez ces fonctionnalités dans le code d’application ou via des services externes comme Gestion des API Azure.

Functions prend en charge plusieurs langages de programmation. Vous pouvez également exécuter le modèle de programmation Functions sur Container Apps, qui combine les déclencheurs et liaisons Functions avec les fonctionnalités de mise en réseau et de mise à l’échelle de Container Apps.

Azure App Service

Azure App Service convient aux microservices HTTP tels que les API web. App Service prend en charge le déploiement en tant que code ou en tant que conteneur unique. Il offre une mise à l’échelle automatique intégrée, des slots de déploiement pour les déploiements bleu-vert et un routage du trafic en fonction des pourcentages, ainsi qu’une intégration avec des pipelines d’intégration et de livraison continues (CI/CD). App Service ne fournit pas de découverte de service. Il convient donc aux microservices qui communiquent par le biais de la messagerie externe ou d’une passerelle d’API plutôt que de s’appuyer sur la communication interservice au niveau de la plateforme.

Azure Red Hat OpenShift

Azure Red Hat OpenShift fournit des clusters OpenShift complètement managés et étend Kubernetes avec une expérience de développeur avisée. Red Hat et Microsoft concevoir, exploiter et prendre en charge conjointement le service. Utilisez Azure Red Hat OpenShift lorsque votre organisation standardise sur OpenShift.

Comparer les plateformes pour les microservices

Le tableau suivant compare la façon dont chaque plateforme prend en charge les fonctionnalités qui concernent une architecture de microservices. Pour une comparaison plus détaillée des plateformes d’hébergement de conteneurs Azure et de leurs fonctionnalités, consultez Choisir un service de conteneur Azure.

Le niveau de l’application dans ce tableau signifie que la plateforme ne fournit pas la fonctionnalité en tant que fonctionnalité intégrée. Vous l’implémentez dans le code d’application par le biais d’un kit SDK ou d’un service externe, qui introduit une dépendance à ce service.

Choisir votre plateforme

• Commencez par Container Apps lorsque vous souhaitez des primitives de microservices intégrées, telles que la découverte de services, Dapr et la mise à l’échelle par application qui incluent une mise à l’échelle à zéro, sans gestion de cluster.

• Choisissez AKS lorsque vous avez besoin d’un accès direct à l’API Kubernetes, d’une configuration de maillage de service personnalisé ou d’un contrôle précis sur l’infrastructure de cluster, comme les pools de nœuds, les stratégies de mise en réseau ou les contraintes de planification.

• Utilisez Functions pour les microservices pilotés par les événements qui ont des modèles de trafic sporadiques ou soudains qui bénéficient d’une facturation à l’échelle zéro et d’une exécution basée sur un déclencheur.

• Utilisez App Service pour des services HTTP simples qui n’ont pas besoin de fonctionnalités de découverte de service au niveau de la plateforme ou de communication interservice.

Votre charge de travail de microservices n’a pas besoin d’être exécutée sur une plateforme unique. Par exemple, vous pouvez exécuter des services principaux sur AKS ou Container Apps pendant que Functions gère les charges de travail pilotées par les événements. Évaluez chaque service de votre composition par rapport à son propre modèle de trafic, à ses exigences de mise à l’échelle et à ses besoins de communication. Choisissez la plateforme qui correspond à ce service au lieu de forcer le service à s’adapter à la plateforme.

Facteurs de décision clés

Le tableau de comparaison indique ce que chaque plateforme prend en charge. Les sections suivantes vous aident à évaluer ces fonctionnalités en fonction des problèmes de microservices qui concernent le plus votre charge de travail.

Communication entre les services

Les microservices dépendent d’une communication fiable de service à service avec des fonctionnalités telles que la découverte de service, les réessais et mTLS.

Si votre architecture dépend des appels de service à service synchrones entre de nombreux services, priorisez une plateforme qui a des primitives de communication intégrées. Container Apps fournit ces primitives via Dapr sans infrastructure supplémentaire. AKS les fournit via des maillages de services comme Istio, qui vous permettent de contrôler les stratégies de trafic, les tentatives de réessai et les interruptions de circuit au niveau du maillage. Vous gérez le cycle de vie, la configuration et les mises à niveau du maillage.

Si vos services communiquent principalement par le biais de messages asynchrones tels que des files d’attente ou des flux d’événements, les fonctionnalités de communication intégrées de la plateforme sont moins importantes, car vous devez interagir avec ces services via un KIT de développement logiciel (SDK) ou une abstraction. Utilisez le modèle de Request-Reply asynchrone pour les opérations de longue durée, car les délais d’expiration de la plateforme peuvent devenir un problème. Par exemple, Functions et App Service appliquent un délai d’expiration de réponse HTTP de 230 secondes en raison des limites d’Azure Load Balancer.

Mise à l’échelle indépendante

Chaque microservice d’une composition a des caractéristiques de charge différentes.

Si vos services ont un trafic très variable ou soudain, Container Apps et Functions adaptent leur échelle en fonction du service et peuvent réduire les services inactifs à zéro. Cette approche évite les frais de capacité inutilisés. Pour Functions, chaque application de fonction est l’unité de mise à l’échelle. Déployez donc chaque microservice comme propre application de fonction. AKS fournit une mise à l’échelle par déploiement. Vous gérez les pools de nœuds partagés et dont l'approvisionnement est maintenu, et les pools de nœuds utilisateur peuvent être mis à l’échelle à zéro.

Les plateformes de mise à l’échelle à zéro introduisent une latence de démarrage à froid lorsqu’un service inactif reçoit sa première requête. Dans une architecture de microservices, une requête utilisateur unique peut traverser plusieurs services. Si plusieurs services de la chaîne d’appels sont non actifs, la latence se cumule. Pour les appels interservice synchrones nécessitant une faible latence, utilisez les fonctionnalités d’atténuation de démarrage à froid de la plateforme ou payez le coût pour conserver les instances minimales actives pour éviter les démarrages à froid.

Si vos services ont une charge stable, prévisible, AKS ou App Service peut réduire les coûts, car vous payez pour une capacité réservée au lieu de la facturation basée sur la consommation.

Déployabilité indépendante

Vous devez déployer, mettre à jour et restaurer des microservices individuels sans affecter le reste du système. Les quatre plateformes prennent en charge le déploiement indépendant, mais elles diffèrent de la façon dont vous validez les modifications. Container Apps et AKS fournissent un fractionnement du trafic en mode natif pour les déploiements progressifs. App Service prend en charge le routage du trafic basé sur des pourcentages entre les emplacements de déploiement. Functions prend en charge les emplacements de déploiement sur les plans Premium et Dédié.

Observabilité distribuée

Une demande d’utilisateur unique peut parcourir de nombreux services. Si vous avez besoin de traces corrélées sur la chaîne d’appels complète, vérifiez que l’outil d’observabilité de votre plateforme s’intègre à votre stratégie de suivi. Container Apps offre une observabilité intégrée avec le traçage Dapr. AKS s’intègre à OpenTelemetry et aux outils de suivi open source, ce qui vous permet de choisir votre back-end de suivi (comme Jaeger, Zipkin ou Azure Monitor), mais vous oblige à déployer et configurer le pipeline de collecte. Functions et App Service s’intègrent à Application Insights pour le suivi des transactions de bout en bout avec une configuration minimale.

Assurez-vous que chaque service de la composition expose des métriques par service telles que le taux de requêtes, le taux d’erreur et la latence. Ces métriques vous aident à identifier le service qui se dégrade sans mettre en corrélation les logs sur la chaîne d’appels complète.

Gestion de l'état

Dans une architecture de microservices, chaque service possède généralement ses données et externalise l’état d’une base de données ou d’un cache dédié. Ce modèle conserve les services déployables indépendamment, et les quatre plateformes la prennent en charge de façon égale, car le magasin de données est une ressource Azure distincte.

Les plateformes diffèrent quand un service a besoin d’abstractions d’état managé par la plateforme, telles que des modèles basés sur des acteurs, l’orchestration de flux de travail ou le stockage dédié par instance :

• AKS offre la plus grande flexibilité par le biais de volumes persistants et de StatefulSets, qui prennent en charge les magasins de données en cluster et l’identité stable par instance.

• Container Apps prend en charge les montages de volumes ainsi que la gestion d'état Dapr, y compris les acteurs Dapr.

• Functions prend en charge les orchestrations avec état et les entités via Durable Functions.

• App Service prend en charge le stockage partagé via des montages Azure Files, mais ne fournit pas d’abstractions d’état par instance ou au niveau de la plateforme.

Considérations

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.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Dans une architecture de microservices, le risque de fiabilité principal est une défaillance en cascade. Un service défectueux provoque l’accumulation des délais d’attente par les appelants et le problème se propage vers l’extérieur par le biais de la chaîne d’appels. Votre choix de plateforme affecte la façon dont vous atténuez ce risque.

• AKS et Container Apps fournissent des sondes d’intégrité au niveau de la plateforme qui détectent des instances non saines et les suppriment automatiquement de la rotation.

• Les fonctions réessaient les exécutions échouées en fonction du type de déclencheur.

Quelle que soit la plateforme, implémentez des disjoncteurs, réessayez des stratégies avec interruption et délai d’attente dans votre communication interservice pour empêcher une défaillance de service unique de devenir une panne à l’échelle du système.

Déployez chaque service dans des zones de disponibilité pour vous protéger contre les défaillances au niveau du centre de données. Dans une composition de plateforme mixte, vérifiez que toutes les plateformes utilisées prennent en charge la redondance de zone pour votre région de déploiement.

Pour obtenir des conseils de fiabilité spécifiques à la plateforme, consultez les sections de fiabilité des guides de service Well-Architected Framework pour AKS, Container Apps et Functions.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Les microservices augmentent la surface d’attaque, car chaque appel de service à service traverse une limite réseau. Traitez tout le trafic interservice comme non approuvé et chiffrez-le via mTLS. AKS prend en charge mTLS via des maillages de service comme Istio. Container Apps fournit mTLS via Dapr ou la configuration au niveau de l’environnement. Les fonctions et App Service ne fournissent pas de MTLS au niveau de la plateforme. Si ces plateformes hébergent des services dans votre composition, appliquez la sécurité du transport via le protocole HTTPS de couche application, les stratégies de passerelle d’API ou l’isolation du réseau virtuel.

Dans une composition de nombreux services, chaque service doit s’authentifier uniquement auprès des ressources dont il a besoin. Attribuez des identités par service plutôt que de partager une seule identité sur la charge de travail. Pour connaître les mécanismes spécifiques à la plateforme, consultez la ligne d’identité par service dans la table de comparaison.

Pour obtenir des conseils de sécurité spécifiques à la plateforme, consultez les sections de sécurité des guides de service Well-Architected Framework pour AKS, Container Apps et Functions.

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 Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Une architecture de microservices peut inclure des dizaines de services, et chaque service gère différents volumes de trafic. Mettre en correspondance chaque service au modèle de facturation qui correspond à son modèle de trafic. Les plateformes basées sur la consommation, telles que Container Apps et Functions, mettent à l’échelle les services inactifs jusqu'à zéro, mais des solutions de calcul dédiées comme AKS peuvent être plus économiques pour les services ayant une charge soutenue. Dans une composition de plateforme mixte, la flexibilité de facturation par service est l’un des principaux avantages des coûts. Toutefois, comptez de la surcharge liée à la maintenance de pipelines de déploiement distincts, de la supervision des configurations et de l’expertise de l’équipe sur plusieurs plateformes.

Pour obtenir des conseils sur les coûts spécifiques à la plateforme, consultez les sections d’optimisation des coûts des guides de service Well-Architected Framework pour AKS, Container Apps et Functions.

Architectures de référence

Limitez vos options à une ou deux plateformes en appliquant les critères de comparaison dans cet article. Exécutez une preuve de concept en déployant un sous-ensemble représentatif de vos services et en testant la communication interservice, le comportement de mise à l’échelle et les flux de travail de déploiement en fonction de vos besoins. Vérifiez que la plateforme répond aux attentes opérationnelles de votre équipe avant de vous engager en production. Les architectures suivantes fournissent des points de départ prêts pour la production :

• Architecture AKS :Architecture de base pour un cluster AKS
• Container Apps :Microservices avec Container Apps et Dapr
• App Service :Application web de base hautement disponible et redondante entre zones
• Azure Red Hat OpenShift :Azure Red Hat OpenShift dans un environnement hybride

Étape suivante

Ressources associées

• Concevoir une architecture de microservices
• Concevoir des API pour les microservices
• Utiliser l’analyse de domaine pour modéliser les microservices
• Choose un service de calcul Azure
• Choose un service de conteneur Azure
• Considérations architecturales relatives au choix d’un service de conteneur Azure