Les microservices, qu'est-ce que c'est ?

Les microservices désignent une approche architecturale du développement d'applications. Ils sont distribués et faiblement couplés, de sorte que les modifications apportées par une équipe n'affectent pas l'ensemble de l'application. L'avantage de ce type d'architecture est que les équipes de développement sont en mesure de créer rapidement de nouveaux composants d'applications pour répondre aux évolutions des besoins de l'entreprise.

Une architecture de microservices se différencie d'une approche monolithique classique par le fait qu'elle décompose une application pour en isoler les fonctions clés. Chacune de ces fonctions est appelée « service » et ces services peuvent être développés et déployés indépendamment les uns des autres. Ainsi, chacun peut fonctionner (ou dysfonctionner) sans affecter les autres. Cela vous aide à adopter la dimension technologique du DevOps et à simplifier l'itération et la distribution continues (CI/CD) tout en les rendant plus accessibles.

Vous vous souvenez de la dernière fois que vous avez consulté un site de vente en ligne ? Vous avez certainement utilisé la barre de recherche du site pour parcourir la liste des produits disponibles. Cette fonctionnalité de recherche constitue un service. Le site vous a sans doute également recommandé des produits associés, à partir d'une base de données sur les préférences des acheteurs. Ces recommandations représentent également un service. Vous avez ajouté un article au panier ? Vous l'avez deviné : il s'agit là aussi d'un service.

Un microservice est donc une fonction essentielle d'une application, qui est exécutée de manière totalement indépendante des autres services. Cependant, une architecture de microservices ne se résume pas à la relation entre les fonctions fondamentales d'une application : elle permet aussi de restructurer les équipes de développement et la communication entre les services pour mieux se préparer aux inévitables pannes, mais aussi aux évolutions futures et à l'intégration de nouvelles fonctions.

Comment y parvenir ? Tout simplement en adaptant les bases d'une architecture orientée services (SOA) pour déployer des microservices.

Si la décomposition d'une application en fonctions pour éviter les pièges des architectures monolithiques vous semble être un concept familier, c'est parce que l'architecture de microservices ressemble à l'architecture orientée services (SOA), une conception logicielle déjà bien établie.

Au tout début, la moindre modification apportée à une application existante nécessitait une mise à jour complète de la version, avec son propre cycle d'assurance qualité, ce qui pouvait potentiellement ralentir de nombreuses équipes en aval. Cette approche est souvent qualifiée de « monolithique », car le code source de toute l'application était structuré au sein d'une unité de déploiement unique (souvent au format .war ou .ear). Lorsque la mise à jour d'une partie de l'application provoquait des erreurs, il fallait placer l'ensemble hors ligne pour annuler les modifications et résoudre le problème. Si cette approche reste viable pour des applications légères, les entreprises en pleine croissance ne peuvent se permettre de tels temps d'arrêt.

Place alors à l'architecture orientée services, qui structure les applications en services individuels et réutilisables qui communiquent via un ESB. Au sein de cette architecture, chacun des services individuels (organisés autour d'un processus métier spécifique) suit un protocole de communication (tel que SOAP, ActiveMQ ou Apache Thrift) pour « se déplacer » dans l'ESB. Ensemble, tous ces services intégrés via un ESB constituent une application.

D'un côté, cela permet de développer, tester et paramétrer les services simultanément, sans devoir subir des cycles de développement monolithiques. De l'autre, l'ESB représente cependant un point individuel de défaillance pour l'ensemble du système. En d'autres termes, les efforts qui visaient à supprimer le « monolithe » n'ont fait qu'en créer un autre : l'ESB, qui pourrait potentiellement ralentir toute l'entreprise.

Quelle est la différence ? Les microservices peuvent communiquer entre eux, généralement de manière stateless, donc les applications développées de cette manière peuvent être plus tolérantes aux pannes et moins tributaires d'un seul ESB. Cela permet également aux équipes de développement de choisir leurs propres outils puisque les microservices peuvent communiquer à l'aide d'API indépendantes de tout langage.

Finalement, les microservices ne sont pas une idée neuve, vu leur ressemblance avec l'architecture SOA. Cependant, ils sont devenus plus viables grâce aux progrès réalisés en matière de technologies de conteneurisation. Grâce aux conteneurs Linux, vous pouvez maintenant exécuter plusieurs parties d'une application indépendamment les unes des autres, sur le même matériel, avec un niveau de contrôle bien plus élevé sur leurs éléments et cycles de vie. Avec les API et les pratiques DevOps, les microservices conteneurisés constituent la base des applications cloud-native.

Les microservices stimulent vos équipes et vos routines grâce à un développement distribué. Vous pouvez aussi développer plusieurs microservices simultanément. Ainsi, davantage de développeurs peuvent travailler en même temps, sur la même application, ce qui réduit la durée du développement.

Si votre entreprise envisage de passer à une architecture de microservices, préparez-vous à des changements, non seulement au niveau des applications, mais aussi au niveau des méthodes de travail des équipes. Ces changements culturels et structurels sont identifiés comme des défis, en partie parce que chaque équipe aura sa propre cadence de déploiement et sera responsable d'un service unique avec une clientèle spécifique. S'il ne s'agit pas des préoccupations habituelles des développeurs, elles n'en demeurent pas moins essentielles dans la mise en œuvre d'une architecture de microservices efficace.

Outre la culture et les processus, la complexité et l'efficacité sont les deux défis majeurs liés aux architectures de microservices. John Frizelle, architecte de plateformes pour Red Hat Mobile, a énoncé les huit catégories de défis suivantes dans son intervention lors du Red Hat Summit de 2017 :

1. Création : il faut prendre le temps d'identifier les dépendances entre les services. Gardez à l'esprit que la création d'une version peut nécessiter la création de plusieurs autres versions à cause de ces dépendances. Prenez également en compte les effets que les microservices peuvent avoir sur vos données.
2. Test : les tests d'intégration, tout comme les tests complets, peuvent se complexifier et prendre une importance capitale. Sachez qu'une panne d'un élément de l'architecture peut provoquer d'autres défaillances ailleurs, selon la manière dont vos services s'appuient les uns sur les autres.
3. Production de versions : lorsque vous lancez de nouvelles versions, faites attention aux problèmes de rétrocompatibilité. Pour y remédier, pensez au développement selon une logique conditionnelle, même si vous risquez d'augmenter rapidement la complexité et l'encombrement. Autre solution : gérer plusieurs versions en parallèle pour différents clients, même si la maintenance et la gestion seront plus complexes.
4. Déploiement : oui, c'est aussi un défi, du moins au début. Pour faciliter le déploiement, vous devez au préalable investir largement dans des solutions d'automatisation. En effet, les microservices deviennent vite trop complexes pour envisager un déploiement manuel. Réfléchissez à la manière dont vous allez déployer vos services, ainsi qu'à un ordre de priorité.
5. Journalisation : avec des systèmes distribués, vous avez besoin de journaux centralisés pour regrouper vos données. Sans eux, l'évolutivité devient vite impossible à gérer.
6. Surveillance : il est essentiel de disposer d'une vision centralisée du système pour identifier les sources des problèmes.
7. Débogage : il n'est pas possible de recourir au débogage à distance depuis votre environnement de développement intégré (IDE), qui n'est de toute manière pas applicable à des dizaines ou à des centaines de services. Il n'existe malheureusement pas encore de solution de débogage universelle.
8. Connectivité : réfléchissez à la découverte des services, qu'elle soit centralisée ou intégrée.