🥡 The Tech Away | Issue #3
De la veille tech à emporter | Juin 2024
Au menu ce mois-ci :
⛈🎇 Google détruit par inadvertance la souscription Cloud d’UniSuper, un fond de pension Australien évalué à 125 milliards de $$
💸Comment vous pouviez couler votre concurrence chez AWS avec une simple requête HTTP ce mois-ci
🚣🐇 Suivre ses métriques de performance de delivery DORA avec Apache DevLake
🎙️Software delivery stories - Westrum Organizational Culture
🎄Continuous Discovery : modéliser l’espace des opportunités avec un opportunity solution tree
📘 The Software Guidebook - la 7e partie va vous surprendre
⛈🎇 Google détruit par inadvertance la souscription Cloud d’UniSuper, un fond de pension Australien évalué à 125 milliards de $
Les clients d’UniSuper ont dû vivre une semaine assez stressante ce mois-ci, puisqu’ils étaient dans l’incapacité de consulter pendant cette durée le solde de leur pension de retraite, où certains australiens y mettent les économies de toute une vie
La raison ? Google déclare avoir malencontreusement supprimé toute la souscription Cloud d’UniSuper lors d’une opération qui a aussi détruit leurs back-ups de données, y compris les back-ups des back-ups répliqués dans une autre région 😱
Dans une déclaration conjointe avec Google, UniSuper affirme avoir rétabli ses services sans pertes de données grâce à des back-ups supplémentaires hébergés auprès d’un autre Cloud provider
Et vous, vous jouez vos procédures de disaster recovery à quelle fréquence pour vérifier que tout marche comme prévu™️ ?
💸Comment vous pouviez couler votre concurrence chez AWS avec une simple requête HTTP ce mois-ci
Début mai, les internets s’affolaient de découvrir qu’Amazon facturait à ses utilisateurs les requêtes non-authentifiées sur les buckets S3.
Ainsi, il suffisait à un concurrent mal intentionné ou un peu farceur connaissant le nom d’un de vos buckets de faire ceci en boucle :
$> aws s3 cp ./file.txt s3://your-bucket-name/random_key;
Sans authentification, la commande est évaluée en AccessDeniedError (HTTP 4XX) pour l’émetteur de la requête … et en $0.005 pour le propriétaire du bucket
AWS a dû s’exprimer le 7 mai pour confirmer que ce comportement devait changer.
S3 engineers are working to make unauthorized requests that customers did not initiate free of charge — Jeff Barr (AWS), le 7 mai
Il ne fallait pas cligner des yeux : depuis le 13 mai, la documentation d’AWS mentionne désormais que les propriétaires de buckets S3 ne paieront plus pour ce genre de requêtes.
1 semaine pour passer de l’idée à la production, c’est rapide, et ça fait une transition toute trouvée pour le sujet suivant 👇
🚣🐇 Suivre ses métriques de performance de delivery DORA avec Apache DevLake
Ce mois-ci, j’ai découvert un nouveau projet open-source incubé dans la fondation Apache et qu’il me semble intéressant de suivre de près : Apache DevLake.
La proposition de valeur de ce projet est de fournir des dashboards Grafana ainsi que des connecteurs (à Github, Gitlab, CircleCI, Jira, SonarQube, ...) pour pouvoir monitorer et consulter les 4 métriques clefs qui permettent, selon le DORA, de mesurer la performance d’une équipe de delivery :
les 2 métriques de vélocité : la fréquence de déploiement et le lead time,
les 2 métriques de stabilité: le change failure rate et le temps (moyen ou médian) de remise en service (MTTR)
C’est un projet que je compte suivre de près car c’est en effet un besoin récurrent dans mes projets de mesurer ces indicateurs (du DORA ou d’autres indicateurs de la santé du projet), des fois manuellement et d’autres fois via des scripts. Je ne l’ai pas encore testé, mais la documentation donne envie !
Et vous, vous suivez quoi comme indicateurs de la “bonne santé” de vos projets ?
Si vous n’êtes pas familier avec Accelerate et les métriques DORA : Accelerate, la vitesse conditionne l'excellence : un nouveau paradigme dans le développement logiciel
Si les études Accelerate/State of DevOps du DORA vous intéressent, l’item suivant peut valoir le détour 👇
🎙️Software delivery stories - Westrum Organizational Culture
Dans le premier numéro du Tech Away, je vous partageais le podcast Software Delivery Stories - le podcast avec de vraies histoires de delivery logiciel dedans ! de mes collègues Simon Lefort et Julien Tellier qui couvrent les capabilities de l’étude Accelerate.
Si “performance de delivery” rime souvent avec “pratique technique” ou “méthodologie", on oublie souvent l’influence de la culture d’entreprise sur les 4 métriques clefs citées dans l’item précédent.
L’épisode #4 avec Lucie Quach, paru en avril, aborde ce sujet de culture par l’angle du modèle théorique des organisations de Westrum. Selon ce dernier, on peut catégoriser la culture d’entreprise selon 3 archétypes :
pathological (power-oriented) : on y observe des jeux politiques, de la rétention d’information et on a tendance à abattre le messager porteur de mauvaises nouvelles,
bureaucratic (rule-oriented) : il y a un process ou un formulaire pour tout, chaque département a son périmètre, il faut tout faire dans les règles,
et generative (performance-oriented) : l’organisation est concentrée sur sa mission, toutes les initiatives pour atteindre l’objectif sont bien perçues et encouragées.
Ces archétypes ont évidemment une incidence sur le flow de l’information dans une organisation, la capacité d’entraide et de collaboration entre les équipes, la déperdition d’énergie des individus à comprendre et suivre les règles du jeu en plus de faire leur travail, ou encore le potentiel d’apprentissage et d’innovation du groupe.
🎄Continuous Discovery : modéliser l’espace des opportunités avec un opportunity solution tree
Le mois dernier, j’ai souhaité en apprendre plus sur le concept de continuous discovery. C’est tout naturellement que j’ai commencé à lire l’ouvrage Continuous Discovery Habits de Teresa Torres conseillé par mon nouveau collègue Bruno à la machine à café.
Je n’ai lu que la moitié pour l’instant, mais j’y ai trouvé des définitions intéressantes sur la différence entre continous delivery et continuous discovery, sur le product management en général, et j’y ai trouvé un nouvel outil que j’expérimente sur mon nouveau projet : l’opportunity solution tree.
Ce livre explique que le product discovery est l’activité qui permet de décider ce qu’on veut construire. C’est une activité distincte du product delivery où l’on se concentre sur ce qui se passe après cette prise de décision : build, ship, maintenance, …
Pour prendre des décisions sur le produit, il convient d’explorer l’espace des opportunités (les problèmes que rencontrent nos utilisateurs, mais aussi leurs besoins et leurs envies), et ce livre nous propose de modéliser ces opportunités sous la forme d’un arbre (l’opportunity solution tree) organisé comme suit :
à la racine : un objectif ou résultat souhaité (au sens des OKR par exemple),
puis l’espace des opportunités qui peuvent contribuer à réaliser cet objectif,
puis l’espace des solutions candidates pour répondre à ces opportunités,
puis des assomptions : des hypothèses falsifiables que l’on pose quant à la viabilité de ces solutions, des hypothèses qui nécessiteront une expérimentation pour les vérifier (comme un spike par exemple)
Alimenter cet arbre se fait au moins 1 fois par semaine pour que cette activité de discovery puisse mériter le qualificatif de continuous, toujours d’après ce livre.
Et vous, comment vous décidez de la direction que va prendre votre produit ?
Est-ce que vous décidez de cette direction uniquement une fois, au début du projet, avant de vous lancer dans le delivery ?
📘 The Software Guidebook - la 7e partie va vous surprendre
J’ai consacré ces derniers mois à la rédaction d’articles de blog sur le C4 Model, une façon de dessiner des diagrammes d’architecture as-code. C’est une notation créée par Simon Brown qui est architecte, conférencier, … mais aussi auteur de livres sur le sujet de l’architecture et du logiciel.
Je me suis intéressé ce mois-ci à un des ouvrages de Simon Brown disponible sur Leanpub : The Software Guidebook où il partage sa vision de la forme que peut prendre une documentation d’architecture pour un produit :
How long should documentation be? I get asked this question a lot. And rather than talk about numbers of pages, what I’m really looking for is something that I can read in a couple of hours, over a coffee or two, to get a really good starting point for exploring the code.
C’est un livre numérique assez court et qui se veut “activable” en proposant une structure de documentation en 13 parties décrites comme suit :
Et vous, comment vous organisez votre doc d’archi ?
📘 The Software Guidebook - Simon Brown
Et vous, vous avez lu quoi ce mois-ci ?
@ dans 1 mois 👋