Mois : juin 2021

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

Le par addinquydans Notes de lectureLaisser un commentaire

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 →
Publicité
Le par addinquydans CitationsLaisser un commentaire

The multiplicity of the design space constantly confuses apprentice designers. Given a software design problem, what’s a good solution to it? Events? Objects? Observers? Callbacks? Virtuals? Templates?… The most important difference between an expert software architect and a beginner is the knowledge of what works and what doesn’t.

Andrei Alexandrescu

 

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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 →

Note de lecture : Introduction to Apache Flink, par Ellen Friedman & Kostas Tzoumas

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Apache Flink pour les executives.

Voici un petit traité qui promettait d’en savoir plus sur Flink en 6 chapitres et à peine une centaine de pages. Le texte me laisse quelque peu sur ma faim, me donnant plutôt l’impression d’un ouvrage dédié aux « executives ».
Le premier chapitre cherche à répondre à la question fondamentale « pourquoi Apache Flink » en 18 pages. On y répond surtout au « pourquoi le streaming processing » dans la première moitié, mais le chapitre se rattrape un peu en donnant les clés du positionnement de Flink par rapport aux autres frameworks de streaming. Bienvenu également, la vue aérienne des API et des librairies sus-jacentes qui expose les vues « batch » et « streaming » de Flink. Mais ce chapitre présente surtout les différents cas d’usages dans différents domaines.

Le second chapitre est d’avantage consacré aux aspects architecture, et met en lumière l’articulation transport / processing. Au moins le propos clarifie l’importance de Kafka dans ce contexte. Mais il manque quand même cruellement de précisions plus concrètes : le reste du texte donne quelques schémas de très haut niveau et d’autres cas d’usage. J’aurais préféré une vision dynamique des fonctionnements en mode stream et batch.

Au chapitre 3, nous allons voir ce que Flink fait. Le sujet est abordé sous l’angle des caractéristiques du framework : gestion des fenêtres glissantes, des états et des « checkpoints ». Littéralement, le chapitre répond bien à ce que fait Flink, mais sans laisser transparaître « comment » il le fait ce qui est quelque peu frustrant.

Lire la suite →