Un micro-service pour les gouverner tous

Le micro-service est un concept permettant de construire des applications modulables, facilement évolutives et intégrées dans une architecture scalable.

Qu’est-ce qu’un micro-service

Un micro-service est un concept, une bonne pratique (« pattern ») de développement logiciel, permettant de découper par module fonctionnel ou par fonctionnalité une application en petits package de code, liés entre eux par un couplage faible via une multitude de web-micro-services (Couplage en informatique). On verra par la suite que le concept n'est pas lié à une technologie en particulier, et que chaque équipe peut faire le choix technologique qui lui convient le mieux.

Microlithe plutôt que monolithe

L’approche historique consistait à développer un gros package contenant l’ensemble de l’application (un .war unique par exemple), seulement l’évolutivité de l’application impliquait de lourds tests de non régression sur l’ensemble pour être certain qu’il n’y avait pas d’effet de bord.

Le SOA a apporté de la modularité au niveau des échanges inter applications via une approche service, par l’intermédiaire d’ESB ou équivalent. Le déploiement des fonctions métiers se fait avec plus de souplesse et de modularité qu’une approche point à point. 

L’approche micro-services module encore plus les applications, le package ne contient plus qu’un module ou fonctionnalité, disposant de sa base de données ou de son schéma de base de données dont il est maitre et en a l’accès exclusif. Les autres modules souhaitant accéder à des données d’un autre module devront passer par un de ses services pour y parvenir.

L’approche monolithe ou « gros package » oblige un exploitant ou un outil d’industrialisation des déploiements à déployer une nouvelle instance de l’ensemble du package en cas de pic de charge.

Aussi, l'approche monolithe, comme le SOA, conduit à la coupure de tous les modules et des services en cas de chute de la ou des instances déployées (bug, pic de charge, incident…), ce qui n'offre que peu de possibilité d'avoir un fonctionnement dégradé partiel d’une application.

Lors d’un pic de charge, d’un module en particulier, il suffira de déployer une nouvelle instance du package/module concerné, et de le lier aux autres par le biais d’un répartiteur de charge ou d’un frontal pointant vers la nouvelle instance.

Une problématique d’organisation et de rigueur plutôt que technique

La conception d’une application en micro services intervient dans la plupart des cas lors de la mise en place initiale, ou lors des évolutions majeures de l’application.

Si les micro-services nécessitent une mise en œuvre particulière faisant appel à des méthodes de gestion/déploiement spécialisées, la réalisation d’un projet micro-services n’est pas liée à une technologie particulière. Des frameworks micro-services pourront émerger, embarquant une surcouche gérant la métrologie, la supervision ou toute fonctionnalité utile en complément du code métier embarqué.

La plus grosse complexité et la force des micro-services, passe par une rigueur inculquée aux équipes de développement, ce qui permettra, dans le cas où les concepts liés aux micro-services sont bien appliqués, d’avoir un code modulable, scalable et plus facilement évolutif/maintenable.

En amont de la réalisation, un travail de découpage par module ou fonctionnalité doit être fait, afin de répartir le travail entre les équipes de développements, de définir la granularité des packages déployés mais surtout de dessiner l’ébauche macro des échanges entre services et éventuels contrats d’interface de ces derniers.

L'avantage majeur de cette organisation est l'indépendance des équipes les unes des autres (et de leurs modules respectifs). A contrario, l'inconvénient principal est la rigueur à respecter en amont et pendant les développements. La gouvernance des modules doit être définie en amont et appliquée tout au long de la réalisation.

L’évolution des modules est faite de manière indépendante grâce aux versionning des services composant les modules et il est nécessaire de penser une nouvelle façon de les gouverner.

Comment les gouverner

Le concept des micro-services implique une forte maintenabilité et une évolutivité des modules de manière indépendante. Il faut que le cycle d’évolution des modules suive une rigueur stricte.

Le principe de versionning doit être scrupuleusement appliqué afin de ne pas provoquer d’effet de bord sur les services environnant, la version d’un module ou d’un service devra être incrémentée à chaque changement du contrat d’interface du module ou à chaque grosse mise à jour fonctionnelle majeure.

A chaque étape de l’évolution ou de la création, un contrat d’interfaces est fourni par l’équipe du module contenant la description de chaque service utilisé (description du service, signatures, données de tests, exemples), à destination des autres équipes souhaitant s’intégrer.

Il sera possible d’avoir deux versions d’un même module en fonctionnement, au cas où, une application ne saurait pas fonctionner avec la version la plus récente, ce qui permettrait de laisser plus de temps à l’équipe pour mettre à jour le module.

Afin de gérer ce cycle de vie des services de manière centralisée, des plateformes API Management sur le marché permettent d’adresser des besoins, de documentation, de versionning, de reporting de métriques et de répartition de charge.

Comment les intégrer dans un existant

Les échanges avec un écosystème non micro-services se produisent de la même manière que sans micro-services :

• L’écosystème ne sait pas gérer de web-services (en émettre ou en recevoir), des échanges standards pourront se faire par un échange de fichier standard, par un système de file de message ou via une couche intermédiaire API/ESB
• L’écosystème sait gérer des web-services, il suffit de coordonner les responsables d’urbanisation des deux mondes afin d’échanger les contrats d’interfaces permettant d’utiliser les web-services

Cependant, les échanges de fichiers se font de plus en plus rares, à part pour les applications manipulant de gros fichiers, comme des médias vidéos ; les web-services sont à favoriser dans la majorité des cas car plus « temps-réel », plus adapté aux cas d’usage digitaux.

Que l’existant soit constitué de SOA ou non, il sera toujours possible de faire communiquer les deux écosystèmes, comme cela serait possible avec une application non micro-services, par le biais d’appel web-service/API ou bien échange de fichiers. Il n'est pas toujours possible de concevoir une application isolée du legacy, il ne faut pas s'interdire d'utiliser les services ou les interfaces mises à dispositions par les applications du SI, même si ces dernières ne sont pas conçues en micro-services.

Comment les industrialiser / les outiller

Des outils permettent de gérer le déploiement et l’orchestration des packages, tels que Docker et Kubernetes qu’on ne présente plus, ce qui permet de déployer à la volée une instance du module (qu’il soit constitué de micro-services ou non) sans se soucier de la couche OS et matériel ; tout en bénéficiant de l’isolation de Docker.

Dans le cas du package micro-services et de ses nombreux web-services, la problématique repose sur le fait de faire connaitre le nouveau package déployé aux autres packages déjà déployés, il faut pour cela un système de répartition de charge flexible.

Par exemple, l’API Management permettrait de répondre à ce besoin, grâce à sa fonctionnalité de passerelle API (intégrée dans la plupart des solutions API management du marché), chaque service appellerait la plateforme API management, comme intermédiaire, pour contacter le web-micro-service cible. En cas d’ajout d’instance d’un module micro-services, l’API management serait notifiée et ajouterait la nouvelle instance déployée à sa liste des cibles, pour agir en tant que répartiteur de charge.

L’API management permettrait aussi de fournir une gouvernance des services et de versionner les services afin de faire évoluer les modules de manière indépendante, ce que n’offrirait pas nativement un répartiteur de charge.

Comme abordé précédemment, les micro-services ne sont pas liés à une technologie particulière dans le sens où Spring permettrait de faire des micro-services, aussi bien qu’un framework micro-services dédié. 

L’avantage d’être technico-agnostique est qu’il est possible pour une entreprise souhaitant introduire des micro-services dans ses applications, d’enrichir un socle micro-services évolutif (utilisé par tous les modules micro-services), de fonctionnalités d’exploitation ou de surveillance par exemple, on pourrait imaginer un service qui notifierait un système de déploiement en cas de temps de réponse trop long, ce qui provoquerait l’ajout d’une nouvelle instance pour équilibrer la charge. Ce qui apporte une liberté d’évolution et de personnalisation sans limite, sans modifier le contenu des modules utilisant le socle.

Pour conclure, le micro-service est un concept permettant d’organiser les développements par modules fonctionnels, afin de rendre indépendant chaque module pour ainsi faciliter leur utilisation, leur gouvernance et leur évolutivité/maintenabilité. De plus, une industrialisation est possible pour fournir de la surveillance (métriques de performances et API) et de l’auto-dimensionnement.

Comme décrit dans cet article, il se dégage de grands principes qui justifient l’intégration de micro-service dans son SI. Au cas par cas, il reste néanmoins à étudier la stratégie la plus adaptée. Ceci doit faire l’objet d’un approfondissement.