Choisir une option de calcul Azure pour les microservices

  • Article

Le terme calcul fait référence au modèle d’hébergement des ressources de calcul utilisées par votre application. Pour une architecture de microservices, deux approches sont particulièrement prisées :

  • Orchestrateur de service qui gère les services s’exécutant sur des nœuds dédiés (machines virtuelles).
  • Architecture sans serveur utilisant des fonctions en tant que service (FaaS).

Bien qu’il ne s’agisse pas des seules options, ce sont deux approches éprouvées pour créer des microservices. Une application peut inclure les deux approches.

Orchestrateurs de services

Un orchestrateur gère les tâches liées au déploiement et à la gestion d’un ensemble de services. Ces tâches incluent le placement des services sur des nœuds, la surveillance de l’intégrité des services, le redémarrage des services non intègres, l’équilibrage de charge du trafic réseau entre les instances de service, la détection des services, la mise à l’échelle du nombre d’instances d’un service et l’application des mises à jour de configuration. Les orchestrateurs les plus courants sont Kubernetes, Service Fabric, DC/OS et Docker Swarm.

Sur la plateforme Azure, envisagez les options suivantes :

  • Azure Kubernetes Service (AKS) est un service Kubernetes géré. AKS configure Kubernetes et expose les points de terminaison d’API Kubernetes, mais il héberge et gère le plan de contrôle Kubernetes, en exécutant les mises à niveau automatisées, l’application automatisée de correctifs, la mise à l’échelle automatique et d’autres tâches de gestion. Vous pouvez considérer AKS comme « des API Kubernetes en tant que service ».

  • Azure Container Apps est un service managé basé sur Kubernetes qui extrait les complexités de l’orchestration de conteneur et d’autres tâches de gestion. Container Apps simplifie le déploiement et la gestion des applications conteneurisées et des microservices dans un environnement serverless tout en fournissant les fonctionnalités de Kubernetes.

  • Service Fabric est une plateforme de systèmes distribués pour le packaging, le déploiement et la gestion de microservices. Les microservices peuvent être déployés vers Service Fabric comme des conteneurs, des exécutables binaires ou des Reliable Services. À l’aide du modèle de programmation des Reliable Services, les services peuvent directement utiliser les API de programmation Service Fabric pour interroger le système, vérifier l’intégrité, recevoir des notifications sur la configuration et les modifications de code, et détecter d’autres services. La singularité de Service Fabric tient au fait qu’il est axé sur la création de services avec état à l’aide de Reliable Collections.

  • D'autres options comme Docker Édition Entreprise peuvent s’exécuter dans un environnement IaaS sur Azure. Des modèles de déploiement sont disponibles sur la Place de marché Azure.

Containers

On fait parfois l’amalgame entre conteneurs et microservices. Or, il s’agit de deux choses différentes (vous n’avez pas besoin de conteneurs pour générer des microservices) et les conteneurs ont des avantages particulièrement intéressants pour les microservices, tels que :

  • Portabilité : Une image de conteneur est un package autonome qui s’exécute sans nécessiter l’installation des bibliothèques ou autres dépendances. Cela la rend facile à déployer. Les conteneurs peuvent être démarrés et arrêtés rapidement, afin de lancer des instances pour gérer plus de charge ou pour effectuer une récupération après la défaillance d’un nœud.

  • Densité. Les conteneurs sont légers par rapport à l’exécution d’une machine virtuelle, car ils partagent les ressources du système d’exploitation. Cela permet de packager plusieurs conteneurs sur un seul nœud, ce qui est particulièrement utile lorsque l’application se compose de nombreux petits services.

  • Isolation des ressources. Vous pouvez limiter la quantité de mémoire et d’UC disponible pour un conteneur, ce qui contribue à garantir qu’un processus de perte de contrôle n’épuise pas les ressources de l’hôte. Pour plus d’informations, consultez Modèle de cloisonnement.

Sans serveur (fonctions en tant que service)

Avec une architecture sans serveur, vous ne gérez ni les machines virtuelles, ni l’infrastructure de réseau virtuel. Par contre, vous déployez le code et le service d’hébergement se charge de placer ce code sur une machine virtuelle et de l’exécuter. Cette approche a tendance à favoriser les petites fonctions granulaires coordonnées à l’aide de déclencheurs d’événements. Par exemple, un message placé dans une file d’attente peut déclencher une fonction qui lit le contenu de la file d’attente et traite le message.

Azure Functions est un service de calcul sans serveur qui prend en charge différents déclencheurs de fonction, y compris les requêtes HTTP, les files d'attente Service Bus et les événements Event Hubs. Pour obtenir la liste complète, consultez Concepts des déclencheurs et liaisons Azure Functions. Envisagez également Azure Event Grid, un service de routage d'événement managé d'Azure.

Orchestrateur ou sans serveur ?

Voici quelques éléments à prendre en compte lors du choix entre une approche d’orchestrateur et une approche sans serveur.

Facilité de gestion : Une application serverless est facile à gérer parce que la plateforme gère toutes les ressources de calcul à votre place. Alors qu’un orchestrateur rend abstraits certains aspects de la gestion et de la configuration d’un cluster, il ne masque pas complètement les machines virtuelles sous-jacentes. Avec un orchestrateur, vous devez envisager des problèmes tels que l’équilibrage de charge, l’utilisation de l’UC et de la mémoire, et la mise en réseau.

Flexibilité et contrôle : un orchestrateur vous donne un grand contrôle sur la configuration et la gestion de vos services et du cluster. L’inconvénient est la complexité accrue. Avec une architecture sans serveur, vous perdez en contrôle, car ces détails sont rendus abstraits.

Portabilité : tous les orchestrateurs répertoriés ici (Kubernetes, DC/OS, Docker Swarm et Service Fabric) peuvent s’exécuter localement ou dans plusieurs clouds publics.

Intégration d’application : La création d'une application complexe à l'aide d'une architecture serverless peut être difficile en raison de la nécessité de coordonner, de déployer et de gérer de nombreuses petites fonctions indépendantes. Une option dans Azure consiste à utiliser Azure Logic Apps pour coordonner un ensemble de fonctions Azure. Pour obtenir un exemple de cette approche, consultez Créer une fonction qui s’intègre avec Azure Logic Apps.

Coût : avec un orchestrateur, vous payez pour les machines virtuelles qui s’exécutent dans le cluster. Avec une application sans serveur, vous payez uniquement pour les ressources de calcul réellement consommées. Dans les deux cas, vous devez tenir compte du coût des services supplémentaires, tels que le stockage, les bases de données et les services de messagerie.

Extensibilité. Azure Functions est automatiquement mis à l’échelle afin de répondre à la demande, en fonction du nombre d’événements entrants. Avec un orchestrateur, vous pouvez effectuer un scale-out en augmentant le nombre d’instances de service en cours d’exécution dans le cluster. Vous pouvez également effectuer une mise à l’échelle en ajoutant des machines virtuelles au cluster.

Notre implémentation de référence utilise principalement Kubernetes, mais nous avons utilisé Azure Functions pour un service, à savoir le service Historique des livraisons. Azure Functions est bien adapté à ce service particulier, car il s’agit d’une charge de travail pilotée par des événements. En utilisant un déclencheur Event Hubs pour appeler la fonction, le service avait besoin d’une quantité minimale de code. En outre, le service Historique des livraisons ne fait pas partie du workflow principal. Son exécution en dehors du cluster Kubernetes n’a donc aucune incidence sur la latence de bout en bout des opérations initiées par l’utilisateur.

Étapes suivantes

Communication entre les services