Microservices

Comment fonctionnent les microservices ?

Dans une architecture microservices, une application est divisée en tâches et services distincts. Chaque tâche ou service est créé indépendamment, et chacun exécute un processus unique et gère généralement sa propre base de données. Un service peut générer des alertes, enregistrer des données, prendre en charge des interfaces utilisateur, gérer l'identification ou l'authentification des utilisateurs et effectuer diverses autres tâches de calcul et de traitement.

Par comparaison, une architecture monolithique traditionnelle peut comprendre le même assortiment fondamental de tâches et de services nécessaires à la réalisation de l'objectif de l'application. Mais ces fonctions sont toutes contenues dans une seule grande application exécutable tout-en-un. Une application microservices peut être conçue et assemblée pour réaliser un grand nombre des tâches précédemment réalisées par des applications monolithiques.

Le paradigme des microservices offre aux équipes de développement une approche plus décentralisée de la création de logiciels. Chaque service peut être isolé, reconstruit, testé, redéployé et géré indépendamment. Par exemple, si un programme ne génère pas correctement des rapports, le personnel informatique peut remonter le problème jusqu'à un service spécifique, puis tester, redémarrer, corriger et redéployer ce service en fonction des besoins, indépendamment des autres services.

Caractéristiques de l'architecture et de la conception des microservices

L'architecture microservices est constituée de composants et de services discrets ; leur intercommunication et leurs échanges de données créent les fonctions d'une application complète. Les caractéristiques typiques d'une conception et d'une architecture de microservices sont les suivantes :

• Composants uniques. Les services sont conçus et déployés en tant que composants individuels travaillant ensemble pour accomplir une fonction spécifique ou répondre à une exigence particulière.
• Décentralisé. Les composants uniques des microservices ont peu de dépendances, voire aucune, bien que le couplage lâche nécessite une communication fréquente et étendue entre les composants.
• Résilience. Les services sont conçus pour une tolérance maximale aux pannes. La défaillance d'un seul service ne doit pas entraîner la désactivation de l'ensemble de l'application. Cela nécessite souvent une excellente conception logicielle et des pratiques d'ingénierie de fiabilité des sites (SRE), ainsi qu'un déploiement redondant et des techniques de basculement et d'évolutivité élevées.
• Basée sur les API. Une architecture microservices s'appuie sur des API et des passerelles API pour faciliter la communication entre les composants et les autres applications.
• Séparation des données. Chaque service accède à sa propre base de données ou à son propre volume de stockage.
• Automatisation. Les composants des applications microservices peuvent être nombreux - et leur déploiement manuel peut s'avérer fastidieux. Les microservices s'appuient sur des technologies d'automatisation et d'orchestration pour le déploiement et la mise à l'échelle des composants.

Avantages d'une architecture microservices

Les conceptions et les déploiements de microservices se sont développés grâce au cloud, à la conteneurisation et aux systèmes hyperconnectés. Une architecture microservices offre plusieurs avantages :

• Indépendance. Chaque module ou service de microservice peut être développé à l'aide de langages et d'outils différents et déployé sur des plateformes différentes. La seule connexion entre les composants des microservices est l'API par laquelle ils communiquent à travers un réseau. Cela apporte de la flexibilité au développement des applications.
• Cycles de vie. Cette indépendance en matière de développement et de déploiement signifie que différentes équipes de développement construisent et entretiennent couramment des composants de microservices par le biais de pipelines d'intégration continue et de développement continu (CI/CD). Cela offre une plus grande agilité de développement et peut améliorer le temps de mise sur le marché. Elle réduit également le temps et les exigences de test, car seul le module est testé - il n'est pas nécessaire, ou très peu, de procéder à des tests de régression sur l'ensemble de l'application.
• Isolement. Étant donné que chaque composant d'une application microservices fonctionne indépendamment, il est beaucoup plus facile de surveiller l'état et les performances de chaque composant et de superviser le fonctionnement de l'ensemble de l'application. Cette isolation facilite également l'identification et la correction des erreurs, comme le redémarrage d'un module défaillant.
• Évolutivité. Pour faire évoluer une application monolithique traditionnelle, le personnel informatique doit déployer une nouvelle copie de l'ensemble de l'application. Avec une application microservices, seuls les composants associés doivent évoluer. Il est plus rapide et beaucoup moins gourmand en ressources de déployer et d'équilibrer la charge de quelques conteneurs plutôt que d'une application monolithique entière.
• Rapidité. Chaque composant microservices est de petite taille, ce qui permet aux développeurs de concevoir, coder, tester et mettre à jour un composant en beaucoup moins de temps qu'avec une application monolithique traditionnelle.
• Réutilisation. Les composants d'application modulaires sont réutilisables par d'autres applications, ce qui facilite encore les investissements dans la conception d'applications et accélère les délais de développement.
• Compatibilité avec les conteneurs. Les composants microservices sont adaptés au déploiement et à la gestion au sein de conteneurs virtuels, à l'aide de technologies de conteneurs et d'orchestration éprouvées telles que Docker et Kubernetes.

Microservices ou architecture monolithique

Une architecture monolithique est un programme unique. Elle incorpore toute l'application ou la logique opérationnelle nécessaire pour effectuer le travail dans une seule pile cohésive située sur un seul serveur principal au sein du centre de données. Cela a toujours été une façon logique et efficace de créer des applications, mais c'est inadapté à de nombreuses applications modernes et aux besoins des entreprises. Comparons les avantages des architectures monolithiques et des architectures microservices.

Principales différences

Les applications monolithiques sont considérées comme des entités tout-en-un où l'ensemble de l'application est construit, testé et déployé en tant que base de code unique. Les utilisateurs accèdent à l'application par l'intermédiaire de l'interface d'application côté client ou de la couche de présentation. Les interactions et les requêtes des utilisateurs sont échangées conformément à la logique sous-jacente de l'application et de l'entreprise, qui dicte l'accès à la base de données, le traitement des données et la manière dont les résultats sont renvoyés au client. Aucune application monolithique n'existe ou ne fonctionne sans dépendances - c'est simplement que la plupart du "travail" spécifique de l'application est effectué au sein d'une seule entité logicielle.

Une architecture microservices décompose la logique sous-jacente en une série de tâches ou de services différents, dont chacun peut être développé et déployé séparément et communiquer par l'intermédiaire d'une API. Les utilisateurs interagissent avec l'application via une application côté client ou un portail web ; l'interface distribue les demandes des clients aux services correspondants et renvoie les résultats à l'utilisateur. Une application microservices implique également des dépendances telles qu'un noyau de système d'exploitation (OS) commun, des moteurs d'orchestration de conteneurs et des identifiants d'accès aux bases de données.

Avantages et inconvénients

Les architectures monolithiques ne sont pas nécessairement complexes, mais la construction d'applications complexes avec de nombreux points d'intégration sur une architecture monolithique introduit de nombreux points de défaillance possibles, tels que des bogues logiciels ou des défaillances matérielles, qui peuvent entraîner des temps d'arrêt prolongés et une intervention humaine. Les applications monolithiques sont volumineuses et longues à coder, à construire et à tester. De plus, les applications monolithiques ne s'adaptent pas bien. Par exemple, si une application a besoin de plus de puissance de calcul pour faire face à un pic de demandes des utilisateurs, une nouvelle instance de cette application - et toutes ses dépendances - doit être déployée sur un autre serveur.

À l'échelle, les microservices offrent un niveau d'efficacité que les applications monolithiques traditionnelles ne peuvent pas atteindre. Lorsqu'une fonction de microservice nécessite plus de puissance de calcul, seul ce microservice est mis à l'échelle en ajoutant plus d'instances de ce service par le biais d'un équilibreur de charge pour partager le trafic réseau. En outre, les outils d'orchestration et d'automatisation utilisés pour déployer et gérer les services peuvent détecter si un service tombe en panne ou ne répond plus et redémarrer automatiquement un service en difficulté. Enfin, un microservice unique contient moins de code et moins de fonctions à tester, et nécessite beaucoup moins de tests de régression pour détecter les conséquences involontaires des changements ou des mises à jour. Ces facteurs peuvent accélérer le développement et la maintenance des services.

Les microservices posent également des problèmes. La prolifération des services individuels multiplie la complexité de l'environnement des microservices. Chaque service dépend des performances et de l'intégrité du réseau, et chaque service individuel doit être relié à des outils de gestion, de journalisation, de surveillance et autres.

Architectures d'applications hybrides et modulaires

Le passage d'une architecture d'application monolithique à une architecture de microservices peut être problématique pour les développeurs. Une base de code monolithique n'est pas toujours bien organisée en services individuels bien ordonnés. Une autre solution consiste à envisager un modèle hybride de microservices, qui met à jour une application existante avec un mélange de code et de services monolithiques, le tout déployé par le biais de conteneurs basés sur le cloud.

Une autre option est une architecture monolithique modulaire, qui cherche à équilibrer l'évolutivité, la vitesse et la complexité opérationnelle. Cette approche segmente le code en modules de fonctions individuels, ce qui limite les dépendances et isole les magasins de données, mais préserve les communications plus simples, l'encapsulation logique et la réutilisabilité d'une architecture monolithique.

Composants et fonctions de l'architecture microservices

Les applications traditionnelles sont conçues et construites comme un seul bloc de code. Une architecture microservices exprime une application comme une série de services ou de composants logiciels indépendants mais liés, qui peuvent être développés, testés et déployés indépendamment, voire comme des projets logiciels distincts. Les services interagissent et communiquent par le biais d'API sur un réseau en utilisant des protocoles légers tels que le protocole de transfert hypertexte (HTTP) et le transfert d'état représentationnel (REST). C'est ce processus qui fait émerger l'application globale.

Une architecture de microservices se compose de plusieurs caractéristiques ou fonctions principales. Outre les services individuels, les composants typiques d'une architecture microservices comprennent les API, les conteneurs, un maillage de services, les concepts SOA et le cloud.

Microservices et API

Les API et les microservices sont des technologies différentes mais complémentaires. Les API facilitent l'intégration et la communication entre les différents services dans une architecture microservices, permettant aux services de demander et de recevoir des résultats les uns des autres. Cette interopérabilité assure la fonctionnalité globale de l'application.

Au cœur de cette structure se trouve une passerelle API, qui gère, organise et distribue les appels API entre les services et les clients externes. Les passerelles gèrent également la sécurité de l'API, la surveillance et l'équilibrage de la charge. Le fait de se décharger de ces tâches administratives permet aux microservices de rester agiles et légers.

Microservices et conteneurs

Un conteneur est un ensemble de logiciels individuels et exécutables, comprenant toutes les dépendances nécessaires pour fonctionner de manière indépendante. Les conteneurs sont séparés du reste du logiciel qui les entoure, et de nombreux conteneurs peuvent être utilisés dans le même environnement. Dans une architecture microservices, chaque service est conteneurisé individuellement dans le même environnement, par exemple le même serveur ou des serveurs apparentés.

Les microservices sont presque toujours associés à des conteneurs virtuels, qui sont des constructions utilisées pour emballer les services et leurs dépendances. Les conteneurs peuvent partager un noyau de système d'exploitation commun qui leur permet d'exister sur les serveurs en bien plus grand nombre que les machines virtuelles (VM) plus traditionnelles. Les conteneurs peuvent également être rapidement mis en marche et arrêtés, souvent en l'espace de quelques secondes.

Bien que les conteneurs ne soient pas nécessaires pour les microservices, ils les rendent pratiques. Les instances de petite taille et peu gourmandes en ressources des conteneurs sont adaptées aux petites bases de code que l'on trouve dans les microservices. Leur création et leur démontage rapides les rendent évolutifs et temporaires ou éthérés. Les outils modernes d'orchestration de conteneurs, tels que Kubernetes, permettent de détecter et de redémarrer les conteneurs défaillants avec une intervention humaine minimale.

En comparaison, une VM typique nécessite un système d'exploitation complet, des pilotes et d'autres éléments. Un microservice peut être déployé dans une VM. Cela peut apporter une isolation supplémentaire, mais cela crée également une redondance et des coûts inutiles. Pourquoi déployer et payer 10 à 20 licences de système d'exploitation pour des machines virtuelles afin de créer une seule application ? Les VM sont bien plus efficaces en termes de coûts et de ressources pour des applications monolithiques complètes.

Microservices et maillage de services

Bien que les API servent de colle proverbiale pour la communication entre les services, la logique réelle qui régit la communication est un autre défi. Il est possible, bien que fastidieux, de coder la logique de communication dans chaque service d'une application typiquement complexe.

D'autre part, l'architecture microservices s'appuie souvent sur un maillage de services pour abstraire la communication de service à service des services et la placer dans une autre couche de l'infrastructure. Elle crée des conteneurs proxy - également appelés conteneurs sidecar - qui se rapportent à un ou plusieurs services et acheminent le trafic si nécessaire, tandis que ces services poursuivent leurs opérations. Une application microservices peut faire appel à de nombreux mandataires pour gérer divers services ou collections de services connexes.

Microservices et SOA

Il existe des similitudes entre les microservices et l'architecture orientée services, mais ce ne sont pas les mêmes. L'architecture orientée services est une approche de développement logiciel axée sur la combinaison de composants logiciels réutilisables ou de services. Une interface commune permet aux services d'interopérer à travers un bus de services d'entreprise, tout en exigeant peu de connaissances sur le fonctionnement de chaque service. Les composants SOA s'appuient souvent sur le langage de balisage extensible (XML) et le protocole d'accès aux objets simples (SOAP) pour communiquer.

Le modèle SOA fonctionne le mieux pour les services qui sont largement transactionnels et réutilisables dans de grands systèmes logiciels. L'architecture SOA n'est pas aussi bien adaptée aux codes nouveaux ou remaniés, ou aux projets qui impliquent des cycles de développement et de déploiement rapides et continus - c'est là que les microservices brillent.

D'une certaine manière, les microservices sont une évolution de l'architecture SOA, mais ils ne sont pas interdépendants. La principale différence entre l'architecture SOA et les microservices est le champ d'application : L'architecture SOA est conçue pour fonctionner dans l'ensemble de l'entreprise, tandis que la portée des microservices est limitée à l'application elle-même. L'architecture SOA peut compléter les microservices en permettant aux applications et aux composants d'interopérer avec d'autres services réutilisables au sein de l'entreprise.

Les microservices et l'informatique dématérialisée

Les conteneurs et les microservices peuvent être déployés et orchestrés dans n'importe quel centre de données ou installation de colocation, mais ils nécessitent une infrastructure conçue pour gérer de tels volumes de services intégrés et une mise à l'échelle rapide ou imprévisible. Les cloud publics fournissent des environnements idéaux pour l'informatique à la demande et évolutive, ainsi que des moteurs d'orchestration, des passerelles API, des structures de licence avec paiement à l'utilisation et d'autres éléments qui constituent les éléments de base d'une architecture de microservices.

Les défis d'une architecture microservices

Bien que les avantages des microservices soient convaincants, les adoptants doivent également évaluer et traiter certains inconvénients potentiels d'une application microservices.

• Complexité inutile. Toutes les applications ne sont pas adaptées au paradigme des microservices. L'investissement nécessaire pour appliquer les techniques de microservices à des applications plus petites et plus simples pourrait ne pas être rentable. Tenez compte de la nature, de la complexité et de la portée de chaque projet et évaluez les avantages et les inconvénients d'une approche microservices avant de vous engager dans la conception.
• Performance. Un conteneur de microservices offre d'excellentes performances de calcul pour sa tâche, mais plusieurs d'entre eux doivent communiquer à travers le réseau pour que l'application globale fonctionne. L'encombrement du réseau et la latence peuvent entraver les performances et annuler ces avantages individuels. En outre, le volume de microservices nécessaires à la prise en charge des applications requiert une gestion et un contrôle supplémentaires du réseau et peut nécessiter plusieurs instances d'équilibrage de la charge.
• Limites du réseau. Les composants microservices s'appuient sur une communication basée sur l'API sur un réseau. Les réseaux d'entreprise existants peuvent donc être soumis à des contraintes importantes en termes de bande passante et de latence, qui peuvent encore être multipliées par la présence de nombreuses applications microservices fonctionnant simultanément dans l'environnement et l'infrastructure de l'entreprise. Certains utilisateurs de microservices pourraient avoir besoin d'une mise à niveau de leur réseau pour répondre aux exigences de communication d'applications microservices très sollicitées. En outre, les vulnérabilités du réseau et les risques de sécurité peuvent facilement être exacerbés dans les environnements microservices complexes.
• Surveillance. Un environnement d'application microservices peut être extrêmement complexe, et tous les composants déployés pour construire l'application doivent être surveillés et faire l'objet de rapports. Ce défi est exacerbé par la nature éthérée de ces composants, qui doivent être surveillés au fur et à mesure de leur déploiement et de leur suppression. Cela nécessite un niveau élevé de surveillance de l'état et des performances, ainsi que l'automatisation et l'orchestration.
• Sécurité. La sécurité des applications est essentielle pour protéger l'accès au logiciel et aux données sous-jacentes, mais elle peut s'avérer plus difficile avec les microservices. Les API doivent s'autoriser et s'authentifier à chaque appel, et chaque composant doit renforcer le service contre les intrusions. Les outils et processus de sécurité doivent surveiller et rendre compte dans un environnement microservices complexe et changeant. Une automatisation poussée est nécessaire pour associer la configuration et la surveillance de la sécurité à chaque composant microservices. En outre, chaque module de composant doit recevoir les correctifs et les mises à jour appropriés pour maintenir une sécurité cohérente dans l'ensemble de l'application, ce qui peut s'avérer difficile lorsque les modules sont maintenus par des équipes différentes selon des calendriers différents.
• Culture. Le développement de microservices représente un nouvel état d'esprit sur la manière de concevoir, de construire et d'exploiter les applications d'entreprise. Cela signifie qu'une entreprise doit adapter non seulement les outils et les processus de développement qu'elle utilise, mais aussi favoriser les compétences de programmation et la culture d'équipe pour prendre en charge les microservices. Les développeurs doivent collaborer lorsqu'ils travaillent sur différents services et adopter des paradigmes de développement continu, des pratiques complètes d'automatisation des processus et des flux de travail, ainsi que la surveillance et la sécurité.

Le rôle des microservices dans DevOps

Bien que les microservices et DevOps soient deux concepts différents et ne s'appuient pas l'un sur l'autre, on les rencontre fréquemment ensemble en raison de l'alignement naturel étroit entre les deux idées.

DevOps combine les tâches des équipes d'exploitation des applications et des systèmes. L'amélioration de la communication entre les développeurs et le personnel d'exploitation permet à l'équipe informatique de mieux créer et gérer l'infrastructure. Les budgets des projets DevOps comprennent souvent des provisions pour le déploiement, la planification et la mise à l'échelle de la capacité, les tâches opérationnelles, les mises à niveau et plus encore. Les développeurs et les équipes chargées des applications peuvent gérer les bases de données, les serveurs, les logiciels et le matériel utilisés dans la production.

Les microservices sont un paradigme utilisé pour concevoir, construire et déployer des logiciels modernes. Cela implique la création, le déploiement, la surveillance et la gestion de nombreux composants individuels qui constituent l'application globale. Étant donné que DevOps et d'autres techniques agiles sont souvent utilisées pour créer et déployer des logiciels, les nombreux composants impliqués dans les microservices s'intègrent naturellement à DevOps. En outre, la prise en charge du cycle de vie des microservices nécessite un travail d'équipe et une collaboration entre les équipes de développement et d'exploitation, ce qui se prête au mode de fonctionnement des équipes DevOps. Les équipes DevOps expérimentées sont bien équipées pour utiliser des architectures de type microservices dans les projets de développement de logiciels.

Considérations de conception pour une transition réussie vers les microservices

De nombreuses implémentations de microservices adhèrent encore à des modèles de conception hérités et sont entravées par ceux-ci. Cela signifie que les architectes et les développeurs doivent adopter de nouveaux principes et modèles de conception, prendre en compte les implications de l'accès aux bases de données et de la mise en réseau, et mettre en œuvre une messagerie efficace entre les services. Il s'agit d'une tâche ardue qui nécessite du temps et de l'expérience.

Principes de conception

Les principes de conception de l'architecture microservices permettent de rationaliser le fonctionnement de chaque service et de s'assurer que chaque service fournit des résultats optimaux pour l'ensemble de l'application. Les principes les plus courants sont les suivants :

• Cohésion élevée. Les services doivent fonctionner ensemble avec un minimum de communication pour tirer le meilleur parti de la bande passante limitée du réseau.
• Faible couplage. Les services doivent avoir peu d'interdépendances, voire aucune. Cela minimise l'effet des perturbations en cas de défaillance d'un composant et se prête bien à la conception de modules réutilisables.
• Champ de responsabilité unique. Un service doit être délimité de manière à refléter une exigence commerciale spécifique et à ne faire qu'une seule chose. Cela renforce l'idée de composants réutilisables.
• Fiabilité. Concevoir les services pour une tolérance aux pannes ou une résilience maximale, de sorte qu'une panne dans un service ne mette pas hors service l'ensemble de l'application. Cela implique souvent l'utilisation de services multiples ou redondants, de sorte que la défaillance d'un composant ne paralyse pas l'ensemble de l'application.
• Ne partagez pas vos données. Le partage du stockage et des données constitue une dépendance indésirable. Chaque service doit avoir ou pouvoir accéder à sa propre base de données ou à son propre volume de stockage.
• Utiliser l'automatisation. Utilisez des outils d'automatisation tels que Kubernetes pour déployer et gérer des composants microservices, souvent dans le cadre d'un pipeline CI/CD.
• Utiliser des API. Les API sont la méthode privilégiée pour l'interaction et la communication entre les services. Une bonne conception et une bonne gestion des API sont essentielles à la réussite des applications microservices.
• Contrôler. Utiliser des outils de surveillance pour contrôler et signaler l'état, les performances et les problèmes des services et pour gérer le trafic afin d'optimiser les performances des services.

Modèles de comportement

La résilience, l'intégration, la découverte et l'enregistrement sont des défis pour toute architecture d'application, mais surtout pour les microservices. Voici quelques modèles de conception architecturale de microservices courants à prendre en compte :

• Conception de la découverte. Les clients finaux qui accèdent à une application microservices utilisent la découverte côté client ou serveur pour trouver un service disponible et transmettre une demande.
• Conception de l'enregistrement. Les services utilisent l'auto-enregistrement ou l'enregistrement par un tiers pour aider à déterminer quels services sont occupés et lesquels sont disponibles.
• Conception de flux. Les architectes et les développeurs déterminent le flux de travail entre l'interface utilisateur frontale et les données back-end par le biais de modèles de conception Modèle-Vue-Contrôleur ou Modèle-Vue-VueModèle.
• Conception de Saga. Certains microservices s'appuient sur des instructions de processus et d'autres exécutent des fonctions réelles, ce qui permet une messagerie plus ordonnée et une récupération fiable.
• Conception de la fiabilité. Les développeurs autorisent plusieurs tentatives d'appel (retry) ou arrêtent la communication avec un service défaillant (circuit breaker) afin d'éviter que les erreurs ne se répercutent en cascade entre les services.
• Conception transitoire. Refondre une application monolithique en microservices, par exemple à l'aide d'un modèle de conception étrangleur, afin de segmenter une application existante en fonctions spécifiques et de créer des modules découplés. Dans certains cas, cela nécessite une refonte fondamentale de l'application existante pour s'adapter aux pratiques des microservices.

Implications pour les bases de données

La gestion des données pour les microservices n'est pas simplement une question de conception ou de technologie, mais plutôt un ensemble d'attributs ou de principes qui soutiennent la cohérence, la mise à l'échelle et la résilience des applications microservices. Les modèles de conception fondamentaux des microservices comprennent les éléments suivants :

• Une seule base de données par service. Lorsque vous associez un service à une base de données, n'affectez qu'une seule base de données au service.
• Base de données partagée. Si plusieurs services partagent une base de données, les demandes de concurrence peuvent potentiellement provoquer des conflits ; une base de données non traditionnelle, telle que NoSQL, peut réduire les conflits mais n'est pas appropriée pour de nombreux types de données.
• Conception de Saga. Créez une série de transactions et de confirmations qui permettent à la base de données de sortir d'une transaction et d'alerter le système qu'une erreur s'est produite.
• Conception basée sur les événements. Utiliser une base de données statique pour capturer et stocker les enregistrements des transactions basées sur des événements.

Modèles de messagerie

La communication entre les services peut poser des problèmes aux développeurs et aux architectes. Examinez les approches suivantes en matière de messagerie pour les microservices :

• Couplage lâche ou serré. Les services à couplage lâche réduisent les dépendances mais exigent souvent une messagerie plus fréquente et plus complète, tandis que les services à couplage étroit peuvent nécessiter moins de communication mais comportent plus de dépendances.
• Communication asynchrone ou synchrone. Un canal unique et un style requête/réponse sont courants dans les applications monolithiques, mais des canaux de communication multiples et un-à-plusieurs sont plus efficaces - voire essentiels - pour certaines applications microservices.
• Courtiers en messages. Les courtiers de messages légers, tels que Amazon Simple Notification Service, peuvent gérer et trier les messages sans attendre les réponses, et constituent une approche courante dans les applications microservices complexes. Les concepteurs ont le choix entre de nombreux outils et plateformes de messagerie pour les applications microservices.

Les étapes clés du déploiement des microservices

Deux règles générales s'appliquent à tout projet de microservices : Une architecture distribuée de microservices ne convient pas à toutes les entreprises ou à tous les types d'applications, et il n'existe pas de plan universel unique pour déployer des microservices en production. Il y a tout simplement trop de choix et d'alternatives possibles pour les développeurs et le personnel d'exploitation. Suivez ces conseils pour faciliter le déploiement des microservices et éviter les pièges les plus courants.

1. Utiliser le cloud. L'utilisation de microservices dans une infrastructure conteneurisée au sein d'un centre de données traditionnel peut s'avérer judicieuse pour certains déploiements limités. Mais l'évolutivité du cloud public, ses ressources à la demande et ses services d'orchestration natifs en font une infrastructure efficace et rentable pour les microservices basés sur des conteneurs.

2. Mettre l'accent sur la résilience. Créez des microservices comme des entités sans état qui peuvent être arrêtées, redémarrées, corrigées et redimensionnées, le tout sans perturber les autres services ou l'application dans son ensemble. Les conceptions qui autorisent des dépendances excessives, telles que des magasins de données partagés, entre les services peuvent transformer une architecture de microservices planifiée en une architecture monolithique distribuée.

3. Décentraliser les données. Chaque service individuel devrait accéder à ses propres ressources de données pour s'assurer qu'il dispose des données dont il a besoin et pour éviter les incohérences. Les services peuvent également utiliser la meilleure conception de base de données pour la tâche à accomplir, et les modifications apportées à une base de données et à un magasin de données n'affecteront pas les autres services.

4. Éliminer les silos. Les applications traditionnelles emploient souvent des groupes informatiques organisés en silos qui gèrent des parties spécifiques du déploiement de l'application. Les microservices sont mieux servis par des équipes interfonctionnelles et hautement collaboratives organisées autour de l'application microservices. Cela exige une culture flexible et favorable, telle que DevOps ou d'autres paradigmes agiles, pour trouver et résoudre les problèmes aussi rapidement et efficacement que possible.

5. Automatiser partout. Le développement d'applications modernes utilise des pipelines étroitement couplés pour construire, tester et déployer des logiciels - et les microservices sont adaptés aux pipelines. Les mêmes cadres d'automatisation qui pilotent la construction et les tests peuvent être étendus aux déploiements, ce qui accélère la mise en production de nouveaux services mis à jour, ainsi que le dépannage et la résolution des problèmes en redémarrant efficacement les services.

6. Utiliser la surveillance. Un service non surveillé ne peut pas être géré. Utilisez des outils de surveillance adaptés aux environnements de composants dynamiques pour chaque service dans les environnements microservices complexes. L'automatisation du déploiement permet de s'assurer que chaque composant est correctement connecté aux outils de surveillance, de journalisation et de reporting associés qui peuvent suivre l'état et les performances des composants.

7. Combiner et centraliser les journaux. La journalisation des microservices implique souvent des journaux séparés pour chaque service. Cependant, les données des fichiers journaux stockés dans des conteneurs individuels sont perdues lorsque le conteneur est détruit et peuvent être difficiles, voire impossibles à retrouver. Stockez les journaux dans un espace de stockage persistant. Pensez à la cohérence et à la synchronisation des données lorsque vous créez de nombreux journaux, afin qu'il soit possible de les combiner et d'obtenir une image cohérente de l'activité en cas de problème. Les outils d'analyse des journaux peuvent représenter un investissement intéressant pour les applications microservices.

8. Adopter la sécurité. Les architectures microservices sont sensibles aux questions de sécurité. Le grand nombre de services, la dépendance à l'égard des API, les fichiers journaux désagrégés et les exigences étendues en matière de communication réseau créent une grande surface d'attaque avec de multiples vecteurs d'attaque. Les meilleures pratiques en matière de sécurité des microservices sont les suivantes :

• Utiliser plusieurs couches de sécurité. Un seul outil ou cadre de sécurité est rarement suffisant pour atténuer tous les risques de sécurité. Utilisez toutes les mesures de sécurité disponibles - pare-feu, jetons, cryptage et surveillance - pour sécuriser les services et l'application dans son ensemble.
• Se concentrer sur la sécurité d'accès. Crypter toutes les données auxquelles on accède et qui sont échangées entre les services, et sécuriser les API au moyen d'une authentification et d'une autorisation appropriées qui respectent les principes du moindre privilège.
• Communiquer et collaborer. Les développeurs et le personnel d'exploitation doivent collaborer avec les groupes de sécurité pour créer une approche et un environnement de sécurité complets, un concept connu sous le nom de DevSecOps.

9. Étendre les tests. La complexité des architectures de microservices s'étend à leur test. Les tests de bout en bout des applications classiques sont loin d'être idéaux pour les microservices, c'est pourquoi il convient d'explorer d'autres options. Testez les services en tant que sous-systèmes individuels, avec clonage ou simulation pour gérer les dépendances ou les services connexes. Les tests contractuels analysent la manière dont le logiciel testé utilise une API, puis créent des tests basés sur cette utilisation. La manière dont les microservices sont déployés influe également sur les tests. Plutôt que de procéder à un déploiement ou à une mise à jour globale, chaque microservice peut être déployé, mis à jour, corrigé, testé et géré séparément des autres services. Préparez des tests rigoureux et des plans de retour en arrière solides en cas de problème. Envisagez de tester localement les microservices basés sur le cloud ; avec une isolation suffisante des services, les tests sur un service n'affecteront pas les autres.

10. Adopter des techniques de gestion des versions. L'adoption de microservices exige un contrôle de version adéquat afin de garantir que l'application globale inclut la bonne gamme de services, dont certains ou tous peuvent être mis à jour et maintenus indépendamment par différentes équipes selon des calendriers différents. Même les microservices indépendants et faiblement couplés peuvent avoir des dépendances. Un changement dans une version peut nécessiter des changements dans d'autres services, ce qui entraîne des changements de version correspondants dans d'autres services. Les techniques de versionnement des microservices comprennent les approches suivantes :

• Uniform Resource Identifier (URI) versioning.
• Versionnement de l'en-tête.
• Version sémantique.
• Version du calendrier.

Outils de déploiement et de gestion des microservices

Grâce à la synergie avec les API, les conteneurs et les processus de développement continu, les microservices peuvent utiliser bon nombre des mêmes outils pour la conception, le test, le déploiement et la gestion.

Kubernetes est la norme de facto pour l'orchestration basée sur les conteneurs, qu'une entreprise l'utilise dans ses propres environnements locaux ou par le biais d'un service basé sur le cloud. Parmi les autres outils d'orchestration figurent Docker Swarm et Compose, ainsi que HashiCorp Nomad.

Les organisations peuvent choisir parmi une large gamme d'autres outils qui couvrent les tests, le déploiement, la surveillance et la gestion des environnements microservices. Gatling, Hoverfly, Jaeger, Pact, Vagrant, VCR et WireMock sont des exemples d'outils qui couvrent les domaines des tests. Les outils de gestion des API comprennent API Fortress, Postman et Tyk. Les outils de cadres architecturaux bien adaptés aux microservices et aux API REST comprennent Goa et Kong.

La surveillance et la gestion des microservices peuvent être particulièrement difficiles, étant donné la nécessité de suivre et de maintenir chaque composant de service d'une application et leurs interactions. Ces fonctions comprennent l'observabilité, la détection des défaillances et la collecte de métriques à partir des journaux afin d'identifier les problèmes de performance et de stabilité. Sentry, Sensu et Sumo Logic sont des exemples d'outils de surveillance. Parmi les outils d'agrégation de journaux, citons Fluentd, Logstash, Ryslog et Loggly. Pour la visualisation des logs, les outils incluent Scalyr, Graylog, Kibana et Sematext.

Le maillage de services est une couche d'infrastructure dédiée à la communication entre des services individuels. Lorsque des centaines de services communiquent entre eux, il devient compliqué de déterminer quels services interagissent les uns avec les autres. Un maillage de services, tel que Linkerd et Istio, rend ces communications plus rapides, plus sûres, plus visibles et plus fiables en capturant des comportements tels que l'équilibrage de la charge en fonction de la latence ou la découverte de services. Les principaux fournisseurs de services cloud proposent des services auxiliaires pour faciliter la gestion des microservices.

Les améliorations apportées à ces technologies, ainsi qu'à d'autres telles que la surveillance et la journalisation complexes, ont réduit la complexité des microservices et stimulé leur adoption par les organisations et les équipes de développement.