Introduction aux microservices
Si vous travaillez de près ou de loin dans l’informatique, vous ne serez sans doute pas passé à côté des nombreuses discussions récentes autour des microservices. Chez Neoxia, nous avons pu creuser ce sujet et travailler à maintes reprises sur l’implémentation de ces nouvelles architectures pour nos clients. Cet article est le premier d’une série, rédigée par Alexandre Brun et moi-même, dont le contenu s’appuie sur ces expériences et missions.
Dans ce premier volet, nous commençons par le commencement, en posant les bases de ce qu’est une architecture en microservices. Puis dans les articles à venir, nous parlerons des prérequis techniques et métiers nécessaires à la mise en place d’un tel système pour vos projets informatiques, mais également des thèmes plus poussés allant de l’outillage jusqu’aux différents patterns en passant par le stockage des données ou la communication inter-services. Restez attentifs à notre fil Medium ou à notre page LinkedIn pour ne rien manquer !
La genèse des microservices
La méthode de conception par microservices est actuellement à l’honneur dans le monde de l’informatique, de la même manière que l’agilité ou les APIs. En effet, cette méthode de conception est devenue un standard chez les développeurs, principalement parce qu’elle permet la livraison d’applications ou de services complexes pour les entreprises, et ce de façon beaucoup plus évolutive et modulaire que les méthodes traditionnellement utilisées.
Au début de l’histoire du développement informatique grand public, les logiciels étaient conçus afin que la logique métier se situe au coeur de l’application, et que celle-ci soit implémentée dans différents modules autour d’une seule base de données. C’est ce que l’on nomme encore aujourd’hui des logiciels de type monolithique, dans le sens ou ils ne forment qu’un seul bloc.
Puis, la complexité croissante des applications a conduit au découpage des développements entre back end (logique métier et accès à la donnée) et front end (interface et expérience utilisateur), afin de permettre une plus grande évolutivité répondant aux nouveaux besoins des utilisateur (usages sur mobile, tablette, etc.). Cette organisation conservait toutefois la logique métier au sein d’un bloc unique.
Ces dernières années, l’architecture par microservices est apparue pour répondre aux principales carences des monolithes, à savoir la difficulté d’implémenter de nouvelles fonctionnalités rapidement. Notre expérience nous a enseigné que ce ne sont pas les logiques métiers qui bloquent la mise en place de nouvelles fonctionnalités, mais bien la complexité des systèmes applicatifs qui freine les développements. En effet, au cours de nos différentes missions, nos clients arrivent très bien à matérialiser leurs besoins de nouvelles fonctionnalités métiers. Mais la difficulté réside dans l’incapacité à retranscrire cette fonctionnalité dans leur logiciel car ce dernier n’a pas été conçu pour être évolutif.
C’est dans cet objectif que le modèle d’architecture en microservices cherche à diviser un problème en un sous-ensemble de composants, qui interagissent plus ou moins directement et fréquemment les uns avec les autres. Cette façon de diviser pour mieux régner n’est pas nouvelle dans le domaine de l’informatique : d’aucuns se souviendront de la SOA (service oriented architecture), très populaire dans les années 2000. Les principes fondamentaux de ces deux architectures sont très proches, et à bien des égards on peut donc considérer les microservices comme une version contemporaine de la SOA, adaptée aux enjeux de l’Internet des années 2020.
Un microservice, c’est quoi alors ?
Pour le dire simplement, les microservices sont une pratique de développement qui consiste à produire des applications conséquentes composées de plusieurs petits services modulables. Chaque module est dédié à un domaine très précis, et est responsable de tout ce qui a trait à cette tâche. Il met à disposition une interface qui permet aux autres services de communiquer avec lui.
Cette architecture apporte plusieurs avantages, notamment la scalabilité, la maintenabilité, la réutilisabilité et la résilience. Elle réduit également le time to market (le temps nécessaire entre la conception et livraison d’une application), et apporte de la stabilité au système dans son ensemble. Au lieu d’avoir à gérer un monolithe lourd, complexe, et difficile à maintenir, il s’agit au contraire de gérer plusieurs mini-applications légères et simples, qui ont chacune un nombre très restreint de fonctionnalités, et qui les exécutent au mieux.
Le découpage des microservices est fortement inspiré des principes de DDD (Domain-Driven Design). Le DDD permet de séparer des fonctionnalités par domaine métier, en représentant les différents modules et entités directement dans son code. Les microservices passent au niveau supérieur en divisant l’application elle-même dans ces contextes bornés. Ainsi, on peut s’assurer que les données liés à un domaine restent isolées et que seule une API permet d’y accéder.
Donc, pour faire simple, un microservice est une application isolée et autonome dont le but est de répondre à un besoin métier précis dans des bornes bien délimitées. Il doit être “petit” et facile à remplacer, scaler, maintenir, et à modifier. Il faut qu’il soit possible de le déployer seul dans un système qu’il ne doit pas connaître. Toutefois, il doit être capable de partager son statut de santé, et il devrait avoir un moyen de récupérer ce dont il a besoin du système, comme des dépendances, des paramètres, des adresses IPs, etc. Enfin, il doit fournir une API qui donne accès à ses fonctionnalités et ses données.
Quelles sont leurs spécificités techniques ?
Il va de soi qu’une telle architecture implique nombre d’éléments techniques à mettre en place pour respecter cette définition. Chaque microservice peut avoir ses propres spécificités, et la mise en place de l’ensemble du système requiert une réflexion poussée et des compétences précises pour l’implémentation.
Il existe toutefois beaucoup d’outils pouvant faciliter cette tâche. Avant de nous plonger dans ces détails dans nos futurs articles, nous nous contenterons ici de vous parler de l’essentiel des concepts à connaître.
Bases de données
Les bases de données sont au coeur de beaucoup, pour ne pas dire la quasi-totalité des applications. Qu’elles soient relationnelles, clé-valeur, en graphe ou sans schéma, elles sont la solution principale pour stocker des données et y accéder. Quand on conçoit une architecture en microservices, en apparence un choix s’offre à nous : créer une base de données centralisée, ou au contraire laisser chaque microservice gérer ses données ?
En vérité, selon nous, ce choix n’en n’est pas un : une bonne architecture privilégiera toujours la mise en place d’une base de données par microservices. Cette solution apporte un nombre d’avantages conséquents. Car une fois isolées, les données sont :
- À l’abri des corruptions par des éléments extérieurs ;
- Faciles à modifier, tout comme leur schéma ;
- Inaccessibles en direct, en lecture comme en écriture ;
- Potentiellement stockées par des technologies différentes dans chaque microservice, correspondant au mieux au besoin.
Tous ces avantages renforcent l’indépendance de chaque microservice, et les impacts des changements n’en deviennent que plus faciles à estimer.
Environnement (infrastructure, industrialisation, monitoring)
Pour bien mettre en place des microservices, il faut configurer tout un panel d’outils pour les déployer, les héberger et les surveiller. Ces éléments sont tous nécessaires à une telle architecture, et doivent être préparés avant même le début du développement des microservices eux-mêmes.
Pour les déployer, une excellente infrastructure d’intégration et de déploiement continus est nécessaire. La mise en place de cet outil avant le début des développements est bien sûr capitale : un faux pas peut entraîner des retards conséquents et bloquer le déploiement des microservices. Il vaut donc mieux traiter ce sujet en priorité, pour s’assurer que la solution choisie soit la meilleure possible.
Le deuxième point à anticiper est celui de l’hébergement des microservices. Là encore, plusieurs choix sont possibles, mais il faut garder à l’esprit que l’hébergement doit être scalable à l’infini, et doit pouvoir gérer potentiellement des dizaines de mini-applications. C’est pourquoi nous privilégions en général deux solutions : des FaaS (Functions as a Service) ou des conteneurs Docker orchestrés par Kubernetes.
Une fois l’architecture et le déploiement en place, les développements peuvent commencer. Mais pas question de livrer les microservices en production avant qu’un monitoring fiable soit en place ! Le strict minimum ? Des logs, des métriques et des endpoints de santé dans chaque microservice, pour pouvoir contrôler son statut à tout instant.
Communications
Une autre pierre angulaire de l’architecture en microservices est la communication, interne au système, entre les services, ou vers l’extérieur. Beaucoup de choses sont à prendre en compte pour le choix de la technologie de communication : versioning, sécurité, latence… Deux solutions ressortent le plus souvent :
- gRPC & Protobuff. Il s’agit ici d’un framework de type Remote Procedure Call développé initialement par Google. Il permet notamment la mise en place d’une structure de données à la fois stricte et évolutive. Son utilisation permet de réduire la latence et ainsi d’augmenter les performances des services.
- HTTP. On ne présente plus l’HyperText Transfer Protocol car il est aujourd’hui implémenté dans tous les navigateurs par défaut. En soit, l’utilisation de HTTP présente des différences au niveau du code (il faut par exemple manuellement déclarer les routes et parser le JSON), mais présente également des performances plus faibles pour moins de fonctionnalités.
Il est parfaitement possible d’implémenter ces deux solutions et utiliser, par exemple, gRPC pour les communications entre services, et HTTP pour les communications vers l’extérieur. Toutefois, cette implémentation peut prendre du temps, et souvent HTTP fera très bien l’affaire. Ce type de décision n’est également pas immuable, et pourra être assez facilement modifiée après-coup, si nécessaire.
À venir
Il est nécessaire de rappeler que les microservices ne sont pas une solution miracle. Leur implémentation peut coûter cher et peut prendre du temps. Toutefois, une telle architecture, lorsqu’elle est réussie, apporte une foule d’avantages qui résoudront de nombreux problèmes, et garantiront une maintenabilité et une évolutivité que les monolithes ne peuvent se vanter d’avoir.
C’est pourquoi cet article n’est qu’un début ! Nous vous avons présenté ici les microservices en général, mais pour véritablement entrer dans le vif du sujet, il nous faudra aborder tous les aspects techniques qu’implique ce type d’architecture. Entre autres, nous parlerons plus en détails d’industrialisation, de domain-driven design, d’architecture d’entreprise, des enjeux humains… et bien d’autres sujets !
N’hésitez pas à partager vos retours d’expériences ou vos questions, remarques ou suggestions dans les commentaires, nous nous ferons une joie d’échanger avec vous.
