Microservices

Il n'est plus un projet digital où l'architecte ne propose de faire du microservice... et il a presque toujours raison !

Helas, hélas, la plupart du temps, il ne sait pas ce qu'est vraiment du microservice.... et au lieu d'installer cette architecture logicielle souple, il lance le développement d'un "monolithe distribué" selon le bon mot d'un de nos consultants. La solution induite à alors tous les inconvénients du microservice (si, si, il en existe...) et... tous ceux des applications monolithes !

Rappel rapide de ce qu'est une architecture microservice:

• Une collection d'applications unitairement cohérentes. Autrement dit : chacune d'entre elle est autonome et doit remplir une mission fonctionnelle qui la justifie per se. A la limite, si on ne développait qu'elle, cela aurait un sens du point de vue métier.
• Ces applications sont découplées (et non simplement faiblement couplées). Elles peuvent vivre sans les autres. Elles vivent mieux avec, mais cela ne leur est pas vital. Ce point est critique. En particulier, il faut éviter que l'application microservice A ne puisse fonctionner que si l'application microservice B est lancée.
• Ces applications sont collaboratives, ce qui signifie qu'il existe un "langage commun" entre elles et un "forum" où elles se retrouvent pour échanger. Un bus logiciel fait l'affaire par exemple. Un microservice pose une question sur le forum, on lui répond (ou pas !), il exploite la réponse sans se préoccuper de quel autre microservice lui a fourni cette réponse. Sans réponse, il sait aussi travailler (en mode dégradé).
• Les microservices sont tolérants : sur la structure des réponses, sur la présence où le format de telle ou telle information, sur les délais de réception des réponses, ...
• Idéalement (je dis bien: idéalement, côté front c'est parfois compliqué...), un microservice, c'est un front + un back + une source de donnée et un autre microservice, c'est un autre front + un autre back + une autre source de données.

Ce que les microservices ne sont pas:

• Une simple collection d'API Rest découpée en modules chacun déployé sur un Tomcat indépendant.
• Des services interdépendants, utilisant la même base de données, utilisant nécessairement la même plateforme technique (langage, framework), rigide à tout changement de l'API des autres "microservices". Ces (faux) microservices doivent alors tous évoluer en même temps, par palier technique, ce qui est diamétralement contraire à la promesse première du microservice.
• Des services fonctionnellement incomplets n'offrant pas une valeur fonctionnelle intrinsèque.

Le buzz/brouillard autour du microservice est symptomatique des carences de notre profession :

• Absence de connaissance précise des concepts manipulés permettant à chacun de mettre de ce qu'il veut derrière un terme, rendant ensuite problématique les échanges du fait d'une cascade de malentendus. C'est la tyrannie du buzz. La première chose à faire quand on veut faire du microservice est de lire un ouvrage dédié au sujet et de faire ensuite un peu "reposer" ce que l'on vient d'absorber.
• Focalisation immédiate sur les aspects techniques (quel framework utiliser ? quel format (JSON/SOAP) adopter ?, SQL ou NoSQL ?) au détriment de la stratégie. Une réflexion fonctionnelle et conceptuelle, peu ou pas dépendante des techniques d'implémentation est indispensable au préalable pour réussir un projet microservice. Il faut savoir POURQUOI on veut faire du microservice.

Votre système est microservices si:

• Vous êtes capable d'arrêter un microservice, (n'importe lequel) sans pour autant priver vos utilisateurs de la valeur métier apportée par les autres microservices.
• Vous savez remplacer le microservice A écrit en JAVA/MongoDB par le microservice A' écrit en C#/Cassandra.
• Vous savez intégrer la solution tierce Y comme un nouveau microservice (quitte à développer les connecteurs, bien sûr).
• Vous pourriez faire développer un microservice à Paris, un autre à Tokyo et le troisième à Washingtown.
• Vous savez monter de version le microservice A tous les mois, le service B toutes les semaines et le service C, une fois tous les deux jours.

Si ces vertus ne sont pas un enjeu pour vous où si vous ne savez pas le faire, alors évitez de vous lancer dans l'aventure microservices : au lieu de faire nager un souple banc de dauphins, vous allez faire flotter une grosse baleine fatiguée.

P.S. Je suis un chaud partisan du microservice.