🥡 The Tech Away | Issue #4

De la veille tech à emporter | Octobre 2024

Après une longue pause estivale, la newsletter reprend !

Au menu ce mois-ci :

• 👯Software Teaming : le même sujet, au même moment, au même endroit et sur la même machine

• 🐲 Revisitez vos pratiques d’architecture avec la théorie de la résidualité

• 🌇Amazon met fin à quelques services managés pendant l’été

• 🧠 NotebookLM, un nouveau service de Google qui va peut-être changer ma façon de faire de la veille 💡

• 🧠 AI agents invade observability: snake oil or the future of SRE? 🐍

---

👯Software Teaming : le même sujet, au même moment, au même endroit et sur la même machine

Cet été, je me suis rendu au Meetup Software Teaming qui s’est tenu à Paris et qui invitait Woody Zuill, une référence internationale sur le Software Teaming (aussi connu sous le nom de mob programming).

Le meetup a démarré par une demi-heure d’introduction aux concepts de coding dojo et de Software Teaming

Concepts et rôles lors de la pratique du Software Teaming

5 personnes du public ont ensuite choisi un langage de programmation pour réaliser un kata en Typescript en suivant les consignes de Software Teaming dispensées par Woody. Ce dernier a introduit le concept comme suit :

Get a team together, to work on the same thing, at the same time, in the same space, … and at the same computer ! (or many computers if you work remotely)

Pour l’avoir pratiqué dans de nombreux projets, je trouve que c’est une pratique efficace pour travailler sur des problèmes difficiles et éviter un coût de synchronisation fort lorsqu’il faut prendre des décisions structurantes (on prend la décision ensemble et on l’implémente ensemble, on s’épargne de devoir la ré-expliquer aux absents).

Même en étant familier avec la pratique, il était intéressant d’observer ce groupe travailler depuis l’extérieur et bénéficier des conseils et de la rigueur d’un expert qui commentait la situation.

Woody Zuill a partagé qu’il pratique toujours le Software Teaming en TDD, et qu’il le pratique souvent comme “mode de fonctionnement par défaut” : tous les jours pour toutes les tâches dans ses projets (et pas comme un outil ponctuel réservé à certains problèmes).

Et vous, est-ce que vous pratiquez le Software Teaming/Mob Programming souvent ?

---

🐲 Revisitez vos pratiques d’architecture avec la théorie de la résidualité

Cet été, j’ai lu le livre de Barry O’Reilly sur sa “théorie de la résidualité”, une approche différente de l’architecture.

Couverture du livre Residues: Time, Change, and Uncertainty in Software Architecture (Barry M O’Reilly)

Barry O’Reilly affirme que penser l’architecture logicielle comme une discipline d’ingénierie comme les autres (carrée, normée, prévisible, sur laquelle on pourrait se baser sur des plans à construire comme l’automobile, ou la construction d’immeubles) est une raison pour laquelle nos projets informatiques échouent :

Imagine the designer of a car. How would their work look different if the properties of asphalt, rubber, aluminum and gravity were constantly changing or subject to change at any minute? Automotive engineering would not look as it does today. Building architecture would also not look the same as it does today if the properties of concrete, steel, and gravity were disordered instead of ordered. However, software engineers have happily imported practices from these engineering disciplines without a second thought, and they are simply not applicable

Il explique que si l’ingénierie automobile ou l’architecture d’immeuble repose sur des éléments de contexte connus, mesurables et prédictibles, ce n’est pas le cas de l’architecture (au sens logiciel) qui évolue dans un système complexe et imprédictible: le métier.

Il ne pourra alors jamais suffire de se contenter de récolter des exigences (non-)fonctionnelles en début de projet ou de s’inspirer de recettes qui ont marché dans d’autres projets pour être certain de construire un produit qui va résister à des stresseurs imprévisibles (sociaux, économiques, politiques, …)

Selon lui, l’architecture doit être pensée comme une collection de résidus. Un résidu, c’est ce qu’il reste de notre architecture après qu’elle ait été exposée à un stresseur (quelques exemples: un compétiteur développe une fonctionnalité différenciante, notre application passe au journal télévisé et subit un pic de charge, le prix de l’euro dégringole, une guerre éclate, …).

On corrige alors le tir, itérativement, en faisant évoluer l’architecture pour survivre à ce stresseur, puis on applique de nouveaux stresseurs, itérativement, jusqu’à espérer atteindre la criticalité : un état de notre architecture où l’assemblage de résidus ayant ainsi émergé est tel qu’il devient de plus en plus difficile de trouver un nouveau stresseur capable de nuire durablement au système.

C’est un livre assez court, qui prend un angle scientifique (ça parle d’ergodicité, d’hyperliminalité, avec quelques formules en LaTeX ici et là) mais qui reste accessible. Il met le doigt sur des ressentis que j’ai pu vivre dans certains de mes projets, avec des situations ou des débats passés dans lesquels je me suis reconnu. C’est un livre qui se veut aussi pratique/activable avec des exemples et des outils présentés dans le dernier chapitre.

Si cette lecture vous intéresse, je vous recommande d’abord cet article d’Eric Normand qui résume bien ce livre, puis ce talk d’introduction de l’auteur de ladite théorie. S’il ne vous a pas assommé, alors peut-être que le livre peut vous intéresser :)

• 📝Residuality Theory : Good Idea, Bad Name (Eric Normand)

• 📚Livre Residues: Time, Change, and Uncertainty in Software Architecture (Barry O’Reilly, LeanPub)

#Stressor #Attractor #Residuality #Criticality #DeleuzianWalk #FMEA

---

🌇Amazon met fin à quelques services managés pendant l’été

Au détour de ma veille cet été, j’ai découvert cet article qui faisait une synthèse de quelques services managés arrêtés, ou bien à la fin de vie annoncée :

• SimpleDB: un service de base de données NoSQL que je ne connaissais pas, et qui semblait être une première version de DynamoDB

• Data Pipeline: un service pour construire des … data pipelines, à base de runners EC2 et EMR

• Cloud Search: un autre service que je ne connaissais pas non plus, qui semblait servir à créer des moteurs de recherche

• CodeCommit: la solution de versionning de code par AWS,

• Cloud9: un IDE dans le Cloud,

• S3 Select: un service bien pratique pour requêter des données présentes dans un bucket S3 en SQL-like

• QLDB: une base de données managée avec de la blockchain dedans,

• Forecast: un service de prédiction pour les time series

Si la fermeture de certains de ces services m’a surpris (comme S3 Select ou Cloud9), voici ce que je perçois de ces décisions :

• Peut-être qu’AWS redescend de la hype sur les technologies à base de crypto

• Peut-être qu’AWS se sent trop en retard dans la course à “l’environnement de développement du futur” vis-à-vis d’autres acteurs ou solutions plus avancées comme Gitpod ou Github CodeSpace

• Entre le nombre de services pléthoriques à maintenir (plus de 250) et leurs ambitions de frugalité, ce n’est peut-être pas étonnant de voir enfin ce portefeuille de services managés s’amincir

Et vous, vous connaissiez ces services ? Qu’est-ce que leur arrêt vous inspirent ?

• Disruption Ahead: AWS Quietly Axing Services

---

🧠 NotebookLM, un nouveau service de Google qui va peut-être changer ma façon de faire de la veille 💡

Cette semaine j'ai testé NotebookLM, un nouveau service de Google avec des vrais morceaux de LLM et de GenAI dedans.

📓 Il permet de construire des notebooks: rien à voir avec les Notebooks Jupyter, c'est à prendre au sens premier du terme (un cahier, ou un classeur de notes qui portent sur un thème)

🗃️ On peut mettre dans un notebook des fichiers présents sur notre poste ou des liens vers des sites web ou des vidéos youtube (jusqu'à 50 fichiers/lien par notebook), et le service permet de poser des questions à cette base de connaissance ainsi construite

Pour ceux qui parlent couramment l'IA, c'est un service qui permet "simplement" de construire des RAGs, mais de façon accessible pour le commun des mortels (et ça c'est chouette)

🗣️ La feature qui commence à changer ma manière de faire de la veille ? Une fois qu'on a déposé nos sources dans un notebook, une fonctionnalité permet de "générer un audio". Cela génère alors un podcast où 2 intervenants (homme et femme) discutent en anglais des documents que vous avez déposé pour les expliquer, et le résultat est vraiment bluffant

Ca m'est arrivé dans la semaine de créer un notebook avec juste 1 lien d'un article que je n’avais pas eu le temps de lire, et d'écouter le podcast dans le métro.

Un exemple ci-après, avec un audio généré à partir d'un article de Gregor Hohpe : Cloud Automation à la DDD

Et vous, vous avez testé NotebookLM ? Comment vous en servez-vous ?

• https://notebooklm.google/

#LLM #RAG #KnowledgeManagement

---

🧠 AI agents invade observability: snake oil or the future of SRE? 🐍

Ce mois-ci, j’ai lu cet article de Clay Smith qui s’interroge sur l’impact que les agents d’intelligence artificielle pourraient avoir sur les métiers de l’IT.

Si les articles parlant de l’impact de la #GenAI sur le métier de développeur sont légion, l’auteur s’intéresse ici à l’impact qu’ils pourront avoir sur les métiers d’Ops, de SRE (Site Reliability Engineer) ou sur les experts du monitoring et de l’observabilité.

🧠 Ainsi, de la même manière qu’il existe le SWEBench, pour mesurer la capacité d’une IA à résoudre une issue Github en produisant le code d’une fonctionnalité ou du code pour corriger un bug, je découvre dans cet article l’existence du SREBench: un benchmark pour mesurer la capacité d’un agent à identifier la root cause d’un incident dans un cluster Kubernetes ☸️

Avec ce genre de capacités en tête, l’auteur se projette alors dans le difficile exercice d’imaginer la plateforme d’observabilité du futur (d’ici ~5 ans) : là où la littérature aujourd’hui encourage comme bonne pratique de logger des événements structurés (des arbitrarily-wide structured log events selon le concept de “l’observabilité 2.0” décrit par HoneyComb), Clay Smith pense (avec un certain scepticisme) qu’il serait possible de construire un agent IA capable de se brancher à toutes sortes de sources de données non-structurées décrivant le système à observer pour corriger des incidents : code source, documentation d’entreprise (type JIRA), données de monitoring et télémétrie.

Source de l’image: AI agents invade observability: snake oil or the future of SRE? - Clay Smith

Et vous, vous misez plus sur des logs structurés ou sur des LLMs pour votre observabilité ?

#Observability #Observability2.0 #SREBench #SWEBench