Architectures microservices : plus que la somme de leurs parties ?

Il y a plusieurs façons de développer des systèmes logiciels. Au lieu de réaliser un projet dans son ensemble, il peut être judicieux de le diviser en services autonomes, c’est ce qu'on appelle des microservices. Cette notion joue non seulement un grand rôle dans le développement d'une application informatique, mais s’inscrit également dans une démarche agile. Quels sont les avantages de l'architecture microservices, comment fonctionne-t-elle et dans quels cas cette technologie est-elle déjà utilisée ?

Il n'y a pas de distinction nette entre le moment où l'on peut parler d'architecture microservices et le moment où on ne le peut pas. Et pour se perdre encore plus dans les termes, l'architecture microservices représente non seulement une technique logicielle, mais aussi et plus généralement, une manière de travailler des développeurs : comment réaliser au mieux de grands projets de programmation ? En règle générale, les projets qui utilisent la technique des microservices suivent toujours la philosophie Unix de Ken Thompson : "Ne faire qu'une chose et la faire bien". Il faut donc se concentrer sur une seule tâche pour la mener à la perfection. Cette devise sert non seulement à améliorer le travail des programmeurs, mais décrit également la fonctionnalité de chaque microservice.

Dans le domaine de la programmation, on forme des petites équipes qui ne s’occupent que d’un seul service. Dans le domaine du management de projets, on se concentre sur l’équipe et son indépendance. Au lieu d’avoir une administration centralisée, chaque équipe est entièrement responsable de son produit final, de sa création à son suivi ultérieur, en passant par sa livraison. Cette manière de travailler possède de nombreux avantages et aboutit à une architecture logicielle modulaire.

En principe, une architecture microservices est une évolution de l'architecture orientée services (SOA) : les petits services jouent également un rôle dans ce style architectural. Cependant, ils sont toujours intégrés dans un système plus grand et ne sont donc pas aussi indépendants que dans une architecture de microservices. Tout comme il n'y a pas de définition claire pour ce dernier, SOA est également un terme assez vague. Par conséquent, les transitions entre les deux modèles sont fluides.

Le développement de programmes traditionnels fonctionne selon le principe monolithique : toutes les tâches sont réalisées dans une seule et grande application. Tous les services individuels accèdent à une grande base de données et sont édités via une interface utilisateur, tous implémentés dans une seule application. L'approche microservices est basée sur des modules : chaque microservice n'est responsable que de l'exécution d'une seule tâche. Les résultats des deux approches sont aussi différents que les processus de travail.

Dans une architecture microservices, une seule équipe est responsable du développement d'un microservice. Au contraire, dans le cas des applications monolithiques, les équipes sont organisées différemment en fonction de la technologie à laquelle elles ont affaire : une équipe s'occupe des bases de données, une autre programme les services individuels et une troisième s'occupe de la conception d'une interface utilisateur. D'autres équipes sont responsables de la publication des mises à jour, des travaux de maintenance et des analyses. Toutes les équipes sont interdépendantes alors que dans une architecture microservices, les dépendances doivent être évitées autant que possible.

Dans une architecture microservices, une application de grande taille est réalisée sous forme de petits modules monofonctionnels (les microservices). Les blocs de construction eux-mêmes sont développés indépendamment les uns des autres et forment ensemble le produit global. Ce style architectural présente certains avantages.

Lors du développement d'un microservice, les équipes agissent généralement de manière totalement autonome. Un supérieur hiérarchique ne dicte pas de ligne de conduite et les différents groupes de projet n'ont pas non plus à se concerter en permanence. L'équipe se concentre uniquement sur la tâche à accomplir. L'avantage de cette façon de travailler : l'équipe de développement peut choisir la solution qui convient le mieux au microservice, et non celle qui aura été donnée par une autre équipe. Ce système est si bien perfectionné qu'il est possible d'utiliser différents langages de programmation pour différents microservices ainsi que d'utiliser ses propres bases de données ou systèmes de gestion de bases de données. Tout ceci est possible parce que chaque microservice a son propre environnement d'exécution.

Un autre avantage de l'indépendance : le système complet devient beaucoup plus robuste. Si un microservice tombe en panne, l'application complète ne s'effondre pas, seule une petite partie ne fonctionne plus. La recherche d’erreurs est également facilitée : au lieu de rechercher le code source d’une application monolithique de grande taille, seul un programme relativement petit et autonome doit être analysé.

Dans ce contexte, nous pouvons également citer le terme de livraison continue : les produits logiciels sont constamment perfectionnés. Les microservices offrent aux fabricants la possibilité de ne pas avoir à procéder à des mises à jour par grandes étapes. Au lieu de cela, les développements ultérieurs d'un microservice sont publiés directement (après une phase de test appropriée bien sûr), indépendamment des processus restants. Même des modifications mineures dans une architecture monolithique de déploiement peuvent prendre beaucoup de temps. Modifier un microservice qui n'a qu'une seule tâche à accomplir est beaucoup plus facile, car il consomme beaucoup moins de ressources.

La livraison continue s'inscrit dans une démarche agile : l'équipe qui s'occupe d'un microservice est un spécialiste absolu et peut effectuer des changements sans problème majeur. De plus, un seul changement dans le code source (une nouvelle fonctionnalité ou la correction d'un bug) est effectué par version. Cela permet également d'apporter des changements rapides et d'assurer ainsi la stabilité de l'ensemble du système sur le long terme.

À la fin, chaque pierre est assemblée à l'édifice : bien que les microservices soient tous différents dans leur structure, ils doivent finalement avoir des points de contact communs. Ceux-ci doivent être aussi simples que possible pour que la connexion ait peu d'influence sur le processus réel. C'est pourquoi la plupart des développeurs de microservices font confiance aux API REST. Grâce à des méthodes HTTP uniformes et allégées telles que GET ou POST, les différents microservices peuvent facilement communiquer entre eux et échanger les informations correspondantes.

Si un monolithe (c'est-à-dire un système fermé qui réunit tous les services) doit évoluer, il faut alors revoir le système complet. Une architecture microservices donne aux développeurs la possibilité d'évoluer très subtilement. Il vous suffit de renforcer ou modifier le service qui en a besoin. Le produit final reste ainsi beaucoup plus léger et économise des ressources. De même, il est moins coûteux d'intégrer un service complètement nouveau dans le système.

Les microservices sont complètement isolés les uns des autres et fonctionnent dans leur propre environnement. Les différentes applications ne communiquent entre elles que par le biais d'interfaces. Il y a plusieurs façons d'effectuer un tel isolement :

• Conteneurs : la façon la plus courante est de déployer des microservices sous forme de conteneurs. Ceux-ci représentent une forme de virtualisation légères par rapport aux machines virtuelles. Chaque conteneur partage le noyau du système d’exploitation avec les autres. Dans les conteneurs, les microservices fonctionnent de manière totalement autonome : tout ce dont ils ont besoin est inclus dans le conteneur.
• Machines virtuelles : il est possible de créer une machine virtuelle séparée pour chaque microservice. Ici aussi, les microservices peuvent agir isolément les uns des autres. L'inconvénient par rapport à une technologie de conteneur (comme Docker) pour les microservices est que chaque machine virtuelle nécessite son propre système d'exploitation et consomme donc beaucoup de ressources.

Dans l’absolu, il serait même concevable de mettre en place une instance de serveur physique distincte pour chaque microservice. Dans la pratique, cependant, il s'agit probablement d'un gaspillage important de ressources, c'est pourquoi la virtualisation est généralement utilisée. Ce qui est très important quelle que soit la mise en œuvre : l'isolation de chaque microservice. Il n'est pas recommandé d'exécuter plusieurs microservices sur un même serveur, ni de les regrouper dans un même conteneur. Cela pourrait entraîner des conflits entre les différentes applications.

Afin d'éviter les surcharges dans l'ensemble du système, on utilise le load balancing qui permet de répartir automatiquement la charge aux différentes instances pour éviter les pannes.

Aujourd’hui, les architectures microservices ont trouvé leur place dans les systèmes des grandes entreprises. Celles-ci ont ainsi réussi à éliminer certains problèmes ou à optimiser leurs processus. Les exemples de Netflix, Spotify et eBay montrent pourquoi de grandes entreprises avec des systèmes monolithiques établis choisissent alors de migrer vers une architecture microservices. D'autres sociétés informatiques telles que Google et Amazon travaillent également dans ce sens. Dans certains cas, ils utilisaient des systèmes modulaires avant même que le terme « architecture microservices » n’apparaisse.

Comme la plupart des entreprises, le service de Netflix était basé sur un système monolithique (à une époque où Netflix n'était pas encore un service de streaming mais envoyait uniquement des DVD par courrier). En 2008, il y a eu un bug dans une base de données qui a causé l'échec de l'ensemble du service pendant quatre jours. Il a alors été décidé de scinder l'ancien système et de le diviser en microservices. Cela a permis à l'entreprise d'effectuer les changements et de réparer les pannes beaucoup plus rapidement. Comme le système Netflix est extrêmement étendu, un programme séparé a été développé pour organiser les différents microservices entre eux : Conductor.

Conductor permet à Netflix de contrôler de manière centralisée (pause ou redémarrage) ou de mettre à jour les microservices. Au cœur du programme se trouve un service appelé Decider. Celui-ci permet de planifier automatiquement les processus et d’améliorer le workflow. D'autres programmes développés par Netflix pour travailler efficacement avec les microservices sont Mantis (traitement des flux), Dynomite (création d’environnements de bases de données) et Vizceral (visualisation du trafic).

Astuce : Netflix utilise très souvent des programmes open source et publie donc ouvertement ses propres programmes sur le net. Dans leur profil GitHub, tous les programmes mentionnés peuvent être consultés.

Un autre service de streaming, Spotify, s'appuie également sur les microservices. Le défi auquel Spotify doit faire face dans son travail est une forte concurrence. Le marché du streaming audio compte certaines des plus puissantes sociétés informatiques au monde telles qu’Amazon, Apple et Google. Dans le même temps, les développeurs doivent constamment répondre à une demande exponentielle en raison du nombre croissant d'utilisateurs et respecter certaines règles commerciales (telles que les droits de licence). Les microservices sont la solution idéale pour que Spotify puisse réagir rapidement aux nouveautés de la concurrence et publier ses propres innovations plus rapidement.

Par exemple, la fonction pour laquelle les utilisateurs reçoivent déjà des suggestions lors de la saisie d'un terme de recherche est un microservice autonome qui est pris en charge par sa propre équipe. De plus, Spotify bénéficie de la robustesse d'une architecture microservices : si un seul microservice tombe en panne, le produit entier ne devient pas inutilisable. Au total, plus de 800 microservices sont actifs chez Spotify. Le service de streaming utilise Java pour une grande partie des microservices. Cependant, cela n'a rien à voir avec le fait que les microservices ne peuvent pas être écrits dans différents langages de programmation. En fait, c’est pour faciliter le processus de travail : les développeurs passent constamment d'une équipe à l'autre, c'est donc plus facile si tout le monde utilise le même langage.

La plate-forme de vente eBay a commencé, comme la plupart des systèmes, avec une architecture monolithique : eBay avait 3,4 millions de lignes de code dans un seul fichier. A partir de là, il a été décidé de briser l’architecture monolithique et de développer des microservices (avec Java). Sur eBay également, les différents services communiquent entre eux via REST.

Le fait qu'eBay et de nombreuses autres entreprises soient passées avec succès d'une architecture monolithique à une architecture microservices prouve les avantages d'une approche moderne. Si une architecture monolithique est suffisante pour un projet en ligne avec seulement quelques utilisateurs actifs et une offre gérable, celui-ci devra passer à une architecture microservices s’il doit gérer des besoins croissants.

Même s'il y a beaucoup à dire sur la construction de systèmes basés sur des architectures microservices, l'approche moderne n’est pas nécessairement la bonne solution pour chaque entreprise ou chaque projet. La mise en place de microservices peut demander plus d’effort, en particulier pour les petits programmes informatiques qui, de toute façon, ne peuvent gérer que de quelques tâches. De plus, la création de services, mais aussi la maintenance, le développement ultérieur et la surveillance prennent beaucoup de temps. Il convient d'examiner soigneusement les résultats des microservices, en particulier lors de la surveillance des processus : d'une part, les microservices individuels sont très faciles à analyser et à mesurer. En raison de la masse des microservices, cette tâche s'accroît considérablement.

Si l'on considère ses avantages au niveau du workflow, il apparaît clairement que cela n'a pas de sens pour tous les projets, notamment lorsqu’ils sont à court terme. L'un des avantages de travailler avec les microservices est l'indépendance des équipes individuelles. Par exemple : vous voulez éviter qu'une équipe ne doive attendre les résultats de quelqu'un d'autre pour avancer. Cependant, si toute l'équipe de développement ne se compose que de quelques personnes, cette séparation des services n'a guère de sens. De plus, si vous suivez la loi de Conway, une petite équipe qui n'est pas divisée peut accomplir beaucoup de choses et peut quand même obtenir un résultat différent.

Des changements majeurs s'imposent pour les équipes plus importantes : les postes qui contrôlent le développement de manière centralisée sont de plus en plus supprimés et les équipes de développement s'organisent d’elles-mêmes. Une telle restructuration est à la fois longue et coûteuse. Ce facteur doit également être pris en compte en cas de modification éventuelle du système.

Certains partisans des architectures microservices recommandent une stratégie monolithique. Il est logique d'aborder un projet de programmation dans un style monolithique et d'en exploiter les avantages dans les premiers temps. Ce n'est que lorsque le projet a pris une ampleur suffisante que vous pouvez passer à une architecture microservices. L'architecture orientée services (SOA), constitue une bonne étape intermédiaire car elle se situe entre les deux systèmes. Ici aussi, la procédure est modulable. Les services individuels sont destinés à représenter les processus de gestion.