Note de lecture : Spring Microservices in Action, par John Carnell

Note : 7 ; Il reprend là où « Spring Boot in Action » s’arrête…

Effectivement, « Spring Boot in Action » m’avait laissé sur ma faim. C’est essentiellement parce qu’il se focalisait sur la construction d’une application MVC, nous laissant un peu démuni sur la construction d’un serveur Rest, qui constitue pourtant l’un des cas d’usage nominaux. C’est bien sur ce cas d’usage et pas un autre que se focalise ce volume. Mais il va plus loin en couvrant l’intégralité de l’architecture microservices grâce à la stack Neflix et à son intégration dans Spring.

Je commence à froncer les sourcils à partir de 300 pages, mais les 350 de celui-ci se digèrent assez bien, malgré des chapitres aussi en moyenne plus volumineux que ce que j’apprécie généralement : ce volume en compte 10. Les 35 pages de l’introduction s’avalent très bien, on y a droit à une vue générale de l’architecture des applications microservices avec Spring Boot. C’est à la fois plus concret que ce que l’on croise généralement et aussi fort bien illustré, une constante du livre. Certes on n’a pas produit de code (mais l’auteur nous en dispense des fragments) mais on a un plan précis de ce qui nous attends.

La trentaine de pages du chapitre 2 nous amène vers le « hello world » du microservice et même un peu plus loin avec un certain nombre de considérations liées au déploiement. Tout cela s’avale très bien et on peut déjà se salir les mains avec succès. Cela dit, moi j’aurais fait deux chapitres… C’est également une trentaine de pages qui nous attends avec le chapitre 3, où l’on prend de plein fouet la stack Netflix, plus exactement, Eureka, à partir duquel l’auteur nous amène à construire un serveur de configuration. L’architecture de déploiement prends soudain beaucoup plus de complexité, mais c’est somme toute le destin des architectures microservices.

Lire la suite

Publicités

Note de lecture : Building Microservices, par Sam Newman

Note : 7 ; La promesse tenue d’un tour d’horizon ni trop technique, ni stratosphérique.

Cet ouvrage est déjà la référence sur l’architecture Microservices, donc de fait un préalable à mes autres lectures sur le sujet ! Le texte en lui-même est de taille moyenne, avec 250 pages structurées en 12 chapitres. Le propos n’est pas de rentrer ici dans des arcanes techniques, mais de rester à un niveau architectural concret, mettant en œuvre des patterns spécifiques à ce type d’architecture. C’est donc un bon deal.

Le premier chapitre est assez succinct et reste à très haut niveau : pourquoi fait-on des microservices ? Quelles en sont les propriétés principales ? Quels sont les bénéfices attendus ? Si l’on ne retrouve pas le thème de l’hétérogénéité technologique ailleurs (une propriété pourtant importante), les autres se retrouvent égrenés au long des autres chapitres : résilience, scalabilité, alignement sur l’organisation, facilité de déploiement ou de remplacement et composabilité. Le chapitre 2 est plus inattendus, car il s’intéresse au rôle de l’architecte. Un rôle bien mal défini et qui n’a rien à voir avec le rôle des architectes certifiés du génie civile, comme le fait remarquer l’auteur ! C’est en tant que « architecte évolutionnaire » que Sam Newman conçoit ce rôle, à cheval entre la vision et la gouvernance (zoning du domaine, alignement stratégique), mais aussi humain à travers la capitalisation de pratique et la collaboration avec l’équipe. Au final un chapitre qui est une heureuse surprise.

Le chapitre 3 est court d’une dizaine de pages : comment modéliser un service. Ici, l’auteur fait un lien naturel avec les « bounded contexts » du Domain-Driven Design. Mais il évoque aussi un sujet que l’on retrouvera plus loin : le découpage en microservices se fait par split de services ou applications de plus forte granularité. Le chapitre 4 est lui le plat de résistance de l’ouvrage : l’intégration ! J’en retiens plusieurs éléments : tout d’abord la mise en œuvre de chorégraphie distribuée via des évènements plutôt qu’une orchestration centralisée. Des appels synchrones qu’il faut rendre simples et agnostiques. Si je ne suis pas d’accord avec l’avis de l’auteur pour qui SOAP est protocole dépendant et REST protocole indépendant (désolé, mais c’est l’inverse), je trouve intéressant son appréciation de XML par rapport à Json, qui n’est pas dans l’air du temps. Bien sûr qui dit asynchronisme des évènements dit transaction distribuées ou mécanisme de compensation, des sujets ici tout juste évoqués, tout comme le versionning sémantique.

Lire la suite

Note de lecture : Le Pouvoir des habitudes, Charles Duhigg

Note : 8 ; Une saga aussi bien écrite que puissamment documentée sur les neuromécanismes des habitudes.

Charles Duhigg est journaliste, lauréat du Pulitzer qui plus est. Cela se ressent dans le style très percutant texte. L’auteur explore un aspect simple du comportement humain : la plupart de nos actions sont gouvernées par des habitude. Si ce n’était pas le cas, nos actions seraient sans cesse paralysées par la nécessité de prendre des décisions réfléchies pour les choses les plus simples. Mais ces actions ont aussi des effets collatéraux bien plus importants sur notre mode de vie. Donc changer les habitudes clés permet des changements radicaux. Le texte va investiguer le sujet à 3 niveaux : le niveau individuel, celui des entreprises et enfin au niveau sociétal !

La première partie est consacrée aux habitudes individuelles. L’auteur s’appuie sur deux histoires essentiellement : la (triste) histoire d’Eugene Pauly et celle du fonctionnement des alcooliques anonymes ! Ce que nous enseigne ces deux histoires et que confirme les analyses en IRMf, c’est que notre cerveau se « met en veilleuse » quand il détecte le déclencheur d’une habitude. Ici, l’auteur nous expose le grand pattern de son ouvrage : le cycle « déclencheur – routine – récompense ».

Pour changer ses habitudes, l’auteur nous montre la manière dont on peut substituer une routine différente à un même déclencheur aboutissant à la même récompense. Bien sûr, c’est plus facile à dire qu’à faire et cette substitution doit être épaulée par des mécanismes de renforcement, comme celui que confère les groupes de soutien pour les AA.

Lire la suite

Note de lecture : Streaming Data, par Andrew G. Psaltis

Note : 7 ; Data Streaming Distiled !

Le livre est réellement une bonne surprise. Il attaque la question du streaming par l’architecture. L’auteur a son opinion sur la question et nous propose sa vision de celle-ci dès son chapitre d’introduction. Les composants de cette architecture formeront la trame de la première partie du texte.

Passé le chapitre d’introduction sur l’architecture générale, le second chapitre adresse le volet « ingestion ». La bonne surprise est de voir l’auteur l’aborder sous l’angle des patterns avec leurs avantages te leurs faiblesses plutôt que de plonger dans des considérations techniques. Au-dessus de cela le texte s’arrête également sur la tolérance aux pannes avec d’autres patterns de gestion de logging précieux et clairement expliqués.

C’est au data pipeline, donc au Queuing que s’intéresse le chapitre 3, en commençant par exposer son utilité face aux variation de production et au besoin d’élasticité du scaling. Les 3 sémantiques de gestion de message sont bien adressées. J’ai cependant trouvé que le propos reprenait des éléments vraiment très élémentaires mais ne rentrait pas des problématiques telles que la sécurité (l’auteur nous renvoie vers un ouvrage de référence). Là encore les problématiques de tolérance aux pannes spécifiques à cette couche sont bien détaillées.

Lire la suite

Scrum Guide 2016

En mettant un peu d’ordre dans mes anciens posts, je me suis aperçu que j’avais bien mis en ligne et commenté la version 2013 du Scrum Guide, mais que je n’avais pas dit un mot de la version 2016. Il faut dire que cela fait un bon moment que je n’ai plus publié autre chose que des notes de lecture…

Les valeurs de Scrum

La version 2016 compte 1 page supplémentaire. On arrive assez vite à la section qui a été rajoutée: les valeurs de Scrum ! Les 5 valeurs d’ailleurs évoquées depuis longtemps prennent enfin place dans le guide officiel, signe que Scrum se focalise de plus en place sur son essence et moins sur le folklore.

Et quoi d’autre ?

En fait, la surprise est que pour le reste, le texte reste mot pour mot celui de l’édition 2013 ! Il faut un peu chercher pour comprendre la réelle nouveauté de cette édition : le copyright figurant au bas de chaque page ! Certes, c’est un « creative commons », mais quand même…
Je pense que les auteurs auraient pu faire un peu plus d’effort que cela…

Note de lecture : Scrum 4ème édition, par Claude Aubry

Note : 6 ; Le texte progresse, mais pas assez et surtout pas assez dans la bonne direction pour moi !

Mon principe de base est simple : pour une nouvelle édition, si le texte ne progresse pas, la note baisse ! Pourtant du changement, il y en a et oui, j’ai fait baisser la note. Que s’est-il passé ?

Le volume de l’ouvrage n’a guère changé : 294 pages contre 291 pour l’édition précédente. Mais le découpage est passé de 20 à 22 chapitres, ce qui augure de l’ampleur des changements.

Le premier chapitre est passé de 10 à 14 pages avec un contenu complètement revu en bien, il fait d’ailleurs référence à ma présentation « Scrum Shu Ha Ri » et est moins méthodologique que dans l’édition précédente. Même taille pour le chapitre 2, mais lui aussi profondément remanié. Le concept de Sprint est mieux abordé mais il n’y a guère de différence sur le fond. Notamment, il y a ce concept de release dont je pense qu’il serait temps de le laisser tomber. Nous y reviendrons.

Lire la suite