Ar­chi­tec­tures mi­cro­ser­vices : plus que la somme de leurs parties ?

Il y a plusieurs façons de dé­ve­lop­per 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 mi­cro­ser­vices. Cette notion joue non seulement un grand rôle dans le dé­ve­lop­pe­ment d'une ap­pli­ca­tion in­for­ma­tique, mais s’inscrit également dans une démarche agile. Quels sont les avantages de l'ar­chi­tec­ture mi­cro­ser­vices, comment fonc­tionne-t-elle et dans quels cas cette tech­no­lo­gie est-elle déjà utilisée ?

Il n'y a pas de dis­tinc­tion nette entre le moment où l'on peut parler d'ar­chi­tec­ture mi­cro­ser­vices et le moment où on ne le peut pas. Et pour se perdre encore plus dans les termes, l'ar­chi­tec­ture mi­cro­ser­vices re­pré­sente non seulement une technique lo­gi­cielle, mais aussi et plus gé­né­ra­le­ment, une manière de tra­vail­ler des dé­ve­lop­peurs : comment réaliser au mieux de grands projets de pro­gram­ma­tion ? En règle générale, les projets qui utilisent la technique des mi­cro­ser­vices suivent toujours la phi­lo­so­phie Unix de Ken Thompson : "Ne faire qu'une chose et la faire bien". Il faut donc se con­cen­trer sur une seule tâche pour la mener à la per­fec­tion. Cette devise sert non seulement à améliorer le travail des pro­gram­meurs, mais décrit également la fonc­tion­na­lité de chaque mi­cro­ser­vice.

Dans le domaine de la pro­gram­ma­tion, on forme des petites équipes qui ne s’occupent que d’un seul service. Dans le domaine du ma­na­ge­ment de projets, on se concentre sur l’équipe et son in­dé­pen­dance. Au lieu d’avoir une ad­mi­nis­tra­tion cen­tra­li­sée, chaque équipe est en­tiè­re­ment res­pon­sable de son produit final, de sa création à son suivi ultérieur, en passant par sa livraison. Cette manière de tra­vail­ler possède de nombreux avantages et aboutit à une ar­chi­tec­ture lo­gi­cielle modulaire.

En principe, une ar­chi­tec­ture mi­cro­ser­vices est une évolution de l'ar­chi­tec­ture orientée services (SOA) : les petits services jouent également un rôle dans ce style ar­chi­tec­tu­ral. Cependant, ils sont toujours intégrés dans un système plus grand et ne sont donc pas aussi in­dé­pen­dants que dans une ar­chi­tec­ture de mi­cro­ser­vices. Tout comme il n'y a pas de dé­fi­ni­tion claire pour ce dernier, SOA est également un terme assez vague. Par con­sé­quent, les tran­si­tions entre les deux modèles sont fluides.

Le dé­ve­lop­pe­ment de pro­grammes tra­di­tion­nels fonc­tionne selon le principe mo­no­li­thique : toutes les tâches sont réalisées dans une seule et grande ap­pli­ca­tion. Tous les services in­di­vi­duels accèdent à une grande base de données et sont édités via une interface uti­li­sa­teur, tous im­plé­men­tés dans une seule ap­pli­ca­tion. L'ap­proche mi­cro­ser­vices est basée sur des modules : chaque mi­cro­ser­vice n'est res­pon­sable que de l'exé­cu­tion d'une seule tâche. Les résultats des deux approches sont aussi dif­fé­rents que les processus de travail.

Dans une ar­chi­tec­ture mi­cro­ser­vices, une seule équipe est res­pon­sable du dé­ve­lop­pe­ment d'un mi­cro­ser­vice. Au contraire, dans le cas des ap­pli­ca­tions mo­no­li­thiques, les équipes sont or­ga­ni­sées dif­fé­rem­ment en fonction de la tech­no­lo­gie à laquelle elles ont affaire : une équipe s'occupe des bases de données, une autre programme les services in­di­vi­duels et une troisième s'occupe de la con­cep­tion d'une interface uti­li­sa­teur. D'autres équipes sont res­pon­sables de la pu­bli­ca­tion des mises à jour, des travaux de main­te­nance et des analyses. Toutes les équipes sont in­ter­dé­pen­dantes alors que dans une ar­chi­tec­ture mi­cro­ser­vices, les dé­pen­dances doivent être évitées autant que possible.

Dans une ar­chi­tec­ture mi­cro­ser­vices, une ap­pli­ca­tion de grande taille est réalisée sous forme de petits modules mo­no­fonc­tion­nels (les mi­cro­ser­vices). Les blocs de cons­truc­tion eux-mêmes sont dé­ve­lop­pés in­dé­pen­dam­ment les uns des autres et forment ensemble le produit global. Ce style ar­chi­tec­tu­ral présente certains avantages.

Lors du dé­ve­lop­pe­ment d'un mi­cro­ser­vice, les équipes agissent gé­né­ra­le­ment de manière to­ta­le­ment autonome. Un supérieur hié­rar­chique ne dicte pas de ligne de conduite et les dif­fé­rents groupes de projet n'ont pas non plus à se concerter en per­ma­nence. L'équipe se concentre uni­que­ment sur la tâche à accomplir. L'avan­tage de cette façon de tra­vail­ler : l'équipe de dé­ve­lop­pe­ment peut choisir la solution qui convient le mieux au mi­cro­ser­vice, et non celle qui aura été donnée par une autre équipe. Ce système est si bien per­fec­tionné qu'il est possible d'uti­li­ser dif­fé­rents langages de pro­gram­ma­tion pour dif­fé­rents mi­cro­ser­vices ainsi que d'uti­li­ser ses propres bases de données ou systèmes de gestion de bases de données. Tout ceci est possible parce que chaque mi­cro­ser­vice a son propre en­vi­ron­ne­ment d'exé­cu­tion.

Un autre avantage de l'in­dé­pen­dance : le système complet devient beaucoup plus robuste. Si un mi­cro­ser­vice tombe en panne, l'ap­pli­ca­tion complète ne s'ef­fondre pas, seule une petite partie ne fonc­tionne plus. La recherche d’erreurs est également facilitée : au lieu de re­cher­cher le code source d’une ap­pli­ca­tion mo­no­li­thique de grande taille, seul un programme re­la­ti­ve­ment petit et autonome doit être analysé.

Dans ce contexte, nous pouvons également citer le terme de livraison continue : les produits logiciels sont cons­tam­ment per­fec­tion­nés. Les mi­cro­ser­vices offrent aux fa­bri­cants la pos­si­bi­lité de ne pas avoir à procéder à des mises à jour par grandes étapes. Au lieu de cela, les dé­ve­lop­pe­ments ul­té­rieurs d'un mi­cro­ser­vice sont publiés di­rec­te­ment (après une phase de test ap­pro­priée bien sûr), in­dé­pen­dam­ment des processus restants. Même des mo­di­fi­ca­tions mineures dans une ar­chi­tec­ture mo­no­li­thique de dé­ploie­ment peuvent prendre beaucoup de temps. Modifier un mi­cro­ser­vice qui n'a qu'une seule tâche à accomplir est beaucoup plus facile, car il consomme beaucoup moins de res­sources.

La livraison continue s'inscrit dans une démarche agile : l'équipe qui s'occupe d'un mi­cro­ser­vice est un spé­cia­liste absolu et peut effectuer des chan­ge­ments sans problème majeur. De plus, un seul chan­ge­ment dans le code source (une nouvelle fonc­tion­na­lité ou la cor­rec­tion d'un bug) est effectué par version. Cela permet également d'ap­por­ter des chan­ge­ments rapides et d'assurer ainsi la stabilité de l'en­semble du système sur le long terme.

À la fin, chaque pierre est assemblée à l'édifice : bien que les mi­cro­ser­vices soient tous dif­fé­rents dans leur structure, ils doivent fi­na­le­ment avoir des points de contact communs. Ceux-ci doivent être aussi simples que possible pour que la connexion ait peu d'in­fluence sur le processus réel. C'est pourquoi la plupart des dé­ve­lop­peurs de mi­cro­ser­vices font confiance aux API REST. Grâce à des méthodes HTTP uniformes et allégées telles que GET ou POST, les dif­fé­rents mi­cro­ser­vices peuvent fa­ci­le­ment com­mu­ni­quer entre eux et échanger les in­for­ma­tions cor­res­pon­dantes.

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 ar­chi­tec­ture mi­cro­ser­vices donne aux dé­ve­lop­peurs la pos­si­bi­lité d'évoluer très sub­ti­le­ment. 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 res­sources. De même, il est moins coûteux d'in­té­grer un service com­plè­te­ment nouveau dans le système.

Les mi­cro­ser­vices sont com­plè­te­ment isolés les uns des autres et fonc­tion­nent dans leur propre en­vi­ron­ne­ment. Les dif­fé­rentes ap­pli­ca­tions ne com­mu­ni­quent entre elles que par le biais d'in­ter­faces. Il y a plusieurs façons d'ef­fec­tuer un tel isolement :

• Con­te­neurs : la façon la plus courante est de déployer des mi­cro­ser­vices sous forme de con­te­neurs. Ceux-ci re­pré­sen­tent une forme de vir­tua­li­sa­tion légères par rapport aux machines vir­tuelles. Chaque conteneur partage le noyau du système d’ex­ploi­ta­tion avec les autres. Dans les con­te­neurs, les mi­cro­ser­vices fonc­tion­nent de manière to­ta­le­ment autonome : tout ce dont ils ont besoin est inclus dans le conteneur.
• Machines vir­tuelles : il est possible de créer une machine virtuelle séparée pour chaque mi­cro­ser­vice. Ici aussi, les mi­cro­ser­vices peuvent agir isolément les uns des autres. L'in­con­vé­nient par rapport à une tech­no­lo­gie de conteneur (comme Docker) pour les mi­cro­ser­vices est que chaque machine virtuelle nécessite son propre système d'ex­ploi­ta­tion et consomme donc beaucoup de res­sources.

Dans l’absolu, il serait même con­ce­vable de mettre en place une instance de serveur physique distincte pour chaque mi­cro­ser­vice. Dans la pratique, cependant, il s'agit pro­ba­ble­ment d'un gas­pil­lage important de res­sources, c'est pourquoi la vir­tua­li­sa­tion est gé­né­ra­le­ment utilisée. Ce qui est très important quelle que soit la mise en œuvre : l'iso­la­tion de chaque mi­cro­ser­vice. Il n'est pas re­com­mandé d'exé­cu­ter plusieurs mi­cro­ser­vices sur un même serveur, ni de les regrouper dans un même conteneur. Cela pourrait entraîner des conflits entre les dif­fé­rentes ap­pli­ca­tions.

Afin d'éviter les sur­charges dans l'en­semble du système, on utilise le load balancing qui permet de répartir au­to­ma­ti­que­ment la charge aux dif­fé­rentes instances pour éviter les pannes.

Aujourd’hui, les ar­chi­tec­tures mi­cro­ser­vices ont trouvé leur place dans les systèmes des grandes en­tre­prises. 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 en­tre­prises avec des systèmes mo­no­li­thiques établis choi­sis­sent alors de migrer vers une ar­chi­tec­ture mi­cro­ser­vices. D'autres sociétés in­for­ma­tiques telles que Google et Amazon tra­vail­lent également dans ce sens. Dans certains cas, ils uti­li­saient des systèmes mo­du­laires avant même que le terme « ar­chi­tec­ture mi­cro­ser­vices » n’ap­pa­raisse.

Comme la plupart des en­tre­prises, le service de Netflix était basé sur un système mo­no­li­thique (à une époque où Netflix n'était pas encore un service de streaming mais envoyait uni­que­ment 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'en­semble du service pendant quatre jours. Il a alors été décidé de scinder l'ancien système et de le diviser en mi­cro­ser­vices. Cela a permis à l'en­tre­prise d'ef­fec­tuer les chan­ge­ments et de réparer les pannes beaucoup plus ra­pi­de­ment. Comme le système Netflix est ex­trê­me­ment étendu, un programme séparé a été développé pour organiser les dif­fé­rents mi­cro­ser­vices entre eux : Conductor.

Conductor permet à Netflix de contrôler de manière cen­tra­li­sée (pause ou re­dé­mar­rage) ou de mettre à jour les mi­cro­ser­vices. Au cœur du programme se trouve un service appelé Decider. Celui-ci permet de planifier au­to­ma­ti­que­ment les processus et d’améliorer le workflow. D'autres pro­grammes dé­ve­lop­pés par Netflix pour tra­vail­ler ef­fi­ca­ce­ment avec les mi­cro­ser­vices sont Mantis (trai­te­ment des flux), Dynomite (création d’en­vi­ron­ne­ments de bases de données) et Vizceral (vi­sua­li­sa­tion du trafic).

Astuce : Netflix utilise très souvent des pro­grammes open source et publie donc ou­ver­te­ment ses propres pro­grammes sur le net. Dans leur profil GitHub, tous les pro­grammes men­tion­nés peuvent être consultés.

Un autre service de streaming, Spotify, s'appuie également sur les mi­cro­ser­vices. Le défi auquel Spotify doit faire face dans son travail est une forte con­cur­rence. Le marché du streaming audio compte certaines des plus puis­santes sociétés in­for­ma­tiques au monde telles qu’Amazon, Apple et Google. Dans le même temps, les dé­ve­lop­peurs doivent cons­tam­ment répondre à une demande ex­po­nen­tielle en raison du nombre croissant d'uti­li­sa­teurs et respecter certaines règles com­mer­ciales (telles que les droits de licence). Les mi­cro­ser­vices sont la solution idéale pour que Spotify puisse réagir ra­pi­de­ment aux nou­veau­tés de la con­cur­rence et publier ses propres in­no­va­tions plus ra­pi­de­ment.

Par exemple, la fonction pour laquelle les uti­li­sa­teurs reçoivent déjà des sug­ges­tions lors de la saisie d'un terme de recherche est un mi­cro­ser­vice autonome qui est pris en charge par sa propre équipe. De plus, Spotify bénéficie de la ro­bus­tesse d'une ar­chi­tec­ture mi­cro­ser­vices : si un seul mi­cro­ser­vice tombe en panne, le produit entier ne devient pas inu­ti­li­sable. Au total, plus de 800 mi­cro­ser­vices sont actifs chez Spotify. Le service de streaming utilise Java pour une grande partie des mi­cro­ser­vices. Cependant, cela n'a rien à voir avec le fait que les mi­cro­ser­vices ne peuvent pas être écrits dans dif­fé­rents langages de pro­gram­ma­tion. En fait, c’est pour faciliter le processus de travail : les dé­ve­lop­peurs passent cons­tam­ment 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 ar­chi­tec­ture mo­no­li­thique : 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’ar­chi­tec­ture mo­no­li­thique et de dé­ve­lop­per des mi­cro­ser­vices (avec Java). Sur eBay également, les dif­fé­rents services com­mu­ni­quent entre eux via REST.

Le fait qu'eBay et de nom­breuses autres en­tre­prises soient passées avec succès d'une ar­chi­tec­ture mo­no­li­thique à une ar­chi­tec­ture mi­cro­ser­vices prouve les avantages d'une approche moderne. Si une ar­chi­tec­ture mo­no­li­thique est suf­fi­sante pour un projet en ligne avec seulement quelques uti­li­sa­teurs actifs et une offre gérable, celui-ci devra passer à une ar­chi­tec­ture mi­cro­ser­vices s’il doit gérer des besoins crois­sants.

Même s'il y a beaucoup à dire sur la cons­truc­tion de systèmes basés sur des ar­chi­tec­tures mi­cro­ser­vices, l'ap­proche moderne n’est pas né­ces­sai­re­ment la bonne solution pour chaque en­tre­prise ou chaque projet. La mise en place de mi­cro­ser­vices peut demander plus d’effort, en par­ti­cu­lier pour les petits pro­grammes in­for­ma­tiques qui, de toute façon, ne peuvent gérer que de quelques tâches. De plus, la création de services, mais aussi la main­te­nance, le dé­ve­lop­pe­ment ultérieur et la sur­veil­lance prennent beaucoup de temps. Il convient d'exa­mi­ner soig­neu­se­ment les résultats des mi­cro­ser­vices, en par­ti­cu­lier lors de la sur­veil­lance des processus : d'une part, les mi­cro­ser­vices in­di­vi­duels sont très faciles à analyser et à mesurer. En raison de la masse des mi­cro­ser­vices, cette tâche s'accroît con­si­dé­ra­ble­ment.

Si l'on considère ses avantages au niveau du workflow, il apparaît clai­re­ment que cela n'a pas de sens pour tous les projets, notamment lorsqu’ils sont à court terme. L'un des avantages de tra­vail­ler avec les mi­cro­ser­vices est l'in­dé­pen­dance des équipes in­di­vi­duelles. 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é­ve­lop­pe­ment ne se compose que de quelques personnes, cette sé­pa­ra­tion 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 chan­ge­ments majeurs s'im­po­sent pour les équipes plus im­por­tantes : les postes qui con­trô­lent le dé­ve­lop­pe­ment de manière cen­tra­li­sée sont de plus en plus supprimés et les équipes de dé­ve­lop­pe­ment s'or­ga­ni­sent d’elles-mêmes. Une telle res­truc­tu­ra­tion est à la fois longue et coûteuse. Ce facteur doit également être pris en compte en cas de mo­di­fi­ca­tion éven­tuelle du système.

Certains partisans des ar­chi­tec­tures mi­cro­ser­vices re­com­man­dent une stratégie mo­no­li­thique. Il est logique d'aborder un projet de pro­gram­ma­tion dans un style mo­no­li­thique et d'en exploiter les avantages dans les premiers temps. Ce n'est que lorsque le projet a pris une ampleur suf­fi­sante que vous pouvez passer à une ar­chi­tec­ture mi­cro­ser­vices. L'ar­chi­tec­ture orientée services (SOA), constitue une bonne étape in­ter­mé­diaire car elle se situe entre les deux systèmes. Ici aussi, la procédure est modulable. Les services in­di­vi­duels sont destinés à re­pré­sen­ter les processus de gestion.