Note de lecture : Software Telemetry, par Jamie Riedesel

Note : 4 ; Une très belle conceptualisation, mais un texte qui s’éparpille et manque souvent de hauteur

J’ai renommé la section dans laquelle figure cette note de lecture d’après ce livre. Cela devrait en dire long sur celui-ci. Car celui-ci aborde et conceptualise de manière original un sujet : celui de l’architecture du pipeline d’observabilité. Pourtant il n’est pas écrit par un architecte, mais par une ops. Cela est très visible dans la manière dont les sujets sont abordés et cela coûte au texte pas mal de points.

Le texte justement, parlons-en. Il est franchement volumineux avec ses 500 pages découpés en 3 parties, pour un total de 18 chapitres. La première partie aborde le volet architecture que j’évoquais. Cela occupe 170 pages sur 7 chapitres, auquel il faut rajouter le chapitre d’introduction. Il ne faut assurément pas rater ce dernier : les grandes lignes de l’architecture du pipeline d’observabilité y sont décrites, ainsi que les usages de l’observabilité (métriques et logs) par différents acteurs : développeurs, ops, exploitant, sécurité, service légaux…

Le chapitre 2 qui ouvre réellement cette première partie rentre en profondeur sur « l’emitting stage ». On voit déjà ici l’angle ops du texte qui évoque bien SNMP ou systemd, tandis que des briques logicielles permettant l’émission de logs ou de métriques sont passées assez légèrement. Ainsi Log4J est succinctement évoqué, mais pas JMX… Le propos n’est pas inintéressant, mais il aurait peu être nettement meilleur et plus efficace. Fort logiquement, le chapitre 3 va couvrir le shipping, mais également le stockage, ce qui est peut-être trop. J’ai apprécié l’analyse de plusieurs architectures de shipping intégrant même des bus orientés queues (tel que Kafka), mais curieusement les superstars telles que fluend ou Logstash n’y ont guère de place. Il faudra vous diriger vers l’excellent et mal nommé « Logging in Action » si vous êtes frustrés…

Lire la suite
Publicité

Note de lecture : Monitoring Taxonomy, par Dave Josephsen

Note : 3 ; Plutôt qu’un livre, un catalogue pour éveiller votre curiosité.

Le monde du monitoring est plus complexe qu’il n’y parait de prime abord. Non seulement il adresse des finalités très différentes allant des ressources systèmes, infrastructure et réseau jusqu’à l’expérience utilisateur, mais il prend en compte des aspects et des fonctionnalités variés : indicateurs, évènements, découvertes de services, tableau de bord et reporting, pour citer les principaux.

L’objectif de court opuscule d’une soixantaine de pages est d’organiser ce paysage en proposant une taxonomie (d’où le titre) où l’auteur va classer les outils de marché. Bref il s’agit d’un catalogue. Pour être précis, il s’agit de la mise en forme rédigée d’un catalogue disponible et mis à jour sur GitHub. Cela explique d’une part le côté un peu rugueux du texte sur lequel je reviendrais et le fait que ce catalogue soit promis à l’obsolescence. Hélas pas de mise à jour publiée ni en vue à ce jour, pour ce texte.

L’explication de la taxonomie, c’est le sujet du premier chapitre qui tente de l’expliquer en 6 pages. Il utilise 3 axes de classification que je ne développerais pas ici, mais qu’il est bien difficile de comprendre (à part l’axe « modèle de pricing » qui est classique) quand on débarque juste de sa campagne et que l’on n’est pas bien au fait du domaine du monitoring. Car en fait le texte est bel et bien fait pour ceux qui nagent déjà dedans. Rugueux, je vous dis.

Lire la suite

Note de lecture : Comprendre DCE, par Ward Rosenberg, David Kenney & Gerry Fischer

Note : 7 ; Un exposé limpide des concepts de DCE. Au-delà de cet environnement, il permet de comprendre les concepts inhérents aux systèmes distribués.

L’environnement DCE n’a pas été un franc succès dans le monde UNIX. Néanmoins, c’est de cette norme que s’est inspiré Microsoft pour Windows NT. DCE, c’est « le réseau est l’ordinateur » à l’heure pré-Web. Et l’ouvrage présente l’ensemble des services pensés pour en faire une réalité. Ne nous laissons pas abuser par l’apparence préhistorique de la chose : ces services sont bien pensés, repris parfois moins bien à l’heure du Web, le propos du livre reste intéressant. Voyons cela.

Au total, l’ouvrage compte 235 pages hors annexes, structurées en 14 chapitres. Ces dernières occupent 35 pages et ne sont guère passionnantes, à l’exception des questions / réponses. Le premier chapitre « le réseau devient l’ordinateur » donne une vue haut niveau de l’architecture et des motivations de DCE. Il est peu technique et constitue une bonne introduction au sujet. Le chapitre 2 entre directement dans le vif du sujet en abordant l’élément central de DCE, ce qui nous conduit rapidement à parler de service de nommage, d’annuaire, de sécurité, etc.
Le RPC est en quelque sorte la brique de base pour ce qui est de l’interaction entre ordinateurs pour DCE. C’est le sujet du chapitre 3. Ce chapitre décompose toutes les étapes, depuis la compilation avec l’IDL jusqu’au protocole d’appel en passant par la recherche du service dans l’annuaire distant. Une solide présentation du sujet. La présentation des threads DCE au chapitre 4 est un peu plus décevante et ne rentre pas réellement dans le cœur du sujet.

Le Security Service est un sujet sérieux et même complexe quand il s’agit de sécuriser les appels entre cellules. Et c’est bien de cela qu’il s’agit au chapitre 5. Le propos est clair et bien illustré, mais laisse quand même un léger goût d’inachevé en fin de chapitre. Le Directory service, avec d’abord le CDS puis le GDA, est aussi un sujet d’ampleur. On ne lui reprochera pas d’être traité légèrement au chapitre 6. C’est l’un des aspects qui a le plus vieilli avec l’arrivée du Web. Et si le texte est bien écrit, il n’est pas non plus palpitant à lire.

Lire la suite

Note de lecture : Au cœur de Corba avec Java, par Jérôme Daniel

Note : 7 ; Corba clairement expliqué

Dans les années 90, Corba régnait en maître sur les applications distribuées ou peu s’en faut. Celui-ci, paru vers la fin de l’ère Corba, a pour but de nous initier complètement à Corba en s’appuyant sur une implémentation Java. Mais c’est avant tout un livre sur Corba. L’auteur, Jérôme Daniel est l’architecte de l’ORB JavaORB (il est également celui de OpenORB, son successeur). Il est donc logique que les exemples s’appuient sur ce broker.

L’ouvrage est assez conséquent, puisqu’il compte 380 hors annexes, structurées en 4 parties pour un total de 20 chapitres. La première partie se focalise sur les mécanismes de base, mais la facture est quand même de 6 chapitres pour 115 pages ! Le premier chapitre traite des environnements répartis et plus particulièrement de l’invocation à distance (donc de RPC) et tout ce qui va avec : fiabilité et sécurité. Le second chapitre, c’est un peu le « hello world » avec Corba, en y incluant de l’IDL, l’implémentation client et serveur jusqu’à l’exécution. C’est très bien fait. L’IDL, justement, va être utilisé opérationnellement au chapitre 2 durant lequel nous allons développer un véritable serveur Corba. Même si cela reste simple, on y est très bien guidé. Le 3ème chapitre est un peu en décalage des 2 premiers, car il prend des allures de manuel de référence IDL, bien qu’étant moins sec que ce qu’il est convenu de croiser en la matière.

En abordant le chapitre 4, on prend bien conscience que l’IDL est au cœur de Corba, car c’est encore de cela qu’il est question ici, sur les aspects avancés, en continuité directe du chapitre 3. Le chapitre 5 continue dans la même voie, mais en abordant des sujets qui font la jonction avec les ORB : identifiants, contextes d’opération, etc. Alors que ce chapitre devrait redevenir concret à l’image des deux premiers, cela reste hélas pas mal abstrait ! Cette partie se referme sur un chapitre 6 évoquant les références, contextes et autres URL. Il s’y trouve pas mal de code, ce qui mitige un peu le côté aride du propos.

Lire la suite

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