Architecture

SOA is dead long live Microservices

Publié le : Auteur: Marc Divet 2 commentaires
architecture

A n’en pas douter, les architectures microservice sont la tendance hype du moment. Une nouvelle vague de patterns d’architecture vient donc en écraser une autre. Et bien pas si sûr ! Martin Fowler, auteur bien connu, a publié un article intitulé « Microservices ». Dans cet article nous pouvons lire « the microservice style is very similar to what some advocates of SOA have been in favor of ». Cette phrase prend tout son sens pour certains architectes. Parmi ceux-ci, il y a Anne Thomas Manes qui dans un post fameux du 5 janvier 2009, « SOA is dead ; Long Live Services », écrivait : « the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever… If you want spectacular gains, then you need to make a spectacular commitment to change ». Il semblerait que l’architecture à base de microservices vise à atteindre cet objectif !

Ici, chez Sodifrance, nous avons mis en place des architectures « microservices » avant même que ce mot existe et qui sans coller à 100% à l’article de Fowler en sont très proche.

Jusqu’ici ma problématique principale était de faire la preuve que des gains d’efficacité et d’efficience nécessitaient une remise à plat de la manière de fonctionner des DSI. Mais avec le digital rien n’est plus comme avant. Les « pure players » de l’internet sont de véritables incubateurs de nouvelles architectures informatiques. Maintenant, il n’est plus question de promesses mais de solutions « battle-tested ». Lorsque Netflix met en œuvre, dans le cloud, une implémentation de microservices non seulement l’efficacité fonctionnelle est prouvée mais aussi quelle efficience ! Netflix consomme 30% de la bande passante US de l’internet, des dizaines de milliers d’instances AWS et a 50 millions de clients !

L’objectif de ce post est donc de poser un retour d’expérience au regard des principales caractéristiques décrites par Martin Fowler dans le chapitre « Characteristics of a Microservice Architecture ». Ce retour d’expérience vient de ma participation en tant que « lead architecte » à plusieurs projets majeurs de transformation du SI de grands acteurs nationaux des secteurs assurances et banques.

Les composants sont les microservices, toutes les compositions passent par une relation client fournisseur entre microservices (Componentization via Services).

Ce point définit l’autonomie du service dans son cycle de vie, de la conception à la mise en production. Le service est autonome, ce n’est pas une façade sur un existant !

Retours d’expériences : Un énorme effort pédagogique est à faire pour expliquer que l’on ne livre plus d’application… mais des microservices. Avec le niveau de publicité fait aujourd’hui autour des microservices, ce point tombe sous le sens. Mais lorsque nous avons commencé, non !!!

Il a donc fallu déconstruire le système de livraison et de composition d’applications monolithiques, aller aux fondamentaux de la logique de composant, des interactions et des évolutions fonctionnelles, pour comprendre les failles de l’existant. Avec du recul, ce mouvement a participé à la gestion du changement. Arriver avec une recette toute faite est la certitude d’aggraver les crispations. Co-découvrir les problématiques de la situation présente avec les acteurs concernés, c’est créer la phase d’un « unfreeze » du process de gestion du changement de Kurt Lewin.

Les microservices sont organisés autour de fonctions business  (Organized around Business Capabilities)

Cette vision fonctionnelle de l’architecture centrée sur les fonctions métiers n’est pas nouvelle. Les arguments développés par Martin Fowler sont aussi brillants que pédagogiques, comme la référence à l’article de Conway. Mais là encore la mise en œuvre est complexe parce qu’elle n’a rien à voir avec la technique et tout à voir avec l’organisation du travail.

Retours d’expériences  : Ici il n’y a pas de « silver bullet », il faut travailler au plus près du métier (et non des projets) pour typer les microservices, définir une structure de gouvernance des relations consommateurs-consommés pour rendre l’architecture pérenne. Sans cela c’est le chaos.

Des produits et non des projets (Products not Projects)

« You build, you run it » les équipes prennent l’entière responsabilité du cycle de vie. Voici le point le plus « clivant ». Parce qu’un projet a un début, un budget et une fin. Un microservice existe et évolue de manière concomitante au besoin métier qu’il assure, son existence et son évolution sont à l’échelle de l’entreprise.

Retours d’expériences : Sur ce point nous sommes, au milieu du gué, soit une organisation basée sur des propriétaires/concepteurs  de microservices. Leurs réalisations sont déléguées à des centres de services. Bien qu’ils soient indépendants, leur évolution est toujours conditionnée par un couplage avec un ou plusieurs projets qui finance la création (ou l’évolution) du microservice, car plusieurs projets peuvent dépendre du même microservice ! Il s’agit bien sûr d’une entorse au modèle « you build, you run it » mais dans notre cas le changement d’échelle entre une application monolithique et les microservices a permis d’abaisser les coûts de transaction, et donc d’améliorer la rentabilité financière pour l’ensemble des parties prenantes.

La mise en œuvre de protocoles simples : HTTP requête – réponse, « lightweight messaging » (Smart endpoints and dumb pipes)

L’architecture de microservice met fin à la confusion des genres entre un outil technique, les ESB, et une démarche d’architecture. La médiation n’a plus lieu d’être. Il n’existe plus qu’un besoin de communication qui n’ajoute pas au couplage fonctionnel un couplage technique (par exemple un message en position longueur). L’idée d’un ESB recouvrant le patrimoine légué d’un tapis d’API n’a plus sa place. L’architecture à base de microservices n’est pas une architecture d’intégration, c’est un mouvement radical : «  Slapping APIs on existing applications does not improve architecture », A.T. Manes.

 Retours d’expériences : Enfin nous sortons de la bataille Web Services contre Rest, conflit vraiment contre-productif, car la principale difficulté, comme l’enjeu majeur, c’est de rendre résiliant aux évolutions la signature du microservice (ses opérations et les données entrantes et sortantes). Ce n’est pas une mince affaire, et les bénéfices de l’architecture dans son entier peuvent être obérés par une mise en œuvre mal comprise ou bâclée.

Quid des ESB, dans une architecture de microservice ? Leurs rôles d’intégration et d’intermédiation sont inutiles. Par contre les ESBs sont de très bons candidats à la production de services. C’est ce que nous avons mis en œuvre car dans certains cas d’usage ils sont indispensables pour la gestion des transactions impliquant plusieurs microservices.

Gouvernance technologique décentralisée (Decentralized Governance).

Ici, c’est la gouvernance des technologies, des moyens, et des méthodes de mise en œuvre dont il est question (la gouvernance de la relation entre microservices c’est une autre chose).

Décentraliser la gouvernance ce n’est pas l’absence de gouvernance… Netflix autorise une assez grande variété de technologies mais ce n’est pas l’anarchie ! Si une liberté complète est laissée à l’équipe de développement, le management doit s’assurer de sa pérennité. En effet, il ne faut pas oublier qu’un microservice ce n’est pas du jetable, il concentre dans un point unique la réponse à un besoin métier… D’un point de vue de la gouvernance des organisations, laisser dans les mêmes mains le quoi mettre en œuvre, le comment nous le mettons en œuvre et la mise en œuvre, c’est de la même essence que laisser la même personne commander des biens et signer les chèques. Soit la porte ouverte à toutes formes de déviance ! Sans un minimum de séparation des  rôles, l’organisation perd tout pouvoir sur elle-même.

Retours d’expériences : La problématique c’est de gérer la dialectique entre la gouvernance et la décentralisation. L’architecte et le développeur ont bien sûr des avis totalement divergents sur ce point… En tant qu’architectes nous avons la responsabilité de la pérennité et de la résilience du système d’information dans sa globalité. Nous savons malgré tout qu’il faut aussi faire preuve d’une agilité certaine… mais l’agilité passe aussi par une certaine standardisation des pratiques. Ce que nous avons fait c’est définir une typologie de services, à chaque typologie la technologie la mieux adaptée a été adoptée.

Management des données décentralisé (Decentralized Data Management)

Ce qui est expliqué dans le texte de Martin Fowler n’est pas une nouveauté. Cette nécessité est explicitement décrite dans les livres de Thomas Earl, l’auteur le plus prolixe du mouvement SOA, dans le concept de service d’entité.

Retours d’expériences : Je suis en total accord avec ce principe mais entre son énoncé et sa mise en œuvre il y a un vrai gouffre. D’autant plus grand que le domaine métier est marqué par un besoin fort en transactions transverses… comme pour les banques et les assurances !

Nous avons également développé une trajectoire permettant de prendre en compte un patrimoine existant, et cela non plus n’est pas une mince affaire car il faut correctement gérer l’émergence d’une nouvelle architecture cohabitant avec les données de l’ancienne. Qui est encore partisan du big bang ?

Automatisation de l’infrastructure (Infrastructure Automation)

Soit l’application des démarches d’intégration, de déploiement continue, d’automatisation des tests d’acceptation, des tests d’intégration, des tests de performance… Il n’y a pas d’architecture de microservice sans une mise en œuvre d’une automatisation et d’une gouvernance forte. Les microservices sonnent la fin des architectures monolithiques. Si les inconvénients de ce type d’architecture sont la cause de leur déclin, il convient de reconnaître un point important en leur faveur : la cohérence du package de déploiement. Un microservice est indépendant. Par contre ce n’est pas un silo en plus petit : il collabore avec d’autres microservices dans une relation consommateur-consommé. La gestion et le respect des dépendances sont des impératifs majeurs pour éviter les incidents de production. Ce point n’est vraiment pas trivial et doit être traité avec la plus grande attention.

Retours d’expériences : C’est un des postes budgétaires majeurs du programme… mais sans cet investissement rien n’aurait pu fonctionner. Faciliter la vie des acteurs parties prenantes du cycle de vie des microservices c’est aussi s’assurer d’une homogénéité certaine. Le renversement de paradigme silos vs microservices fait apparaître, en creux, les qualités du mode silo. Sans un travail préalable de comparaison, de mise à jour de la dialectique exposée plus haut, les résistances aux changements se seraient cristallisées et auraient fait échouer le programme.

« Design for failure »

Il existe deux niveaux de « design for failure ».

Le premier niveau est bien sûr la mise en œuvre du monitoring et d’outil de diagnostic. Par exemple : http://techblog.netflix.com/2015/02/a-microscope-on-microservices.html

Le deuxième niveau est la mise en œuvre du principe anti-fragile de Nassim Nicholas Taleb. C’est ce que fait Netflix, en déployant son armée de singes dans son système d’information. Ce niveau est une obligation pour un déploiement cloud massivement parallèle comme le fait Netflix sur AWS : http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html

Retours d’expériences Nous avons mis en œuvre le premier niveau de « design for failure », soit la surveillance et les moyens de tracer les erreurs. La mise en œuvre du principe de management décentralisé des données conduit à revoir le modèle transactionnel traditionnel. Là encore, il y a une dialectique à bien comprendre : comment faire en sorte qu’un acte métier qui conditionne la mise à jour de données détenues par plusieurs microservices soit  réalisé correctement ?!

 Design  evolutif (Evolutionary Design)

Il est question ici de versionning… Martin Fowler utilise ces mots : « only use versioning as a last resort ». Le problème c’est que ce dernier ressort est dans la main des métiers. Et le métier commande ! Si le métier décide qu’au 31/12/2015 les numéros de téléphone seront sur 12 chiffres, nous serons dans le « last resort ». Et dans des domaines aussi normatifs que les banques et assurances, les injonctions de ce type restent relativement fréquentes… Il convient donc que l’architecture éclaire ce point avant toute démarche de mise en oeuvre.

Retours d’expériences :  Ce que nous avons fait pour répondre à ce challenge, c’est de prendre le problème à bras le corps. Nous avons donc identifié les niveaux d’impacts sur la relation consommateurs-consommés des évolutions du contrat de service. Ceci est très sophistiqué, le bon sens est très vite pris en défaut. Mais l’objectif de n’avoir à subir que des impacts métier directs sans aucun impact technique a été atteint.

 Conclusion :

Ce parcours a duré plusieurs années. De cette expérience, j’ai retenu que derrière les discours marketing les plus optimistes et volontaristes, se cachaient une myriade de problèmes à résoudre. Après la phase préliminaire d’étude et de planification, l’architecte doit se confronter au brouhaha du chantier de construction. Après le moment où chaque mot, chaque schéma peut être pesé, discuté, amendé, viens le temps du brouillard de guerre, soit le moment où la capacité de décider très rapidement et de maintenir le cap devient un facteur clef de succès de l’entreprise dans sa globalité. Il est ici question de maintenir la cohérence structurelle de l’architecture, cohérence menacée par les effets de la résistance aux changements et des jeux politiques organisationnels. Et là, l’architecte doit rester à l’intérieur de la boucle OODA !

  • Vincent Hanniet

    Mon point de vue est assez différent, donc je le donne pour enrichir l’article !

    Dans ma vision d’architecte, l’architecture orientée services a toujours été d’abord une question concernant le métier, les données et le packaging de fonctionnalités avant d’être une question d’implémentation technique.

    On peut, et on a toujours pu, faire du SOA sans avoir besoin d’un ESB ou même de « Web-Services » utilisant feu le protocole SOAP. Un simple mécanisme de RPC peut faire l’affaire, comme par exemple Google RPC qui est le mécanisme d’appels de service utilisé actuellement par tous les produits Google (si j’ai bien tout suivi à Devoxx 2015) et qui vient de passer open source : https://github.com/google/protorpc. Au passage, vu le volume de ce que Google traite avec grpc, on remarquera que l’indication d’utilisation d’un ESB n’est pas juste une question d’échelle dans les appels de service.

    Mon bouquin de référence pour le SOA est : « Enterprise SOA, Service-Oriented Architecture Best Practices » de Dirk Krafzig, Karl Banke et Dirk Salma. Il date de 2005 et reste tout à fait d’actualité pour faire du SOA, microservices ou pas (car il n’est pas adossé à une pratique de niveau implémentation technique).

    J’aime bien, et je partage complètement, l’approche de Steve Jones qui considère que ce qu’on appelle « Microservices » est essentiellement le SOA tel qu’il aurait pu être compris si les vendeurs de solutions logicielles ne s’en étaient pas « trop » mêlé. En ajoutant, dans le meilleur des cas, une petite touche de Devops en s’intéressant dès en amont à la capacité à déployer les services conçus. Mais je ne vais pas paraphraser l’article original de Steve Jones, et les liens vers différents sujets connexes dont l’article co-écrit par James Lewis et Martin Fowler, résumés ici : http://www.infoq.com/news/2014/03/microservices-soa

    • marc divet

      Une autre source de référence sur les architectures SOA est

      l’immense travail de publication de Thomas Erl et de son équipe. Dans ce
      travail, il y a intrication entre l’aspect fonctionnel et l’aspect d’encapsulation et de résilience
      lié à la technique. Je pense que cette séparation entre l’aspect « métier »
      et l’aspect « technique » est un biais culturel bien français. Soit l’opposition entre le ciel des idées
      pures du philosophe et les mains sales du technicien … La proposition de l’architecture
      microservice, c’est de mettre enfin en musique les idées de séparation d’intention
      et de couplage faible pour répondre aux besoins d’agilité liés au développement
      du numérique.

      Je rappelle donc cette phrase du billet et de l’article de Martin
      F. : « Les microservices sont
      organisés autour de fonctions business
      (Organized around Business Capabilities) ». Bien sûr, pas n’importe
      comment, les apports de l’urbanisation à la Française sont ici très utile, mais
      pas suffisants… Il faut ici introduire une autre taxonomie, chez Thomas Erl, il
      y a deux types de services, dans d’autres implémentations il y en a plus. Chaque
      type correspond à un besoin métier, comme un cas d’usage bien identifié. Sans
      cette typologie de services reconnue par le métier et mise en œuvre par la
      technique, il n’y a pas d’architecture, mais une belle anarchie, à terme
      ingérable.

      Non, les RPC, comme tout autre moyen d’exposition technique et d’appel de
      fonctionnalité ne définit pas une architecture de service, mais défini une API … Cette
      définition est bien sûr essentielle, mais pas suffisante pour garantir un haut
      niveau de maintenabilité et d’agilité. C’est ce que voulait dire A.T Manes en
      écrivant « Slapping APIs on
      existing applications does not improve architecture » …

      Un lien utile … http://serviceorientation.com/serviceorientation/index