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

Note de lecture : L’entreprise libérée par le petit patron naïf et paresseux, par Jean-François Zobrist

Note : 8 ; L’entreprenariat libéré sans ambages et inspirant.

Lire Jean-François Zobrist, c’est d’abord accepter de se prendre une grande claque. L’homme est connu pour ne pas mâcher ses mots, c’est bien ce que l’on retrouve ici. Favi, l’entreprise qu’il a dirigée est largement cité dans l’ouvrage d’Isaac Getz, il est juste de le voir en parler avec ses mots et surtout son point de vue. Un point de vue radical, nous le verrons.

L’ouvrage n’est pas très long, ses 190 pages s’avalent rapidement. Le texte est toutefois structuré en deux parties. La première partie « premiers éléments » compte moins de 50 pages et 4 sous-parties que l’on pourrait appeler « chapitres ». Dans le premier d’entre-eux, Zobrist pose les fondements de ce qui est une entreprise libérée. Elle doit faire de l’argent car c’est indispensable à sa survie comme l’oxygène est indispensable à l’être humain. C’est l’ouvrier qui génère ce cash-flow, tous les autres (DG compris) est à son service. Le thème sera récurrent au long de l’ouvrage. Dans la différence entre entreprise classique et libérée, l’auteur fustige les technocrates en opposant le gestionnaire (qui gère des chiffres) au manager (qui gère des hommes). Le premier veut contrôler le « comment » et naviguer dans la certitude, le second est empreint du bon sens picard et revient au « pourquoi » tout en s’accommodant de l’incertitude qui est la réalité du monde réel.

Dans les principes de la libération des entreprises, l’auteur propose ceux, radicaux, qui ont été ceux de Favi. Radical certes, quand Zobrist énonce que l’encadrement de l’entreprise sont les salariés des ouvriers. Mais c’est bien ce que l’on attend du texte, on n’est pas déçus ! Pour ce qui est d’avancer, tout comme Kotter, l’auteur met en avant le sentiment d’urgence, mais aussi de mettre en avant l’innovation et de laisser sa place au hasard, en fustigeant (encore) les gestionnaires qui cherchent une certitude qui n’existe pas.

Lire la suite

Note de lecture : Le bon moment, par Daniel H. Pink

Note : 5 ; Timing is everything !

Chaque livre écrit par l’auteur de « Drive » mérite à minima l’attention. Ce nouvel opus ne va pas concurrencer le titre phare de l’auteur, mais il a nombre de chose à nous apprendre. Le titre ne cache pas son jeu, c’est de moment, de timing et de synchronisation dont il va être question. Qu’on le veuille ou non, le facteur temps est presque toujours le plus important.

Ce volume est au format de poche, promesse d’une lecture rapide qui sera tenue. L’écriture a dû en être moins rapide quand on voit le nombre d’études et d’histoires sur lesquelles l’auteur s’appuie. Le texte occupe 270 pages en 7 chapitres, sur 3 parties. La première, « la journée » ne compte que 2 chapitres, mais sur 110 pages. Le premier évoque l’architecture secrète de la vie quotidienne ! Il nous montre, avec de très nombreuses études à l’appui, que nous avons bel et bien une rythmicité quotidienne et que notre énergie et notre humeur varient dans la journée. Pour la plupart d’entre nous, cela marche mieux le matin, mais ce n’est pas vrai pour tous et cela varie aussi au fil du temps, passant le plus souvent du soir vers le matin. Rien que ce chapitre vaut le détour et peut vous aider dans votre vie quotidienne !

Au second chapitre, l’auteur va nous parler de l’après-midi que l’on peut voir comme la zone de tous les risques. Du constat des problèmes d’attention dont l’après-midi est la cause, l’auteur nous fait un plaidoyer des « pauses vigilances » qu’il associe à 5 principes directeurs. Là aussi un bon savoir « à emporter ». Même si vous lisez le chapitre l’après-midi !

Lire la suite

Note de lecture : Designing Data-Intensive Applications, par Martin Kleppmann

Note : 10 ; Monumental! Book of the year 2021 !

Une somme de connaissances, cet imposant ouvrage, n’est pas moins que cela. Le titre laisse présager que l’on va parler big data. C’est plus subtil que cela, car il s’agit avant tout les principes et mécanismes fondamentaux des grosses architectures data, certes en faisant référence aux classiques du marché, pour comprendre les spectres d’utilisation des différentes solutions. On va donc y parler stockage, systèmes réparties, transactions, streaming, etc. Et ce n’est pas du léger.

Léger, l’ouvrage ne l’est clairement pas vu de l’extérieur (et comme nous le verrons, cela va se gâter à l’intérieur) : 550 pages divisées en 3 parties pour un total de 12 chapitres. Nous avons donc des chapitres très conséquents, il n’y a aucun doute. La première partie traite des fondamentaux. Cela couvre 150 pages sur 4 chapitres. C’est une introduction en douceur, le propos y est tout à fait abordable. Le premier chapitre, fort d’une vingtaine de pages, nous invite à comprendre ce qu’est un système fiable, scalable et maintenable. Il ne s’agit pas juste de généralités, car l’auteur y présente ainsi la structure des données dans les SGBDR, dans un système de streaming tel que Storm. On y apprend ce qu’est un percentile et beaucoup d’autres choses. Bref, un chapitre en douceur mais solide, épaulé par une trentaine de références bibliographiques.

En débutant le chapitre 2, j’ai été frappé par la gravure représentant la table des matières du chapitre. Le premier chapitre en avait une aussi, ainsi qu’en fait tous les chapitres du livre ! Modèles de données et langages de requêtes sont au menu de ce chapitre diablement passionnant. Non seulement on rentre en profondeur dans les structures des différents modèles de données et les paradigmes des langages de requêtes, qu’ils soient déclaratifs ou impératifs, mais l’auteur nous donne un éclairage historique remontant au Codasyl. Brillant.

Lire la suite

Note de lecture : Site Reliability Engineering, par Betsy Beyer, Chris Jones, Jennifer Petoff & Niall Richard Murphy edt.

Note 4 ; Les bases d’une nouvelle discipline au milieu d’essais assez hétéroclites.

Le SRE est l’une des nouvelles tendances du moment. Elle figure le pendant « run » du devops de manière générale, mais reste parfois difficile à distinguer aussi clairement. Le présent ouvrage a mis en lumière cette nouvelle discipline, aussi pourrait-on le qualifier « d’historique ». Dans les faits, il s’agit avant tout d’un recueil d’articles. Malgré le travail éditorial effectué, il ne faut pas en attendre le niveau de cohérence d’un ouvrage classique.

Avec ses 475 pages rythmés sur 34 chapitres et structurés en 5 parties, l’ouvrage est une belle bête, au moins au niveau du volume. La première partie ne compte que deux d’entre-eux sur une vingtaine de pages et sert d’introduction aux parties suivantes. « Introduction » est d’ailleurs le titre du 1er chapitre. Celui-ci nous esquisse en quelques lignes ce qu’est le SRE chez Google. Car j’ai oublié de préciser qu’il s’agit d’articles en provenance de Google. Le second chapitre ne se situe guère en continuité car il évoque l’environnement de production. Cette infrastructure est gérée par « Borg » qui n’est pas moins que l’ancêtre de Kubernetes !

La seconde partie assoie les principes du SRE. Elle compte 7 chapitres pour un total de 75 pages. Elle débute par un chapitre 3 qui a pour but de nous donner un éclairage « risques ». C’est surtout la notion de budget d’erreur qui y est important. Le chapitre 4 aborde une notion clé du SRE : le SLO pour Service Agreement Objective, que Google préfère au SLA. Les auteurs nous expliquent comment construire ces SLO par rapport aux SLI (« I » pour indicateur), et ce par l’exemple. Un bon chapitre. Le chapitre 5 est consacré au labeur, que l’on pourrait aussi appeler travail de m… Surtout ce chapitre entrouvre un aspect majeur du RSE : Google emploie pour ce travail des développeurs plutôt que des ingénieurs système car l’objectif est d’éliminer ou automatiser tout cela plus que d’effectuer des corrections !

Lire la suite

Note de lecture : Team Topologies, par Matthew Skelton & Manuel Pais

Note : 9 ; Un framework résolument Lean et pragmatique pour repenser l’organisation IT du 21ème siècle à la lumière de la loi de Conway. Book of the year 2020 !

Existe-t-il des règles ou des guides pour structurer une organisation en équipes selon des principes agiles ? On ne manque certes pas de textes qui, en cherchant à investir le domaine de l’organisation nous abreuvent de principes aussi flous que péremptoires. Mais dès qu’il s’agit d’entrer dans le concret, il n’y a plus rien, si ce n’est la « loi de Conway » qui accuse maintenant plus de 53 ans ! C’est bien à ce sujet que s’attaquent les auteurs. Ils s’appuient justement sur la loi de Conway pour développer le modèle qu’ils proposent et développent dans ces pages.

L’ouvrage n’est guère imposant avec son moyen format et ses 185 pages toutefois imprimées en couleur ! La lecture est rythmée par 9 chapitres rassemblés en 3 parties. Mais n’oubliez pas de lire d’abord la préface qui vous livre le modèle « team topologies ». La première pépite est ici. La première partie, elle, couvre une soixantaine de pages sur 3 chapitres et annonce la couleur en s’intitulant « l’équipe comme moyen de livrer ». Le premier chapitre serait plutôt une chasse aux anti-patterns, ou plus exactement aux organigrammes organisationnels : Ils ne prennent pas en compte les lignes de communication et sont un obstacle au flux.

Le second chapitre est consacré à la loi de Conway, ou plutôt à ce qu’il coutume d’appeler « la manœuvre Conway inversée », où comment organiser ses équipes en fonction de l’architecture que l’on souhaite. Et dans le cas présent, il est beaucoup question de microservices et d’équipes « orientées flux » qui sont la pierre angulaire de l’approche. Le chapitre n’est pas simple à suivre et cela va encore se complexifier au chapitre 3. C’est l’équipe, au singulier, qui est l’objet du chapitre. Le focus est très clair ici : favoriser la formation d’équipes dans la durée en limitant leur taille en se conformant au « nombre de Dunbar ». Mais il s’agit alors de limiter le nombre de domaines (et surtout de domaines complexes à confier à l’équipe.

Lire la suite

Note de lecture : Kafka : The Definitive Guide, par Neha Narkhede, Gwen Shapira & Todd Palino

Note : 7 ; Pour comprendre réellement Kafka, par ceux qui l’ont fait… Mais probablement hélas dépassé.

Voici un ouvrage qui, s’il n’est peut-être pas le « definitive guide » qu’il promet d’être (je reviendrais là-dessus) va nous permettre de réellement appréhender ce qui est aujourd’hui l’un des joueurs dominant du monde du big data. Qui de mieux placé pour cela que l’équipe qui fut à l’origine du projet chez LinkedIn ? C’est la promesse du livre et elle est bel et bien tenue.

Justement le texte, parlons-en. Ilse présente en 11 chapitres totalisant 280 pages. Il débute classiquement par un premier chapitre « Meet Kafka » qui nous présente la bête en 16 pages. En fait il fait bien mieux qu’une simple présentation. Certes, il évoque les principes généraux du middleware orienté messages, mais surtout ce chapitre permet d’appréhender le principe de la rétention basée sur le disque. Partitionning, réplication et mirroring sont aussi abordés mais ils seront plus développés par la suite. L’installation de Kafka est au cœur du second chapitre. Ou pas exactement, en fait. Certes, le chapitre aborde de manière bien décomposée l’installation de Kafka, mais aussi de Zookeeper. Mais ce qui occupe la plus grande partie des 20 pages de ce chapitre est consacré à la configuration du broker, mais aussi du cluster jusqu’à des questions assez délicates liées à la JVM ou aux écritures sur disque. En réalité, la configuration de Kafka va bien plus loin que cela, mais on est déjà largement au-delà du niveau « premier contact » !

Au chapitre 3, nous nous frottons à l’écriture d’un « producteur », c’est-à-dire de l’alimentation de Kafka, et ce via du code Java. J’ai bien aimé les extraits de code, ni trop courts faute de quoi il nous manque le contexte, ni trop long quand le code utile est noyé dans une litanie. La partie est plutôt complète, intégrant bien sûr la construction et l’envoi d’un message, puis intégrant progressivement, la configuration, la sérialisation avec Avro puis finalement le partitioning. Un régal. Le chapitre 4 lui fait écho en nous livrant le même exercice côté consommateur. Et l’on va assez loin, je dois dire : désérialisation, bien sûr, mais aussi rebalancing, groupes de consommateur et gestion de l’offset de lecture (qui est bel et bien un élément important à gérer côté consommateur).

Lire la suite

Note de lecture : Agile Conversations, par Douglas Squirrel & Jeffrey Frederick

Note : 5 ; Des cadres de conversation essentiels, mais difficiles à appréhender !

Les transformations agiles ne sont pas seulement le fait d’adoption de pratiques, elles passent par des conversations qui favorisent le changement de culture. C’est tout l’objet de ce texte. Il ne s’agit pas de n’importe quelles conversations, mais d’un processus, d’une progression entre 5 types de conversation.

Avec moins de 190 pages et un format réduit, il a tout d’une lecture légère. Mais il n’en est rien, la prose ne s’avale pas d’un trait. L’ouvrage est composé de 2 parties très inégales. La première a une nature plutôt introductive et ne compte que 2 chapitres totalisant 50 pages. Le premier d’entre eux, escaping the software factory est une simple introduction à l’agilité, au lean et au devops. Il a le mérite de poser les principes de ces 3 courants de pensée, avec une mention spéciale aux principes du devops que l’on ne rencontre pas souvent écrits. Le second chapitre « improving your conversations » est une introduction à la seconde partie. Les types de conversation décrits dans cette seconde partie obéissent tous au cadre des « 4 Rs » décrit ici. C’est pour faciliter les deux premiers Rs (record & reflect) que les auteurs utilisent le format de conversation sur 2 colonnes utilisé par la suite et détaillé ici.

La seconde partie propose 5 types de conversations qui forment autant de chapitres. Ils sont à prendre dans l’ordre, car ils forment un édifice où une conversation sert de base à la suivante. Le chapitre 3 nous propose la conversation de la confiance, qui est bel est bien la fondation de l’édifice agile. Le cœur de cette conversation est le « TDD for people », un cycle délimité par l’action et l’observation, mêlant croyance, hypothèse est sens. C’est un concept plutôt difficile à appréhender et plus encore à adopter. Prévoyez de le relire deux ou trois fois.

Lire la suite