Les microservices : est-ce réaliste ? Le concept d'architecture en microservices

Plus qu'une nouvelle révolution dans les architectures informatiques, les microservices sont une évolution de l'architecture SOA (pour Service Oriented Architecture) dont on a beaucoup parlé au début des années 2000. Une évolution logique qui résulte d’un long retour d’expérience dans la mise en place d’architecture SOA, et qui vient gommer certains de ses défauts. Jérôme Mainaud, architecte logiciel chez Ippon Technologies, livre sa définition des microservices : "c'est un style d’architecture logicielle dont les différents composants sont développés sous la forme de services autonomes qui s’exécutent avec leur propre processus. Ce modèle s’oppose ainsi aux architectures monolithiques où les composants écrits sous la forme de bibliothèque, modules ou classes sont tous déployés dans le même processus."

L’intelligence est placée aux extrémités du réseau

L'ambition est la même que la SOA, c'est-à-dire transformer des applications monolithiques par définition complexes fonctionnellement et volumineuses, en services simples communiquant entre eux. Pour Romain Niveau, consultant chez Xebia, le microservice se distingue de la SOA sur plusieurs points. "La SOA et les microservices se distinguent principalement sur deux points : les ESB lourds et complexes de la SOA sont remplacés par des bus de messages simples sans complexité métier et robustes techniquement"

Les ESB et autres bus de données intelligents ne font pas partie de ces nouvelles architectures de microservices confirme Jérôme Mainaud : "Pour assurer le fonctionnement d’ensemble, les composants communiquent via le réseau. Habituellement, le protocole HTTP REST est utilisé, mais des mécanismes simples de messagerie comme RabbitMQ,  ZeroMQ ou, plus récemment, Apache Kafka sont envisageables. L’important est de suivre la philosophie originelle du Web selon laquelle l’intelligence est placée aux extrémités du réseau et non dans les communications. Les ESB et autres bus intelligents sont donc exclus du périmètre."

Quelle granularité adopter dans le découpage de l'application ?

L'un des problèmes souvent évoqués dans la conception d'une architecture de microservices, c'est estimer le bon niveau de granularité des microservices. De trop grandes tailles comme ils ont pu être conçus dans les architectures SOA, ceux-ci perdent leurs avantages en termes de souplesse en production. Au contraire, des microservices trop fins vont être plus faciles à maintenir et faire évoluer, mais seront très difficiles à gérer en production. Pour Romain Niveau, il n'y a pas de règle prédéfinie en matière de découpage d'application. "Le concept de taille de service est la base des microservices. Il faut surtout s’assurer qu’un service rende une et une seule fonctionnalité, métier ou technique. Si un service commence à regrouper plusieurs fonctionnalités, il est certainement temps de le découper", conseille l'expert.

Attention à ne pas découper de manière trop granulaire l'application

Attention toutefois à ne pas tomber dans l'excès inverse et découper de manière bien trop granulaire l'application souligne Jérôme Mainaud : "je connais des cas où l’application a été découpée en plusieurs dizaines de services et où les développeurs n’arrivent plus à gérer la complexité de l’ensemble. Pire, j’ai vu un cas ou pour chaque entité, il y avait un microservice pour l’écriture insert et un autre pour la lecture. À ce stade, on devrait plutôt parler de nanoservices !" Si la granularité est trop petite, la complexité globale peut devenir plus grande que celle d’une application monolithique.

Trouver la bonne façon de découper l’application est important et n’est pas aisé. C'est à chaque équipe de trouver la granularité et la décomposition qui lui convient. Cependant, plus votre application est simple et petite, moins vous avez besoin de la décomposer en microservices.