Note : 3 ; Verbeux et ennuyeux

La juxtaposition de « patterns » (ou anti-patterns) et devops avait tout pour attiser ma curiosité, bien que j’avoue avoir quelque peu foncé en aveugle sur ce livre. Comme nous le verrons, cela ne fut pas une très bonne idée car le texte prétend parfois avoir inventé l’eau chaude…

Avec 290 pages structurées en 12 chapitres, ce volume se situe dans la moyenne, la taille des chapitres aussi et ceux-ci ne sont pas trop longs. Le livre s’ouvre sur un premier chapitre « what is devops » plutôt sympathique à lire qui évoque le CAMS (culture, automation, metrics et sharing) comme les piliers du devops. C’est original par rapport à mes autres lectures, mais l’éclairage en vaut un autre. Le second chapitre est plus représentatif des chapitres suivants, c’est-à-dire un thème accompagné de patterns et d’anti-patterns. Ici il est question de « paternalisme ». Derrière cela il faut voir le mode guichet et les délais que cela occasionne. La solution promue est évidemment l’automatisation embarquant les vérifications automatisant « l’approbation ». Rien de bien nouveau.

Le thème du 3ème chapitre est la cécité opérationnelle : c’est-à-dire qu’opération et développement vivent chacun dans leur silo et que le développement ignore tout du comportement du produit en production. La solution est ici, cher captain obvious, les métriques et les logs ! Le développement part un peu dans tous les sens et reste hélas assez superficiel. Le chapitre 4 s’intitule « des données plutôt que de l’information ». Ce chapitre se démarque un peu des précédents en ne suivant pas la recette désormais habituelle. Il s’inscrit plutôt dans la continuité du chapitre 3 en évoquant la présentation des données de monitoring. C’est un peu inutile ou plutôt mieux traité ailleurs.

Lire la suite →

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 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 : 7 ; Une intrigue passionnante pour illustrer les « 5 idéaux » de l’auteur.

Gene Kim est co-auteur de plusieurs ouvrages gravitant autour du devops, dont « The Phoenix Project », un texte romancé s’inscrivant dans la continuité de « The Goal » D’Eli Goldratt. Cette fois, il vole en solo de nouveau sur un texte romancé dont l’intrigue s’entrelace avec celle de The Phoenix Project.

La prose occupe un peu plus de 330 pages d’un texte rythmé sur 19 chapitres, mais ceux-ci servent surtout à rythmer l’histoire. Ce sont plutôt les 3 parties qui sont le découpage important. Nous avons droit à une vingtaine de protagonistes dans cette histoire, mais tous n’ont pas la même importance. Nous suivrons surtout Maxine Chambers, « placardisée » au projet Phoenix en servant de bouc émissaire pour un grave problème survenu alors qu’elle était en vacances. Kurt Reznick à la tête de la « Rebellion team » est aussi un personnage majeur, tandis que Sarah Moulton joue le rôle de la méchante. Nous retrouvons aussi épisodiquement Erik Reid du livre précédent, dans un rôle assez curieux. A titre personnel, j’ai bien aimé la présentation « Star Trek » des protagonistes.

Le début est assez lent. Nous assistons surtout durant les 4 premiers chapitres aux affres de Maxine arrivant au sein du Phoenix Project, paralysée par une organisation silotée et procédurière. Ce n’est qu’au chapitre 5 que nous découvrons la Rebellion Team. De manière générale, cette première partie développe largement les dysfonctionnements qui peuvent être observées dans ce type d’organisation. Le paysage dressé, ou la vision d’horreur devrais-je dire, l’est avec beaucoup de détails et de réalisme, mais on n’y apprend rien. Cette première partie introduit toutefois dans ses dernières pages, les « 5 idéaux » qui forment la colonne vertébrale du texte.

Lire la suite →

Note : 9 ; Actualisé et repensé, mais toujours aussi riche et pertinent !

11 ans se sont écoulés depuis la parution de la première édition. De mon point de vue, c’était le premier vrai texte évoquant la culture devops. A vrai dire, j’ai continué à le considérer ainsi jusqu’à la parution de cette nouvelle édition. De prime abord, celle-ci semble avoir subi une cure d’amaigrissement… en fait, c’est le papier qui est plus fin, car celle-ci compte le même nombre de pages, mais réparties en 17 chapitres (au lieu de 18) sur 3 parties. Il s’est passé des choses en 11 ans, et nous allons voir que le texte le reflète bien.

Le chapitre d’introduction n’a guère bougé dans son essence avec son fameux « un million par ci, un million par là… », mais sa forme a été remaniée. La première partie « create stability » compte aussi toujours 4 chapitres. Je retrouve au chapitre 2 la même histoire horrible de l’exception qui a mis un aéroport en rideau. L’erreur dans le code est visible sans être grossière, mais les conséquences sont catastrophiques. L’ambiance est campée pour ce livre emblématique. Le chapitre 3 développe sur cette base la notion de « cracks propagation » en faisant référence au livre de James Chiles « Inviting Disaster ». Je ne retrouve pas dans ce chapitre le diagramme de patterns de l’édition précédente : dommage.

Au chapitre 4, on retrouve les antipatterns de stabilité. C’est un chapitre particulièrement conséquent avec 60 pages. Sa structure épouse celle de l’édition précédente, mais le propos est sensiblement modernisé dans cette seconde édition. Cela dit, j’avais trouvé l’édition précédente plus pédagogique à cet égard. L’auteur semble avoir voulu gagner en efficacité dans son propos. Cela a un prix. Après les antipatterns, les patterns. Ils sont présentés au chapitre 5. Les patterns sont les mêmes d’une édition à l’autre, mais l’auteur a fait le choix de les modifier dans le détail. L’ensemble est un peu modernisé sans que la différence soit notable.

Lire la suite →

Note : 5 ; De bonnes histoires et d’excellents principes mais un manque d’unité.

Le but inavoué de ce livre était d’être la référence sur le devops. J’en veux pour témoin l’impressionnante liste de noms à l’affiche. Les auteurs de « IT Rev » ont développé leur vision du Devops déjà ébauchée dans « The Phoenix Project », il s’agit des « 3 voies » dans la pure lignée de la pensée Lean. Ce livre est consacré au développement de cette idée.

Le livre lui-même est de format un peu plus réduit qu’à l’accoutumé, mais il atteint les 350 pages hors annexes (celles-ci en ajoutent 100 de plus), le volume de matière est donc conséquent. L’ensemble est découpé fin : on compte 23 chapitres rassemblés en 6 parties. La première d’entre-elle est consacré aux 3 voies. 4 chapitres sur 45 pages couvrent le sujet. L’introduction et le premier chapitre donnent les grandes lignes du devops, ce qui pourrait se résumer à la réduction du lead time.

Les 3 chapitres suivants de cette première partie sont chacun consacré à une des voies des fameuses 3 voies. Le second chapitre est ainsi consacré au « flow ». Sans surprise, on retrouve ici les principes du Lean appliqué au Kanban : taille des lots, élimination du gâchis, etc. Toutes choses permettant à la fois de réduire le temps de cycle et de donner de la fluidité au processus. Le second chapitre attaque le principe du feedback. Il est plus vague, évoquant le Andon et le déplacement de la qualité vers le développeur. Enfin le chapitre 4 nous parle d’amélioration continue, évoquant la culture « générative » au sens de Westrum. Les pratiques évoquées tournent autour de l’expérimentation et de la généralisation des découvertes locales.

Lire la suite →

Note : 4 ; De l’intégration continue à devops ! Des points de vue de grande valeur, mais bien trop verbeux. Jolt Award 2011 !

Ce livre fait en quelque sorte suite au « continuous intégration » publié dans la même série. Ici, l’orientation est résolument « devops », ou comment aller du développement à la mise en production. Aussi le livre ne s’articule pas seulement autour des problématiques techniques, mais aussi de processus et des activités garantissant la mise en production : tests unitaires, tests d’acceptance, gestion des releases, gestion des environnements, etc…

La première partie appelée « fondations » évoque tous les prérequis à la déliverie continue. On y parle de tests, de gestion de versions, etc… Bref de toutes sortes de choses que l’on connaît déjà et déjà détaillées par ailleurs. C’est un peu long et verbeux. On en prend pour 100 pages. Au premier chapitre on s’évertue de mettre en lumière la vue « ancienne » du release management. Pas si ancienne d’ailleurs, avec ses « RC1 », « RC2 », etc. On le fait à l’aide d’antipatterns un peu tarte à la crème, pour au final introduire les qualités attendues d’un bon pipeline d’intégration. Le chapitre 2, « configuration management » traite de deux sujets : la gestion de version, où les auteurs sont opiniated sur le développement en banche principale, et les informations de configuration qui doivent être externalisées. Les deux sujets seront repris plus tard. Ces prises de position, même si elles piquent un peu sont plus que sensées.

Une grosse trentaine de pages est consacrée à l’intégration continue. Pas de révolution ici, on reprend des principes désormais bien connus : un build court, ne jamais laisser un build cassé, raccourcir la boucle de feedback en lançant le build d’intégration au plus tôt. C’est un peu long pour dire des choses que l’on connait déjà et qui ne sont pas le cœur du livre. Je ne m’attendais pas nécessairement à voir évoquer la stratégie de test, mais c’est bien le sujet du chapitre 4 qui clôt la première partie sur une quinzaine de pages. Ce sont des pages bien dépensées cette fois, car les auteurs font le tour du sujet assez efficacement en suivant le framework de Brian Marrick. Cela dit, on est cette fois encore, un poil en marge du sujet.

Lire la suite →

Note 3 ; Malheureusement je ne suis pas un ops…

Je voulais vraiment en savoir plus sur CoreOS. Chemin faisant, je savais que je risquais une lecture qui pouvait s’avérer ennuyeuse pour moi, sinon hermétique. C’est surtout la brièveté de l’ouvrage qui m’aura permis de survivre, le texte n’étant vraiment pas fait pour moi.

Bref, le texte l’est avec seulement 175 pages et 10 chapitres (donc des chapitres assez courts en moyenne). L’ensemble est divisé en 3 parties. La première d’entre-elle « getting to know CoreOS » comprends 3 chapitres. Et on commence bien sûr par une introduction au système, d’une quinzaine de pages. Cette introduction doit nous donner une image de haut niveau de CoreOS, qui un OS « statique », dont les composants majeurs sont fleet et etcd. Mais pour moi, l’angle est déjà bien trop « système ».

Les 18 pages du chapitre 2 sont consacrées à faire fonctionner CoreOS sur une machine de dev, dans un environnement Vagrant, lui-même dans une machine virtuelle VirtualBox. En sachant que ce n’est pas un mais 3 CoreOs que l’on souhaite faire fonctionner, cela donne une idée de la configuration : pas vraiment une partie de plaisir pour moi. Je sombre encore un peu plus au chapitre 3 « expecting failure » qui rentre dans les arcanes d’etcd, le tout pimenté de configuration Ngnix !

Lire la suite →