Note de lecture : Production-Ready Microservices, par Susan J. Fowler

Note : 4 ; Une vue bien trop généraliste des microservices depuis un point de vue « ops ».

J’étais impatient d’entamer la lecture de ce petit volume (il compte 130 pages pour sa partie principale). En effet bien qu’il s’agisse d’un texte de plus sur les microservices, il le fait avec une optique « ops » sous la plume de Susan Fowler, à l’époque SRE chez Uber. Dès l’avant-propos, l’auteur nous prévient : on ne rentrera pas dans les détails ici qui nous conduiraient trop loin. Il s’agit de poser les principes généraux et génériques qui permettent l’opérabilité d’une architecture microservices.

Pour mener à bien cette mission, le livre est découpé en 7 chapitres plus 2 annexes. L’entrée en matière s’intitule sobrement « microservices » et pèse 25 pages. Elle ne détaille pas les principes d’un microservice à la Sam Newman. Ici, il est plutôt question de scaling et surtout de présenter le modèle en 4 couches de l’écosystème microservices, qui servira de trame aux différents chapitres. Le chapitre 2 construit pour sa part la structure des chapitres restant, en évoquant la notion de « production ready ». Pour Susan Fowler, cela regroupe un ensemble de propriétés : stabilité, fiabilité, scalabilité, tolérance aux pannes, performance, monitoring et documentation. C’est déjà ici que l’on perçoit le regard du SRE : l’auteur prône la standardisation en toute chose ! Certes, elle évoque la promesse d’hétérogénéité prônée par l’approche microservices mais préfère refermer celle-ci au nom de l’opérabilité !

Le chapitre 3 s’attaque à la stabilité et à la fiabilité, les deux premières propriétés évoquées au chapitre précédent. La cible du propos est d’abord la standardisation des cycles de développements et du pipeline de déploiement. Bien que le terme « standardisation » me donne des frissons, j’appuie le propos développé ici. Un bon point pour le développement des environnements de stagging, partiel ou complet que je trouve pour la première fois bien évoquées ici. Scalabilité et performance sont au menu du chapitre 4. Le propos reste très général sur la notion de scaling, abordant les aspects qualitatifs et quantitatifs, ainsi que la gestion des ressources contraintes. Le capacity planning est brièvement abordé, j’attendais mieux d’un livre labellisé ops. L’efficience du modèle de tâches, du choix du langage ou des caractéristiques des bases de données sont tout autant mentionnées. Un chapitre décevant et frustrant.

Lire la suite

Note de lecture : Building Evolutionary Architecture, par Neal Ford, Rebecca Parsons & Patrick Kua

Note : 6 ; De bons moments mais des considérations bien trop générales la plupart du temps.

Je suis en grand fan d’architecture émergentes. Je n’avais pas de doute sur le fait que ce texte allait alimenter mon enthousiasme. Finalement, le livre refermé, le sentiment est mitigé. Nous allons voir pourquoi.

L’ouvrage est un format court, il ne compte que 164 pages sur 8 chapitres. Le premier chapitre compte une quinzaine de pages et couvre surtout des généralités. D’une part on y évoque les « ilités » et de l’autre la question de la conception émergente et pourquoi les auteurs préfèrent le terme « évolutionnaire ». Bref, il s’agit surtout de généralités. Le second chapitre aborde une notion très conceptuelle, celle de « fitness function », une notion que l’on retrouvera au fil des pages. L’idée est intéressante, à savoir établir une formule combinant les différentes propriétés attendues de l’architecture dans des proportions correspondant à nos attentes. La pratique est beaucoup plus floue, avec des concepts tels que « holistique » versus « atomique » …

Le chapitre 3 est bien plus conséquent, car il compte une vingtaine de pages pour évoquer la question des changements incrémentaux. Le cas d’utilisation choisi « penultimate widget » est bien abstrait, je n’ai pas compris ce que cela faisait (apparemment, ce n’est pas le sujet). Évidemment, il est question ici de pratiques devops et de déploiement continu, mais pas seulement. On évoque aussi la testabilité et de nouveau les fameuses fitness functions. Ce n’est pas mon chapitre préféré. On arrive aux choses sérieuses avec le chapitre 4 traite de « couplage architectural ». D’ailleurs le chapitre compte 35 pages. Tout d’abord la notion de « quanta architectural » définit la plus petite unité déployable indépendamment. Autant dire qu’il est gros pour le monolithe dont les auteurs se moquent à loisir. Le « monolithe modulaire » abordé ensuite (et rarement évoqué) mérite nettement moins de risées. Suivent : Micro-kernel, EDA, SOA, Microservice et serverless !

Lire la suite

Note de lecture : Microservices in Action, par Morgan Bruce & Paulo A. Pereira

Note : 4 ; Plus sur l’infrastructure microservices que sur le microservice lui-même… avec beaucoup d’inaction dans ce « in action » !

Petite déception pour ce nouvel opus de la série « in action » de chez Manning. Celui-ci manque un peu de concret et de profondeur, malgré ses 350 pages. J’étais prévenu, le code serait en Python, mais au final il y en a assez peu, ce qui est à la fois un bien et un mal pour moi. La plus grande surprise est sans doute que l’on ne rentre pas dans la conception des microservices, mais plutôt dans l’architecture de systèmes à base de microservices qui est, il est vrai, une partie importante du concept. Ces architectures sont illustrées à base de diagrammes où chaque microservice est représenté sous forme d’hexagone : est-ce une évocation de l’architecture hexagonale d’Alistair Cockburn ? Nous n’aurons pas la réponse dans ces pages.

L’ouvrage lui-même est structuré en 4 parties pour un total de 13 chapitres. La première, “the lay of the land” couvre moins de 50 pages sur 2 chapitres. On débute par une introduction générale, ou plutôt un teasing des thèmes qui seront développés au fil des pages sur les principes et les challenges que représentent la conception de microservices. Le second chapitre rentre dans l’étude de cas qui servira de fil rouge : SimpleBank. Personnellement, je trouve celle-ci un peu complexe. L’illustration du découpage de feature en service s’en ressent.

La seconde partie s’intitule « design » et compte 5 chapitres sur 135 pages. C’est donc la partie la plus conséquente du livre. Elle débute par un chapitre 3 dédié à l’architecture des applications. Hélas elle reste très haut niveau, brossant à peine les styles d’architectures et les patterns de communication. Petite mention toutefois pour le « micro front-end » que je croise ici pour la première fois. Le chapitre 4 aborde sur 30 pages la question de la conception de nouvelles fonctionnalités. Les auteurs s’appuient sur les notions de « business capabilities » et de « technical capabilities » et sur un découpage en cas d’utilisation ! C’est finalement dans ce chapitre que je trouve trace de la Clean Architecture de Robert Martin, alors que je pensais la croiser au chapitre précédant.

Lire la suite

Note de lecture : Design It ! par Michael Keeling

Note : 5 ; Il aurait été vraiment bien s’il avait été moins abstrait

On trouve de la littérature sur l’architecture agile. Pas beaucoup, mais on en trouve. Mais quand il est question du rôle de l’architecte, il en va autrement. Les approches agiles, centrées sur l’auto-organisation renâclent à en admettre l’existence, et seuls les ouvrages faisant état d’un architecte plus ou moins seul maître à bord (le chef de projet faisant la paperasse indigne de l’Architecte) apparaissent dans les rayonnages.

Le livre de Michael Keeling se positionne ici : une vue agile du rôle de l’architecte. A cet égard, il positionne l’architecte d’avantage comme un facilitateur que comme un directeur (voir un dictateur, le plus souvent). Pour nous convaincre de tout cela, le volume compte pas moins de 310 pages (hors annexes), ce qui semble plutôt conséquent. L’ensemble est structuré en 3 parties totalisant 17 chapitres. La première d’entre-elle, Introducing Software Architecture va compter 2 chapitres et se satisfaire de 25 pages en tout. La douzaine de pages du premier chapitre trace les grandes lignes des missions de l’architecte. C’est concis mais un peu abstrait, sans exemples pour étayer la chose. A ce stade on est confiant, le « Project Lionheart » illustrera cela. On a tort, ce premier chapitre donne un avant-goût du reste.

Design Thinking fundamentals ne parle pas de « Design Thinking » au sens classique du terme. En fait, il est question ici de l’approche globale que propose l’auteur, du travail de l’architecte selon 4 axes :

Lire la suite

Note de lecture : Clean Architecture, par Robert C. Martin

Note : 5 ; Agréable à lire, mais beaucoup de “recyclage », beaucoup de verbiage et peu d’information nouvelle.

Robert Martin est sans contestations possibles un des maîtres du craftsmanship. Je l’ai découvert avec son « C++ Applications Using the Booch Method » qui fut un régal. Son « Clean Code » et plus modestement son « Clean Coder » ont popularisé le craftsmanship et les concepts SOLID. Il m’est difficile d’avouer que j’ai eu du mal à trouver ici des idées nouvelles par rapport à ses écrits précédents. L’ouvrage atteint les 370 pages mais ce volume me parait être là pour donner le change.

Ainsi la première partie composée de 2 chapitres ne dit pas grand-chose, si ce n’est qu’il ne faut pas faire de concession sur la qualité de l’architecture. Une position pas vraiment nouvelle de la part de l’auteur.

La seconde partie fait partie des éléments nouveaux apportés par Uncle Bob : elle est consacrée aux paradigmes des langages de programmation et est composée de 4 chapitres, soit un peu plus de 35 pages. L’auteur nous présente ces paradigmes comme autant de contraintes, de possibilités que l’on enlève au programmeur pour chacune d’entre-elle :

Lire la suite

Note de lecture : Corba : des concepts à la pratique, 2nd édition – Jean-Marc Geib, Christophe Gransart & Philippe Merle

Note : 6 ; Une présentation plutôt pédagogique, mais un texte qui accuse son âge.

Comme le titre l’indique, l’objet de ce livre est d’expliquer Corba en commençant par les principes, puis en poursuivant par la pratique. De fait, le texte devrait pouvoir servir de support d’un cours Corba, par exemple.

Les deux premiers chapitres sont un tour d’horizon des principes de Corba. En une cinquantaine de pages, on fait le tour des concepts de ce middleware, le tout agréablement soutenu par des diagrammes. Pas mal. Curieusement, c’est par une investigation en profondeur que l’on continue, que l’on a un peu de mal à raccrocher à la partie précédente. L’auteur a dû juger que cela était un prérequis indispensable aux chapitres suivants : les interfaces standard de Corba (chapitre 4), hélas fort peu illustré par un exemple pratique, puis les services standard (chapitre 5), toujours aussi peu soutenu d’exemple, même si les diagrammes sont valables. Nous voici arrivé en page 180 (sur 265, hors annexes), avec une vue consistante de Corba, mais peu d’exemples.

C’est le chapitre 6 qui constitue l’étude de cas venant illustrer les parties précédentes. Celui-ci aide pas mal pour comprendre l’implémentation d’un objet Corba en BOA, ainsi que l’utilisation du service de nommage, hélas de nombreux concepts précédemment illustrés n’apparaissent pas, comme les différents types de services décrits.

Lire la suite

Note de lecture : Software Design Decoded : 66 ways experts think, par Marian Petre & André van der Hoek with Yen Quach

Note : 7 ; L’essence du savoir-être de l’architecte dans une lecture éclair !

J’ai réellement été surpris en ouvrant mon colis Amazon, en découvrant ce volume guère plus grand qu’un livre de poche (et pas plus épais non plus). Plus surpris encore de découvrir qu’une page sur deux était couvert par une illustration et que chacune des « 66 ways » tenait en matière de descriptif, sur un seul paragraphe ! Résultat des courses : un lecture qui file en 1 heure 30 chrono, et encore sans forcer !

Malgré la brièveté de l’ouvrage, les auteurs ont tout de même divisé les 66 conseils en plusieurs parties. On débute avec « experts keep it simple », qui regroupe 6 patterns. Je choisirai parmi eux « experts do not overgenerillize », une pierre dans le jardin de ceux qui cherchent toujours la solution générique…

La seconde partie « experts collaborate » propose les 6 suivants. Ici, c’est « experts check with others continually » que je sélectionne. Cela me rappelle mon besoin de parler aux autres de mes idées alors même que je n’ai pas fini de les développer. 6 patterns encore (et l’on voit une récurrence se dessiner) pour la 3ème partie : « experts borrow ». J’y relève « experts use analogy », qui nous permet de réfléchir par comparaison.

Lire la suite

Middleware et Internet, par Daniel Serain

Note : 6 ; Une introduction en douceur, mais un texte malheureusement démodé !

1999, pour les technologies, c’est désormais l’ancien temps ! De fait, cet ouvrage ignore (pour des raisons d’ancienneté) les technologies EJB, .NET et web services ! Aussi regarderons-nous cet opuscule d’un oeil nostalgique.

Le premier chapitre donne une vue générale sur la problématique des middlewares, et aborde superficiellement Corba et COM.

Le second chapitre traite des middlewares d’échanges de messages. Si ce chapitre ignore JMS (là encore pour de bonnes raisons), il présente cependant une bonne introduction à cette technique, sans toutefois rentrer suffisemment dans les détails. Il en va un peu différemment pour le chapitre suivant consacré aux middlewares orientés RPC, où l’auteur détaille plus la cinématique de fonctionnement des RPCs. Il consacre même une partie importante du chapitre à DCE : si la chose est intéressante, elle est encore un peu plus démodée ! Le chapitre 4, qui lui fait directement suite traite de Corba lui-même, des invocations statiques et dynamiques, mais peu des services Corba.

Lire la suite

Note de lecture : Workflow Management, par Wil Van der Aalst & Kees Van Hee

Note : 6 ; Une référence, certes, mais aussi un texte aride !

Soyons clair dès le début : ce livre fait autorité sur les fondamentaux des Workflow et est écrit par la plus grande autorité reconnue en le domaine. D’ailleurs le livre débute ses deux premiers chapitres en posant les bases des concepts fondamentaux des Workflows : tâches, work items et activités, mais aussi les réseaux de Pétri, bien entendu.

Le chapitre 3 s’attaque à la gestion des workflows : l’alignement des ressources et de l’organisation sur les workflows, ainsi que l’adéquation de ceux-ci par rapport aux objectifs et aux coûts. Cette étude est complétée par le chapitre 4 qui couvre l’analyse de pertinence et de performance des workflows.

Si ces 4 premiers chapitres couvrent la théorie, la pratique arrive avec le chapitre 5 qui présente les architectures de systèmes de Workflow, le chapitre 6 qui lui fait suite s’attaque à l’aspect méthode. Une partie qui aurait aussi bien pu être oubliée car elle apporte assez peu ici. L’étude de cas qui termine l’ouvrage est une bonne idée, mais elle est peu passionnante aussi bien par le fond que par la forme.

On notera enfin les 2 annexes : la première destinée aux fondamentaux mathématiques ravira les plus courageux (je n’en fais visiblement pas partie) et la seconde assez courte dédiée à la représentation des workflows avec UML.

Lire la suite

Note de lecture : Architecting Enterprise Solutions, par Paul Dyson & Andy Longshaw

Note: 7 ; Un excellent “pattern language” d’approche très Alexandrienne. Dommage que l’aspect solution me laisse un peu sur ma faim.

Le titre de l’ouvrage est assez évocateur à cet égard: Il s’agit là de décrire le style architectural des systèmes d’information Internet à l’aide d’un pattern language, à la Christopher Alexander. Digne représentant de la « software design patterns series », cet ouvrage expose sur 290 pages découpées en 12 chapitres formant 3 parties des architectures de déploiement dédiées aux applications Internet. Bien sûr, vous allez me dire que le texte va accuser son âge, surtout dans le domaine où les plus grands progrès ont été faits au cours des 10 dernières années ! Si ce point est indéniable, il n’est pas aussi marqué que l’on pourrait le craindre car il se focalise bien plus sur les principes d’architecture que sur les solutions techniques !

Je passe sur le premier chapitre qui ne nous apprend rien pour aborder la première partie « Architecture, Patterns and Internet Technology » qui comprend 4 chapitres sur 60 pages. Le premier d’entre-eux (donc le second chapitre) « system architecture » mérite que l’on ne passe pas trop vite dessus. Ses 15 pages sont consacrées aux propriétés non-fonctionnelles des architectures. Intéressant. Le point sur les technologies de l’Internet que nous propose le chapitre 3 sur 17 pages est un peu superficiel, mais pas aussi démodé que l’on pourrait le croire. Mais il apporte peu. Le chapitre 4 est en quelque sorte la table des matières patterns du livre. C’est un incontournable pour ce genre d’ouvrage. Pour clore cette première partie, les auteurs présentent l’étude de cas fictive sur laquelle ils ont choisi de s’appuyer. On y fait le tour des propriétés non-fonctionnelles que l’on avait énumérées au chapitre 2. C’est bien fait.

Avec 167 pages, la seconde partie est le gros de la troupe du bouquin, et de loin ! Il faut dire que cette partie qui ne compte pourtant que 4 chapitres s’intitule « The Patterns ». Et l’on commence fort logiquement au chapitre 6 par un chapitre « fundamental patterns » de 18 pages. Il présente deux patterns, le très classique « application server architecture » encore largement majoritaire aujourd’hui et un moins convainquant « péripheral specialist elements » dont la symétrie est questionnable du fait de la BDD unique… Le chapitre 7 nous offre un gros morceau avec les « system performance patterns » qui couvrent 45 pages. Les patterns architecturaux de ce chapitre sont particulièrement intéressants et bien décrits dans leur essence (load balancing, redondance, failover, appliance, replication, resource pooling, cache, offlining), il ne manque guère que le sharding des bases NoSQL ! Les diverses variantes de ces stratégies sont abordées ainsi que des considérations d’équilibrage de charge CPU, etc… Bref un chapitre riche qui justifierai le livre à lui tout seul !

Lire la suite