Les microservices sont un style architectural répandu pour générer des applications résilientes, hautement scalables, capables d’évoluer rapidement et pouvant être déployées indépendamment. Mais une architecture de microservices réussie nécessite une approche différente pour concevoir et générer des applications.
Une architecture de microservices se compose d’un ensemble de petits services autonomes. Chaque service est autonome et doit implémenter une fonctionnalité unique dans un contexte borné. Un contexte borné est une division naturelle au sein d’une entreprise qui fournit une délimitation explicite dans laquelle un modèle de domaine existe.
Que sont les microservices ?
Les microservices sont de petite taille, indépendants et faiblement couplés. Une équipe réduite de développeurs peut écrire un service et en assurer la maintenance.
Chaque service est un code base distinct, qui peut être géré par une petite équipe de développement.
Les services peuvent être déployés de manière indépendante. Une équipe peut mettre à jour un service existant sans avoir à recréer et redéployer l’application entière.
Les services sont responsables de la persistance de leurs propres données ou de leur propre état externe. Ils se distinguent en cela du modèle traditionnel dans lequel une couche de données distincte gère la persistance des données.
Les services communiquent entre eux à l’aide d’API bien définies. Les détails de l’implémentation interne de chaque service sont cachés aux autres services.
Prend en charge la programmation polyglotte. Par exemple, les services n’ont pas besoin de partager une pile de technologies, des bibliothèques ou des frameworks identiques.
Outre les services proprement dits, une architecture de microservices type est constituée d’autres composants :
Gestion/orchestration. Ce composant est chargé de placer les services sur des nœuds, d’identifier les défaillances, de rééquilibrer les services entre les nœuds, etc. En général, ce composant est une technologie prête à l’emploi comme Kubernetes, plutôt qu’un élément personnalisé.
Passerelle d’API : la passerelle d’API est le point d’entrée des clients. Au lieu d’appeler directement les services, les clients appellent la passerelle d’API, qui transfère l’appel aux services appropriés sur le back-end.
L’utilisation de la passerelle d’API offre les avantages suivants :
Il dissocie les clients des services. Les services peuvent être versionnés ou refactorisés sans avoir à mettre à jour tous les clients.
Les services peuvent utiliser des protocoles de messagerie qui ne sont pas compatibles avec le web, comme AMQP.
La passerelle d’API peut exécuter d’autres fonctions transversales, telles que l’authentification, la journalisation, la terminaison SSL et l’équilibrage de charge.
Stratégies prêtes à l’emploi, telles que la limitation, la mise en cache, la transformation ou la validation.
Avantages
Agilité. Les microservices sont déployés de manière indépendante, ce qui facilite la gestion des correctifs de bogues et des nouvelles fonctionnalités. Vous pouvez mettre à jour un service sans avoir à redéployer l’application entière et effectuer une restauration si une mise à jour est source de problèmes. Dans de nombreuses applications traditionnelles, s’il existe un bogue dans une partie de l’application, il peut bloquer tout le processus de mise en production. Les nouvelles fonctionnalités peuvent être retardées le temps qu’une résolution de bogue soit intégrée, testée et publiée.
Équipes spécialisées de taille restreinte. Un microservice doit être suffisamment petit pour qu’une seule équipe de fonctionnalité puisse le générer, le tester et le déployer. Les petites équipes favorisent une plus grande souplesse. Les grandes équipes ont tendance à être moins productives, car la communication est plus lente, le temps de gestion augmente et l’agilité diminue.
Base de code de petite taille. Dans une application monolithique, les dépendances de code ont tendance à s’entremêler au fil du temps. L’ajout d’une nouvelle fonctionnalité demande de modifier le code à de nombreux endroits. En ne partageant ni code, ni magasins de données, une architecture de microservices minimise les dépendances, ce qui facilite l’ajout de nouvelles fonctionnalités.
Pot-pourri de technologies. Les équipes peuvent choisir la technologie qui convient le mieux à leur service à l’aide de diverses piles technologiques.
Isolation des erreurs : Si un microservice individuel devient indisponible, cela ne perturbera pas l'ensemble de l'application, pour autant que les microservices en amont soient conçus pour gérer correctement les défaillances. Par exemple, vous pouvez implémenter le modèle disjoncteur ou concevoir votre solution afin que les microservices communiquent entre eux à l’aide de modèles de messagerie asynchrones.
Extensibilité. Les services peuvent être mis à l’échelle de manière indépendante, ce qui permet d’effectuer un scale-out de sous-systèmes qui nécessitent plus de ressources, sans effectuer un scale-out de l’ensemble de l’application. En utilisant un orchestrateur tel que Kubernetes, vous pouvez emballer une plus grande densité de services sur un seul hôte, ce qui permet une utilisation plus efficace des ressources.
Isolation des données. Il est beaucoup plus facile d’effectuer des mises à jour de schéma, car un seul microservice est concerné. Dans une application monolithique, les mises à jour de schéma peuvent devenir très difficiles, car les différentes parties de l’application impliquer les mêmes données, d’où le risque de modifier le schéma.
Défis
Les avantages des microservices ont néanmoins un prix. Voici certains des défis à prendre en compte avant de se lancer dans une architecture de microservices.
Complexité : une application de microservices possède plus d’éléments mobiles qu’une application monolithique équivalente. Si chaque service est plus simple, le système dans son ensemble est plus complexe.
Développement et test. L’écriture d’un petit service qui s’appuie sur d’autres services dépendants nécessite une approche différente de celle consistant à écrire une application monolithique ou en couches traditionnelle. Les outils existants ne sont pas toujours conçus pour fonctionner avec des dépendances de services. Refactoriser au-delà des limites des services peut s’avérer difficile. Il est aussi difficile de tester les dépendances de services, en particulier quand l’application évolue rapidement.
Manque de gouvernance : l’approche décentralisée de création de microservices présente des avantages, mais elle peut aussi être une source de problèmes. Vous pouvez en effet vous trouver face à une diversité de langages et de frameworks telle que l’application devient difficile à gérer. Il peut être utile de mettre en place certains standards à l’échelle du projet, sans trop limiter la flexibilité des équipes. Cela vaut en particulier pour les fonctionnalités transversales, telles que la journalisation.
Surcharge du réseau et latence : l’utilisation de nombreux services granulaires de petite taille peut se traduire par une intensification des communications entre les services. De même, si la chaîne des dépendances de services devient trop longue (le service A appelle le service B, qui appelle le service C, etc.), la latence supplémentaire qui s’ensuit peut devenir un problème. Vous devrez faire preuve de circonspection au moment de concevoir des API. Évitez les API trop bavardes, envisagez des formats de sérialisation et cherchez à utiliser des modèles de communication asynchrone comme le nivellement de charge basé sur les files d’attente.
Intégrité des données : chaque microservice étant responsable de la persistance de ses propres données, la cohérence des données peut être une gageure. Adoptez la cohérence éventuelle dans la mesure du possible.
Gestion : une expérience réussie avec les microservices exige une culture DevOps mature. La mise en place d’une journalisation corrélée entre les services peut poser des problèmes. En règle générale, la journalisation doit mettre en corrélation plusieurs appels de services pour une même opération utilisateur.
Gestion des versions : les mises à jour apportées à un service ne doivent pas perturber les services qui en dépendent. Plusieurs services pouvant être mis à jour à tout moment, sans une conception minutieuse, vous risquez de rencontrer des problèmes de compatibilité descendante ou ascendante.
Ensemble de compétences : les microservices sont des systèmes hautement distribués. Évaluez avec soin les chances de réussite en tenant compte des compétences et de l’expérience de l’équipe.
Processus de génération d’une architecture de microservices
Les articles listés ici présentent une approche structurée pour la conception, la génération et l’utilisation d’une architecture de microservices.
Analyse de domaine. Pour éviter certains pièges lors de la conception de microservices, utilisez l’analyse de domaine pour définir les limites de vos microservices. Procédez comme suit :
- Utilisez l’analyse de domaine pour modéliser les microservices.
- Utilisez la tactique de la conception pilotée par domaine pour concevoir des microservices.
- Identifiez les limites des microservices.
Concevez les services. Les microservices requièrent une approche différente pour concevoir et générer des applications. Pour plus d’informations, consultez Conception d’une architecture de microservices.
Utilisez-les dans un environnement de production. Étant donné que les architectures de microservices sont distribuées, vous devez disposer d’opérations fiables pour le déploiement et la supervision.
- Intégration continue/livraison continue (CI/CD) pour les architectures de microservices
- Générer un pipeline CI/CD pour les microservices sur Kubernetes
- Superviser les microservices exécutés sur Azure Kubernetes Service (AKS)