Note de lecture : Building Microservices, par Sam Newman

Note : 7 ; La promesse tenue d’un tour d’horizon ni trop technique, ni stratosphérique.

Cet ouvrage est déjà la référence sur l’architecture Microservices, donc de fait un préalable à mes autres lectures sur le sujet ! Le texte en lui-même est de taille moyenne, avec 250 pages structurées en 12 chapitres. Le propos n’est pas de rentrer ici dans des arcanes techniques, mais de rester à un niveau architectural concret, mettant en œuvre des patterns spécifiques à ce type d’architecture. C’est donc un bon deal.

Le premier chapitre est assez succinct et reste à très haut niveau : pourquoi fait-on des microservices ? Quelles en sont les propriétés principales ? Quels sont les bénéfices attendus ? Si l’on ne retrouve pas le thème de l’hétérogénéité technologique ailleurs (une propriété pourtant importante), les autres se retrouvent égrenés au long des autres chapitres : résilience, scalabilité, alignement sur l’organisation, facilité de déploiement ou de remplacement et composabilité. Le chapitre 2 est plus inattendus, car il s’intéresse au rôle de l’architecte. Un rôle bien mal défini et qui n’a rien à voir avec le rôle des architectes certifiés du génie civile, comme le fait remarquer l’auteur ! C’est en tant que « architecte évolutionnaire » que Sam Newman conçoit ce rôle, à cheval entre la vision et la gouvernance (zoning du domaine, alignement stratégique), mais aussi humain à travers la capitalisation de pratique et la collaboration avec l’équipe. Au final un chapitre qui est une heureuse surprise.

Le chapitre 3 est court d’une dizaine de pages : comment modéliser un service. Ici, l’auteur fait un lien naturel avec les « bounded contexts » du Domain-Driven Design. Mais il évoque aussi un sujet que l’on retrouvera plus loin : le découpage en microservices se fait par split de services ou applications de plus forte granularité. Le chapitre 4 est lui le plat de résistance de l’ouvrage : l’intégration ! J’en retiens plusieurs éléments : tout d’abord la mise en œuvre de chorégraphie distribuée via des évènements plutôt qu’une orchestration centralisée. Des appels synchrones qu’il faut rendre simples et agnostiques. Si je ne suis pas d’accord avec l’avis de l’auteur pour qui SOAP est protocole dépendant et REST protocole indépendant (désolé, mais c’est l’inverse), je trouve intéressant son appréciation de XML par rapport à Json, qui n’est pas dans l’air du temps. Bien sûr qui dit asynchronisme des évènements dit transaction distribuées ou mécanisme de compensation, des sujets ici tout juste évoqués, tout comme le versionning sémantique.

Le chapitre 5 aborde la question du legacy : comment splitter le legacy. L’auteur propose une approche à l’opposée de la mienne : d’abord splitter la base de données unique, ensuite splitter l’applicatif. L’argumentaire ne m’a guère convaincu. Au moins le texte n’élude pas la question du reporting qui doit effectuer des croisements de données. Si on fait l’impasse sur la question de la modélisation décisionnelle et de sa dénormalisation, Sam Newman aborde la question de la synchronisation via des « data pumps » qui ne semblent être guère que des ETLs, et de leur pendant temps réel / évènementiel… Le déploiement est au menu du chapitre 6. Pour Sam Newman, il s’agit d’un aspect essentiel. Les sujets sont presque aujourd’hui des classiques : deployment pipeline, dockerisation et finalement définition d’environnements, où l’auteur préfère Fabric à Ansible (et bien sûr aux autres).

Si le déploiement n’est pas mon sujet préféré, il n’en va pas de même des tests au chapitre 7 ! J’abonde dans le sens le l’auteur sur nombre de points. Tout d’abord sur l’idée d’utiliser les quadrants de Brian Marrick comme repère et sur les critiques faites à la pyramide de Mike Cohn. J’ai toutefois un peu de mal à m’y repérer sur les noms donnés aux types de tests : Le CDC semble correspondre aux tests d’acceptation, et les tests bout-en-bout semblent des tests système. Le « canary test » et le « chaos monkey » ne sont pas encore de grands classique, c’est bien de les voir abordés ici. C’est de monitoring que parle le chapitre 8. Il est court mais synthétise bien les aspects à considérer : gestion (unifiée) des logs et corrélation entre services, par exemple.

On ne saurait échapper aux questions de sécurité. Le chapitre 9 leurs sont consacré. Si le tour d’horizon semble effectué, le sujet descend à un niveau très technique en étant pauvrement illustré. Cela en fait un des chapitres que j’ai le moins apprécié. On remonte de nombreux niveaux avec les questions organisationnelles du chapitre 10. Ce sont tout simplement des modèles d’organisation adapté aux développements en microservices qui sont proposés ici. L’idée proposée va dans le sens des feature teams qui sont dans l’air du temps.

Le pénultième chapitre aborde enfin des questions d’échelle, et plus exactement les questions de fragilité qui y sont inhérentes. Les patterns proposés ici par l’auteur sont devenus des classiques dans le monde des microservices : Bulkhead, circuit breaker, mais aussi scalabilité horizontale des bases de données, transactions applicatives et CQRS. Un gros chapitre. L’ouvrage se referme sur les chapitre 12 qui reprends et synthétise les différentes facettes de l’architecture en microservices.
L’ouvrage de Sam Newman s’est fait sa petite réputation. Elle est méritée. L’auteur évite l’écueil du texte trop technique, toute en restant très concret. La prose est claire et consistante. Le domaine est toutefois en pleine évolution. Malgré le niveau « pattern » adopté pour cet ouvrage, il s’expose à une lente prise d’obsolescence.

Building Microservices

Référence complète : Building Microservices – Sam Newman – O’Reilly 2015 – ISBN : 978 1 491 95035 7

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.