Mois : octobre 2019

Note de lecture : Extreme Ownership, par Jocko Willink & Leif Babin

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Quand le leadership signifie assumer ses responsabilités.

Voilà un livre (lâchons le mot : un best-seller) qui ne va pas revendiquer comme s’alignant sur les principes agiles, et pourtant… Les auteurs nous proposent les leçons de leadership durement acquises et éprouvées sur le terrain : celui des Navy Seals au centre des combats les plus violents en Irak. Bien sûr elles s’exercent au sein d’une chaine de commandements militaire, mais les auteurs savent en extraire les pépites qui prennent sens dans l’organisation d’une entreprise « pour diriger et gagner » et dans une certaine mesure dans les contextes agiles.

Le texte pèse 312 pages en moyen format en comptant l’annexe (qu’il est recommandé de lire). Les 12 chapitres empruntent tous le même format : la narration d’un épisode de la vie des Navy Seals, la plupart en zone de combat, sur plus de la moitié du chapitre. Puis un exposé du ou des principes mis en avant dans le chapitre, sur une à 3 pages. La fin du chapitre est dédiée à l’application du principe au monde de l’entreprise via un story-telling issu d’une expérience postérieure aux Navy Seals, dans l’accompagnement de managers via la société de conseil crée par les auteurs : Echelon Front.

Les 12 chapitres sont répartis sur 3 parties avec la régularité d’un papier à musique. Donc 4 chapitres par partie, à l’exclusion d’une introduction. Celle-ci n’emprunte pas la structure précédemment décrite mais décrit l’entrainement des Navy Seals afin de véhiculer un seul message : le leadership est l’unique facteur réellement important. La première partie s’intitule « gagner la guerre de l’intérieur ». Elle s’ouvre par le chapitre qui donne son nom à l’ouvrage : « extreme ownership ». Le message est simple : quoi qu’il arrive au sein de l’unité organisationnelle du manager, celui-ci doit assumer la responsabilité de tout ! Le second chapitre s’intitule « pas de mauvaises équipes, seulement de mauvais leaders ». J’en retiens une phrase forte : le standard de votre organisation, ce n’est pas ce que vous prêchez, c’est ce que vous tolérez. En corollaire, la responsabilité du leader est envers l’équipe avant d’être envers les individus.

Lire la suite →

Note de lecture : Testing Microservices with Mountebank, par Brandon Byars

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Une guide d’utilisation de Mountebank par son créateur. Bien écrit, mais assez basique

Mountebank est un framework de test (encore un) bien adapté au test des microservices, utilisant comme l’auteur nous le développera, le principe de l’imposture ! Malheureusement pour moi, la bête s’utilise avec du code JavaScript (avec du Node.js pour être précis), un obstacle que je n’avais pas anticipé. Cela a certainement impacté la note, dommage car le principe de ce moteur de test qui permet de simuler les services environnant au runtime ouvre nombre de perspectives.

Reprenons au départ : le volume se présente sous forme d’un texte de près de 220 pages découpé en 3 parties totalisant 10 chapitres. La première partie « premières étapes » ne compte que 2 chapitres sur 40 pages. Le premier chapitre « testing microservices » campe le décor. Il positionne clairement cet outil sur le volet « end to end » et introduit les notions de prédicats et d’imposteurs qui seront clé par la suite. Le second chapitre est le « hello world » … mais il s’avère rapidement être plus que cela. Il commence doucement en requêtes curl et en json, mais bascule rapidement sur le JavaScript ! L’auteur brûle un peu les étapes.

La seconde partie compte 6 chapitres et s’étend sur 130 pages. C’est le gros de la troupe et il est d’ailleurs sobrement intitulé « using Mountebank ». Il s’ouvre au chapitre 3 par le concept de réponses préfabriquées (canned responses), ce qui nous amène aussi à évoquer les prédicats. C’est plutôt clair et bien illustré. Les prédicats sont justement le sujet du chapitre 4. On les aborde en commençant par les expressions régulières pour terminer avec le JSonpath en passant par les champs multivalués. Le chapitre est riche et clair la plupart du temps.

Lire la suite →

Note de lecture : Microservices Patterns, par Chris Richardson

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; La bible du Microservice !

A beaucoup de points de vue, c’est un livre imposant ! D’abord par sa taille : 470 pages, découpées en seulement 13 chapitres, mais aussi par son contenu qui va assez loin dans les aspects techniques abordés. Le propos n’en reste pas moins clair, je regrette juste que les fameux patterns soient juste évoqués mais pas vraiment documentés en tant que tel.

Le premier chapitre couvre une trentaine de pages et aborde deux sujets : le monolithe et les patterns. Le monolithe est traité avec intelligence, loin du bashing habituel. Ici on part du postulat d’une architecture hexagonale pour explorer les conséquences en maintenance et en organisation d’équipe ! La big picture des patterns vaut aussi le détour, pas seulement pour la classification de ces derniers, mais aussi par la qualité de l’explication sur l’approche patterns.

Ce sont aussi une trentaine de pages consacrées au chapitre 2 sur les stratégies de décomposition. On y parle, et c’est un peu inattendu, UML, Use Cases et DDD. C’est aussi le moment pour l’auteur d’exposer sa vision du découpage en « capabilities » et « services ». C’est intéressant, de bon niveau même, mais pas flamboyant.

Les choses sérieuses commencent au chapitre 3 et ses 45 pages sur l’IPC qui en est le sujet ! Il couvre les aspects conceptuels tels que la définition des interfaces, le versionning et les transactions. Puis on rentre dans le dur avec la communication synchrone (ReST, gRPC), puis asynchrone (JMS, Kafka), en publication ou en requête / réponse. Le chapitre s’étend jusqu’aux patterns essentiels que sont le circuit breaker et le gateway. C’est du solide.

Lire la suite →

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

Le par addinquydans Notes de lectureLaisser un commentaire

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 →