Note de lecture : The Passionate Programmer, par Chad Fowler

Note : 6 ; Juste une nouvelle édition actualisée et améliorée dans les idées développées dans le précédant ouvrage

J’ai une habitude, probablement détestable : je pénalise d’un point les secondes éditions qui sont justes aussi bonnes que les premières éditions ! Cette seconde édition de « My Job Went to India », car c’est bien de cela qu’il s’agit même si le titre a changé, subit cette règle de plein fouet. Comme nous allons le voir, si l’évolution du texte va au-delà du cosmétique, c’est surtout le changement de titre qui reflète mieux l’intention première du propos.

A format équivalent, cette nouvelle version, avec près de 200 pages en accuse 20 de plus que l’opus précédent. 5 nouveaux items sont apparus et 4 ont disparus (ceux du dernier chapitre), un bilan qui passe donc de 52 à 53 items. On retrouve les mêmes chapitres que précédemment, à l’exception du dernier qui a disparu. Donc, c’est 5 chapitres au lieu de 6. La première partie « choose your market » comporte 10 items au lieu de 9 précédemment, mais avec quelques changements. Mon item « à emporter » est le n° 4 : Be the worst ! Comme le disait Miles Davis, pour progresser, il faut choisir le groupe où l’on sera le moins bon joueur !

Lire la suite

Note de lecture : Practical Monitoring, par Mike Julian

Note : 7 ; Une brève et excellente introduction à l’univers du monitoring !

Quand il est question de monitoring, il est bien difficile de trouver un ouvrage ciblant d’autres publics que les ingénieurs systèmes. Pourtant, partie intégrante de nos systèmes d’information, il est bien utile sinon indispensable de comprendre ce que ce domaine recouvre, ces composantes, ces possibilités, les différentes composantes, etc. Non, ce que la plupart des ouvrages nous proposent, c’est de plonger directement dans les fichiers de configuration, nous laissant à nous autres, pauvres mortels, la difficile tâche de comprendre de quoi il en retourne. Ce livre comble exactement cette lacune. Attention, il reste technique, mais à peu près agnostique quant aux outils.

Le livre est bref également, avec à peine 140 pages. C’est à la fois dû à l’efficacité de la prose (qui est par ailleurs très agréable à lire) et au caractère introductif du texte. L’ensemble se décompose en deux parties, pour un total de 11 chapitres. La première partie se contente de 4 chapitres pour un total de 55 pages et couvre les principes du monitoring. Elle débute de manière originale par un premier chapitre sur les anti-patterns, ici au nombre de 5. La plupart d’entre-eux nous alerte sur un focus trop porté sur l’outillage en premier lieu, alors que sa mise en place doit être guidé par l’usage et les feedbacks escomptés. On commence bien ! Fort logiquement, le second chapitre est consacré aux patterns. Ils sont au nombre de 4 et le plus important d’entre-eux, régulièrement rappelé dans la suite du texte, est de débuter par la perspective utilisateur. Voilà qui nous change des ouvrages purement techniques sur le monitoring.

Le 3ème chapitre a une perspective résolument processus, on n’y parle presque pas de monitoring : il s’agit de la gestion des incidents et des alertes. La coloration de ce que nous propose l’auteur ici est d’avantage ITIL qu’agile, mais un ITIL un peu agilifié quand même. Enfin, et c’est une surprise, le chapitre 4 nous propose une courte introduction au minimum vital des concepts mathématiques et statistiques nécessaires pour comprendre les indicateurs. Bien vu.

Lire la suite

Note de lecture : Prometheus: Up & Running, par Brian Brazil

Note : 4 ; Une approche “culture système” avec des allures de manuel de référence qui ne facilite pas la compréhension globale.

La littérature sur Prometheus est fort maigre, malgré le poids qu’a pris ce système de monitoring, porté entre autres par le cloud en général et par la percée de Kubernetes avec lequel il s’intègre parfaitement, en particulier. Cet ouvrage vient combler cette lacune. Comme nous le verrons, il s’adresse avant tout à un public orienté « opérations », qui manque singulièrement d’une vue en grand.

Pourtant l’auteur n’a pas été avare : l’ouvrage compte 350 pages an 20 chapitres structurés en 4 parties. La première d’entre elles, l’introduction ne compte que 2 chapitres sur 35 pages. Cela débute par une présentation de l’outil. On y dresse le paysage du monitoring, les fonctionnalités attendues pour arriver sur l’architecture de l’outil lui-même. Un chapitre très instructif. On plonge directement dans l’exercice préféré de l’auteur dans les premiers pas proposés au chapitre 2. Certes on voit comment installer le produit et commencer à l’utiliser, mais en alignant les commandes, sans perspective ni contexte. C’est assez frustrant.

La seconde partie traite du monitoring des applications. Elle compte 4 chapitres sur environ 55 pages. Il est d’abord question d’instrumenter les programmes au chapitre 3. Via de courts exemples en Python, on voit comment mettre en place les différents instruments (compteur, gauge, buckets, etc.) et comment configurer Prometheus pour les récupérer. C’est super-basique mais cela fait le boulot. C’est toujours côté client que le chapitre 5 se situe en passant en revue les modes d’exposition et ce en différents langages. Le texte est à mi-chemin entre le guide d’utilisation et le manuel de référence, il lui manque une vue de haut niveau des cinématiques de scrapping.

Lire la suite

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 : Kubernetes: Scheduling the Future at Cloud Scale, par David K. Rensin

Note : 1 ; Plaquette commerciale Kubernetes

Vous allez dire que j’aurais dû me méfier vu la maigreur de l’opuscule (38 pages) ? C’est vrai. Pour autant, cela peut suffire pour avoir une vue aérienne et une première approche de l’outil. La vue aérienne est assez bien couverte par le premier chapitre, « go big or go home ». Sauf qu’en fait, ce n’est pas le premier chapitre. Le premier est une introduction où l’auteur parle essentiellement de lui : une totale perte d’espace pour un opuscule qui n’en a déjà pas de trop. Revenons à ce premier chapitre qui est en fait le second. Il introduit correctement les concepts de base : conteneurs, nodes, pods… C’est quand même bien succinct et on ne voit pas très bien comment tout cela fonctionne et communique ensemble !

Le second chapitre traite d’un aspect important : les labels et les annotations. L’auteur nous en parle mais en omettant complètement de nous dire comment cela était assigné, comment cela fonctionnait. Bref on sait juste que cela existe et que cela peut être requêté, même si on ne sait pas comment ni dans quel but. Il faudra raccrocher cela avec l’idée évoquée qu’il faut traiter les serveurs comme du bétail et qu’ils peuvent être détruits et créés à la volée. On voit confusément la relation et l’auteur nous laisse nous débrouiller avec cela. On saute du coq à l’âne avec le réplication contrôler, les services, le scheduling des pods, etc. Cela aurait mérité un autre chapitre, car il n’y a pas vraiment de rapport. En fin de compte, beaucoup de concepts sont effectivement évoqués, mais fort mal introduits et sans aspects concrets pour bien comprendre chacun d’entre eux.

Le dernier chapitre évoque les différents modes de déploiements : sur machine virtuelle, sur serveurs dédiés ou en service managé sur le cloud. L’auteur travaille chez Google, aussi est-il à l’aise pour dire que cela marche bien sur GKE. C’est sans aucun doute vrai, même si en 2021, les 3 grands clouds n’ont plus de problèmes là-dessus.

Lire la suite

Note de lecture : Value Stream Mapping, par Karen Martin & Mike Osterling

Note : 7 ; La démarche Value Stream clairement expliquée et décomposée, et un peu moins clairement illustrée.

Le Value Stream Mapping, ou VSM, est un sujet souvent évoqué dans la communauté agile qui veut s’habiller de Lean. Mais il est souvent peu compris, et plus souvent encore pas compris du tout. Dans le meilleur des cas, il est réduit à la timeline montrant les temps de production et les temps d’attente.

Mais qu’est réellement le VSM ? Comment détermine-t-on les VSM d’une organisation ? Comment modélise-t-on ces VSM et par quelle démarche ? Enfin, comment utilise-t-on cette approche pour enclencher une logique d’amélioration continue et d’expérimentation qui est la marque d’un processus Lean ? Ce sont à ces nombreuses questions que répond le présent ouvrage, et ce n’est pas rien !

La partie principale du texte est relativement courte, avec environ 150 pages, mais il faut y rajouter les 35 pages des annexes. Le sujet est couvert en 6 chapitres. Le premier d’entre-eux « value stream management » n’est guère évocatif de par son titre, mais comme on peut s’en douter, ses 26 pages ont un caractère introductif. Il s’agit ici d’expliquer la structure du VSM (vue macro et vue micro) et son focus sur le client. Un accent particulier est mis sur le caractère cross-fonctionnel des VSM, à l’inverse des vues processus qui restent localisés à une fonction, indépendamment du focus client.

Lire la suite

Note de lecture : Escaping the Build Trap, par Melissa Perri

Note : 6 ; Pour enfin comprendre le paradigme « produit »

Opposer « projet » et « produit » semble être l’un des sujets du moment… sauf qu’au moment de comprendre en quoi l’approche « produit » est fondamentalement différente de l’approche « projet », les choses se compliquent. C’est tout l’objet de l’ouvrage de Melissa Perri dont la lecture n’ira pas nécessairement aussi vite que prévu, malgré qu’il ne compte que 170 pages hors annexes.

Ce ne sont pas moins de 5 parties rassemblant 25 chapitres que compte l’ouvrage. Autant dire que ces derniers sont plutôt courts, ce qui rythme bien la lecture. La première partie « The build Trap » compte 200 pages totalisant 5 chapitres ! Le premier chapitre « the value exchange system » met l’accent sur le problème résolu (en échange de compensation) ce que l’auteur oppose à la posture de « demande de fonctionnalité ». Ce virage du mode réactif vers une réelle compréhension des besoins de utilisateurs est le véritable virage de la culture produit. L’obstacle majeur à ce virage est la culture de l’output (la fonctionnalité produite) par rapport à l’outcome (l’impact), comme le souligne le second chapitre.

Avant d’aborder les organisations orientées produit (au chapitre 4), l’auteur nous fait toucher du doigt la différence entre projets (s’organiser pour construire quelque chose) et produit, un avoir de la société que l’on fait grandir et évoluer pour adresser toujours mieux les besoins des utilisateurs. Donc le chapitre 4 introduit les organisations orientées produit, optimisant et priorisant leurs activités en fonction de l’impact métier, en les comparant aux entreprises orientées ventes, vision ou technologie. Rechercher l’impact, c’est aussi accepter l’incertitude, nous rappelle le chapitre 5. C’est une logique de découverte et de questionnement qui s’oppose aux certitudes du mode projet.

Lire la suite