Au cours de ces dernières années, le terme "microservice" s'est développé pour décrire une architecture composée d'une suite de petits services. A la QCon San Francisco 2012, James Lewis de Thoughtworks a fait une présentation sur le concept, ainsi que co-écrit un article avec Martin Fowler sur le même sujet. Cependant, récemment Steve Jones est entré dans le débat en arguant que les Microservices ne sont pas nouveaux comme certains le pensaient, et sont en fait un autre terme pour la SOA (Architecture Orientée Services). A cet effet, il compare et contraste la définition actuelle des Microservices avec le Modèle de Référence SOA de l'OASIS. Steve reprend le plan suivi par James et Martin dans leur article :
Répartition en Composants via les Services: Le MR SOA de l'OASIS déclare :
L'Architecture Orientée Services (SOA) est un paradigme pour l'organisation et l'utilisation de capacités distribuées qui peuvent être sous le contrôle de différents domaines de propriété.
Comme Steve le met en avant :
L'OASIS rentre alors gentiment dans le détail de ce qu'est un service :
- La capacité à réaliser un travail pour quelqu'un d'autre
- La spécification du travail réalisable pour autrui
- L'offre d'effectuer ce travail
En SOA, les services sont le mécanisme par lequel l'offre et la demande sont rassemblées.
Et Steve compare avec ce que Martin et James disent sur le sujet :
Les services sont des composants "hors-processus" qui communiquent des interfaces de composants explicites.
Organisés autour des Capacités du Business: c'est là que Steve pense que Martin a faux et que les Microservices ne sont pas nouveaux. Le MR SOA de l'OASIS définit une capacité comme :
Un effet dans le monde réel qu'un fournisseur de service est capable de fournir à un consommateur de service.
Steve met en avant le fait qu'il soit important de différencier entre la capacité (ce qui produit le travail) et le service (l'élément en charge de l'organisation).
Ce que nous avons découvert en faisant de la SOA sur le terrain pendant une décennie, et tous les gens du Modèle de Référence SOA à l'OASIS avaient beaucoup d'expérience dans le domaine, c'est que le cadre organisationnel était séparé des actions elles-mêmes. La raison pour laquelle c'est d'une importance cruciale, c'est que les gens commençaient souvent à créer des services - où service = capacité - et on finissait avec des tonnes et des tonnes de services (mmh si j'étais insultant, je les appellerais microservices).
Il pense que bien que le texte de Martin sur le sujet soit correct, il lui manque d'importantes références au passé.
Nouveau ? Attendez, j'ai même écris un livre qui parlait de comment modéliser, gérer et monter des équipes autour de cette approche. Le Manifeste SOA (2009) parle des principes clés derrière SOA (mais je préfère quand même le Modèle de Référence) de la part d'un gros groupe de praticiens. Le fait est qu'il y a ici deux problématiques : d'abord la confusion entre service et capacité, et deuxièmement le manque de reconnaissance de l'importance des hiérarchies dans la gouvernance.
Les Produits, pas les Projets : Steve dit que l'article de Martin et James va plus loin que le MR SOA sur ce sujet, mais encore une fois, ne dit rien de nouveau.
Une recherche rapide sur Google suffit à montrer combien d'articles il y a sur ce domaine, certains meilleurs que d'autres et certains produits aussi meilleurs que d'autres, mais ce n'est réellement pas nouveau. J'avais l'habitude d'utiliser la phrase "les Programmes, pas les Projets" et j'ai toujours parlé d'assigner des architectes pour toute la durée de vie d'un projet afin de les "rendre responsables". Ce n'est pas que cette déclaration soit en aucun cas mauvaise, c'est juste que ça n'est en aucun cas nouveau. Nous savons depuis des années que ça aide, mais qu'il y a un problème significatif : le coût.
Des extrémités intelligentes et des tuyaux idiots : Steve est d'accord de tout cœur avec ce principe, mais encore une fois, ne pense pas qu'il soit nouveau. Il l'exprimerait aussi de manière légèrement différente, comme il l'explique :
Dans le Modèle de Référence SOA de l'OASIS, il y a le concept d'un "contexte d'exécution". C'est la partie qui permet à un service d'être appelé et sa capacité invoquée. Clairement, l'extrémité est "intelligente" comme c'est elle qui fait le travail, d'où le terme "mécanisme" utilisé plus haut. La "tuyauterie" peut être triviale ou non (les "tuyaux" communiquant avec ces Rovers sur Mars sont plutôt intelligents je pense), mais ce qu'elle est c'est sans valeur ajoutée. C'était une trouvaille cruciale en SOA et c'est bien documenté dans le Modèle de Référence. Le contexte d'exécution est là où toute la plomberie interne est réalisée mais c'est le Service qui offre l'accès à la capacité, et c'est la capacité qui délivre de la valeur.
Gouvernance Décentralisée : Encore une chose sur laquelle Steve est d'accord avec Martin et James. Cependant...
Je pense que ce n'est pas pas un mauvais conseil, c'est juste que la SOA offre tellement plus que les Microservices en termes de gouvernance. SOA telle que décrite dans le Modèle de Référence OASIS permet à ces principes d'être appliqués à toutes les ressources en informatique, pas juste celles implémentées dans un style particulier, et (...) c'est une approche que les écoles de commerce enseignent.
Microservices et SOA : Il semble qu'initialement, l'article de James et Martin ne référençait pas la SOA (assez ou tout court). Apparemment, à la suite de récentes interactions avec Steve, une note sur le sujet a été rajoutée dans l'article. Cependant, Steve pense que non seulement ce n'est pas suffisant, c'est une diversion :
[...] ce n'est pas une véritable définition de la SOA, mais un déballage des bons vieux clichés des "gros" ESB et WS-*, qui étaient déjà tellement appréciés des RESTafariens quand ils expliquaient pourquoi leur manière était la meilleure. L'affirmation est que cet article décrit le style Microservices de manière nette et précise, et est donc valide en comparaison de la SOA, parce que "SOA signifie tellement de choses". Je ne suis fondamentalement pas d'accord avec cela, premièrement parce que les Microservices en tant qu'approche d'implémentation y gagneraient s'ils pouvaient expliquer comment ils s'articulent autour d'approches non-Microservices, un travail que fait très bien la SOA, et deuxièmement parce qu'il n'arrive même pas à dire ce qui fait qu'un service soit "micro", avec des services allant d'équipes de taille décente (12 personnes), à l'individu.
En conclusion, Steve réitère que selon lui, les Microservices n'ont rien de nouveau et qu'ils sont juste en fait une approche de Livraison Orientée Services. Selon sa vision des choses, un architecte/développeur s'en tirerait mieux en utilisant une approche SOA, qui est bien mieux définie et avec bien plus d'expérience aujourd'hui. Au lieu de parler de Microservices comme quelque-chose de neuf, nous devrions parler de la SOA "aujourd'hui". Et comme Steve le mentionne :
En outre, le fait qu'une des références utilisées soit celle de Netflix qui utilise le terme de "SOA dense" comme reconnue dans les notes de bas de page, ainsi que le fait qu'un autre (Amazon), dise également que c'est du SOA.
Qu'en pensez-vous ? Est-ce juste du SOA ou est-ce que les Microservices offrent quelque-chose de fondamentalement différent ?