DevOps on Zwindler's Reflection

DevoxxFR - Récap du vendredi (jour 3)

Fri, 18 Apr 2025 14:00:00 +0000

Les résumés des 3 jours de DevoxxFR 2025

Troisième jour de DevoxxFR 2025

Cette fois-ci, je me suis couché tôt(-ish, j’ai écrit l’article du jour 2 au lieu de dormir). Je suis donc arrivé assez tôt pour voir la keynote, mais pas dans l’amphi bleu (à 10 personnes près).

C’est parti pour le récap’ du jour 3.

Plongez dans l’ère quantique : décryptez et anticipez la révolution à venir

Fanny Bouton, directrice de l’informatique quantique chez OVHcloud, nous a plongés dans l’univers de l’informatique quantique.

Elle a expliqué que la suprématie quantique, la “Formule 1” du quantique, n’est pas attendue avant 15 à 30 ans. Actuellement, nous avons des ordinateurs quantiques avec 10 à 156 qubits (IBM). En France, il y a six ordinateurs quantiques. Et c’est assez unique, car nous avons 6 différents types sur les 10 types d’ordinateurs quantiques qui existent.

Un peu comme l’IA, il ne faut pas avoir “peur” de l’informatique quantique, qui ne va pas mettre au chômage l’informatique classique.

Elle reste nécessaire pour piloter les ordinateurs quantiques, qui peuvent accélérer certains calculs (notamment des simulations).

En revanche, Fanny a insisté sur l’importance de former tout le monde pour aller vers le futur. Elle a abordé le fait que les concepts comme l’intrication et la superposition d’état nécessitent de réapprendre les bases de l’informatique quand la quantique sera vraiment là.

Enfin, elle a parlé du fait qu’elle avait fait l’acquisition pour OVHcloud d’un ordinateur QRNG permettant de générer de meilleurs nombres aléatoires (il y a donc déjà des usages aujourd’hui) et que, en attendant la suprématie quantique, on pouvait déjà simuler les calculs quantiques sur des HPC classiques, pour amorcer le virage quantique en douceur et soutenir les acteurs locaux.

Les LLM rêvent-ils de cavaliers électriques ?

À 09:35, Thibaut Giraud, alias Mr Phi, a présenté une hypothèse intrigante : les LLM (Large Language Models) ne comprennent rien et sont des perroquets stochastiques. Ils répètent sans comprendre, sans représentation interne.

Cependant, il a très vite pris le contrepied de cette hypothèse : selon lui, les LLM ne sont pas vraiment des perroquets stochastiques. Certains modèles peuvent comprendre un peu les échecs et jouer avec un bon niveau. GPT-3.5 turbo instruct, par exemple, a un ELO de 1700-1800 (la mesure du niveau d’une personne aux échecs; 1800 représente le niveau d’un joueur en club).

La démonstration est assez longue et joue un peu sur les mots, je trouve.

En revanche, Thibaut a partagé une expérience amusante où, si on donne à ChatGPT 3.5 deux ELO très forts et que les noirs donnent leur dame au début, la partie continue de manière bizarre avec les noirs donnant volontairement toutes leurs pièces.

Il a également mentionné une autre expérience montrant qu’on peut entraîner des LLM avec 4 GPU et beaucoup de PGN (le standard pour décrire les mouvements dans une partie d’échecs).

PostgreSQL : Le couteau suisse dont vous avez besoin (sans le savoir)

Laetitia Avrot a donné un excellent talk sur PostgreSQL, et notamment certaines fonctionnalités méconnues et pourtant très utiles.

Bien que je ne sois pas DBA Postgres, la mise en scène (un loueur de vélo) a permis une introduction progressive des différents concepts.

Elle a abordé des sujets comme les types de données Range, qui permettent d’éviter à la sources des erreurs de conception classiques, les colonnes générées, les triggers, la recherche fulltext, et les notifications. Les exemples étaient extrêmement clairs et la présentation assez drôle. Laetitia est une personne que j’admire beaucoup.

Petite citation random qui m’a beaucoup parlé

Mon blog mydbanotebook, je l’écris pour moi parce que je suis plus toute jeune. Je sais que quand je trouve un truc intéressant et que je veux le retrouver 2 ans plus tard, je le retrouverai sur mon site."

Combien de fois suis-je retombé sur mon propre blog en cherchant la solution à un problème que j’avais déjà résolu ?

45 minutes pour mettre son application à genoux : le guide complet du test de charge

Malgré cinq minutes d’avance, je n’ai pas pu entrer dans l’amphi Maillot pour cette session. Trop de queue devant l’amphi…

Caramba. Encore raté.

Speechless

Je me suis fait embarquer un peu par hasard dans le “Speechless”, organisé par Jean-François Garreau.

Un exercice intriguant où trois speakers doivent “jouer” une présentation sur un sujet choisi en partie au hasard, en partie par le public, et avec des slides loufoques qu’ils ne connaissent pas à l’avance.

Je ne suis pas fan d’impro, mais c’était assez intéressant à voir.

A la base, j’avais prévu d’aller voir le récit de David Pilato “Envie de booster ta carrière ? Open source-toi !”. A priori, c’était super en plus. Hop, sur la liste aussi.

Après-midi

L’après-midi a été écourtée par le fait que j’ai dû prendre le train retour en milieu d’après-midi.

Cependant, j’ai eu des super discussions avec Ane, Idriss, Stéphane, Julien, Horacio, et Laetitia.

J’ai pu échanger avec des gens qui avaient vu mes talks (au moins Sacha, Jérôme, Jérôme, plus ceux d’hier) et j’ai eu des retours très positifs, ainsi que quelques suggestions d’amélioration.

Je remercie chaleureusement toute l’équipe d’organisation qui, cette année encore, a fait un travail incroyable. J’ai remercié de vive voix Arnaud avant de partir, mais j’espère que tous les organisateurs / organisatrices savent que je leur suis très reconnaissant, à tous/toutes, individuellement.

Et merci aux sponsors pour s’occuper des gourmands comme moi xD

Vivement l’année prochaine !

DevoxxFR - Récap du jeudi (jour 2)

Fri, 18 Apr 2025 08:00:00 +0000

Les résumés des 3 jours de DevoxxFR 2025

Deuxième jour de DevoxxFR 2025

Après une soirée qui a fini bien tard, j’ai eu un peu de mal à me lever ce jeudi matin. Grave erreur… arriver à 9h00, c’est louper à coup sûr les keynotes…

C’est parti pour le récap’ du jour 2 !

Langage, IA et propagande : la guerre des récits a déjà commencé

Vous l’avez compris, j’ai donc loupé la première keynote, qui était a priori très réussie. Qu’à cela ne tienne, plutôt que me tasser dans une salle d’overflow (certaines étaient pleines aussi de toute façon !), je suis allé faire le tour des sponsors à la place.

Néanmoins, c’est une session que je vais certainement regarder en replay.

Anatomie d’une faille - l’attaque xz utils

À 10h30, j’ai pu assister à une présentation qu’on m’avait déjà plusieurs fois recommandée.

Il faut dire qu’Olivier a fait un super travail sur son talk récapitulatif de l’attaque sur xz utils (la CVE de 2024, ciblant de manière indirecte openssh).

Olivier a bien planté le décor et ne s’est pas contenté d’une analyse technique. Je connaissais plutôt bien cette partie pour avoir lu pas mal d’articles sur le sujet, mais je n’avais pas creusé l’aspect social engineering pour pousser le maintainer Lasse Collin à donner les “clés du camion” à Jia Tan.

Un must à voir si vous avez vaguement suivi l’histoire et que vous voulez un récapitulatif complet en 45 minutes chrono.

Kubernetes : 5 façons créatives de flinguer sa prod

Mon talk du jour !! En amphi bleu en plus.

On ne va pas mentir, l’amphi bleu, c’est quand même une sacrée scène et même pour un speaker non débutant, ça fait quelque chose (d’ailleurs, j’ai entendu Rachel Dubois dira à peu près la même chose un poil plus tard dans la journée).

Coutumier des retours d’expérience d’incidents sur Kubernetes, en particulier des erreurs liées au GitOops (j’ai fait une typo, mais je la laisse volontairement parce que c’est rigolo), j’avais envie de sortir un peu des sentiers battus et d’évoquer cinq anecdotes ayant conduit à des incidents en prod (ou quasiment) qui soient peu communes.

Je ne pensais pas avoir de temps pour des questions et finalement, j’ai eu presque 10 minutes d’échange avec le public. Inattendu, mais enrichissant.

Voilà les slides :

Kubernetes : 5 façons créatives de flinguer sa prod 🔫

Et après l’effort, le réconfort !

TDD et IA

Après mon talk, j’ai voulu souffler (comme je le fais d’habitude) et je me suis isolé le temps de reprendre mon énergie. Pas de bol, j’ai laissé le temps filé et je suis arrivé deux minutes trop tard à l’entrée de l’amphi Maillot et j’ai vu la porte se fermer DEVANT moi.

Un peu deg’, car j’avais très envie de voir mon ancien collègue et ami Benoit Prioux et son talk TDD et IA.

Je ne résiste cependant pas à republier (avec son accord) le sketchnote de mon amie Ane :

Encore un replay à regarder 🙃.

Dans les coulisses des géants de la Tech !

À 13h30, Rachel Dubois, experte product ayant travaillé pour ou en contact avec plusieurs grosses licornes tech, a partagé des insights sur les problématiques “produit” et l’importance de mesurer l’impact business de ce qu’on code.

Elle a insisté sur le fait que mouvement n’est pas la même chose que le progrès et que les ingénieurs doivent être au cœur de l’innovation.

Grosso modo, ça a beaucoup parlé de mesure d’impact des features codées, de feature flipping, d’expérimentations lives sur des grandes populations, de design systems pour faciliter les créations de “variants” de l’UI/UX.

C’était plein de bon sens, mais je n’ai pas non plus été hyper surpris, notamment sur la partie “technique”. Mais peut-être que c’est parce que Deezer faisait mieux les choses que la moyenne ?

Point que je note quand même, Rachel a insisté sur le fait que les ingénieurs ne sont pas des prestataires lambda et que tech == business. Et ça, même dans une belle boite tech, c’est un peu difficile à rentrer ça dans certains crânes.

Pause sponsors

N’ayant pas de talks que je voulais absolument voir juste après, j’ai décidé de faire le tour des sponsors.

J’ai eu des discussions intéressantes avec des gens de chez Sonatype, Couchbase et Mirakl.

On a finalement assez peu parlé de leur business et échangé sur un peu tout et rien. C’était agréable de ne pas être vu comme un prospect :). Ou a minima, que je ne l’aie pas ressenti.

Question pour un container

À 17h00, j’ai participé à un quizz rigolo réalisé par Sherine Khoury et Aurélie Vache sur les containers et la spec OCI.

Bon, ayant eu faux à la 2ème ou 3ème question (dans ce genre de quizz, les formulations sont parfois ambigües), je savais que c’était mort donc j’ai laissé tombé xD.

Mais j’ai regardé les démos et écouté les explications, c’était intéressant !

Infisical : Le meilleur ami des devs pour des secrets bien gardés !

Encore un gros regret : j’ai aussi loupé le talk de Julien Briault sur Infisical…

J’ai encore trop discuté, on ne peut pas tout faire (voir plus bas…).

Panel Staff 42

À 19h00, j’ai assisté à un panel de staff (et principal) engineers.

Les panelists ont discutés de la manière de trouver l’impact par rapport au produit et au business, et aussi de comment un contributeur individuel peut continuer à évoluer sans devenir staff.

C’était intéressant d’avoir plusieurs points de vue, les panelistes travaillant dans des entreprises très diverses et avec plusieurs niveaux de maturités par rapport aux ladders Staff+ (notamment en France).

Petites citations “random” :

N’attendez pas qu’on vous sollicite pour faire des feedbacks. Donnez-en sans attendre qu’on vous le demande.

Être staff, est-ce que ce n’est pas un peu être psy ? Écouter les gens, trouver les problèmes qu’ils / elles ne voient pas.

Il faut valoriser le rôle de staff sans imposer aux gens de devenir staff pour évoluer en salaire.

On a terminé par une question un peu complexe qui n’a (a mon sens) pas été répondue.

On demande aux gens de chercher la visibilité, en interne et parfois aussi en externe, s’ils veulent devenir staff (ou plus). Mais comment on fait pour garder l’équité avec ceux qui font bien leur travail pendant leurs heures, mais n’ont pas de temps (car on les charge trop ?) pour chercher cette visibilité durant les heures de travail ?

Et c’est encore plus vrai quand on demande de l’engagement en dehors des heures de travail (BBL, meetups le soir, conférences le week end).

C’est un point tricky et je n’ai pas plus de réponse.

Meet and greet / réseautage tout au long de la journée

Aujourd’hui, j’ai loupé plusieurs talks qui m’intéressaient, tout simplement parce que j’ai été absorbé par des discussions passionnantes avec de nombreuses personnes, rencontrées pour la première fois pour certaines, ou de vieux copains/copines.

Merci en particulier à Fanny, Erwan, Paul, Olivier, Pierre, le mystérieux “DarkSidious” (hihi), mais aussi Quentin, Geoffrey, Jean-Philippe, Loïc, Mickaël, Mazlum, Cécile et surement d’autres personnes que mon cerveau fatigué par deux jours de confs aura malheureusement zappé (désolé).

C’était vraiment top :-).

DevoxxFR - Récap du mercredi (jour 1)

Thu, 17 Apr 2025 12:00:00 +0000

Les résumés des 3 jours de Conférence Tech 2025

Premier jour de Conférence Tech 2025

Comme vous l’avez peut-être vu (j’ai abondamment communiqué sur les réseaux 🙃), après quasiment un an sans conférence en tant que speaker, me revoilà sur “les planches”, à DevoxxFR !

Evidemment, vous vous en doutez, j’en ai profité pour voir un max de confs, comme à mon habitude ;-).

C’est parti pour le récap’ du premier.

L’IA n’existe pas

Luc Julia a ouvert la journée (dans un amphi bleu blindé) avec un exposé acide et décalé sur l’évolution de l’IA. Selon lui, il n’y a pas de révolution, mais plutôt une évolution continue depuis les années 50-60, puis 90-2000.

Nous en France, les révolutions, on connait et c’est pas ça.

Le titre est un rappel au fait que l’IA générative manque de créativité et que les IA omnipotentes d’Hollywood n’existent pas. Il faut toujours un humain derrière.

Luc a également abordé des problématiques comme la propriété intellectuelle, en citant des cas où l’IA générative open source Stability diffusion a produit des images avec des watermarks Getty Images clairement visibles, et un peu les problématiques environnementales, avec des chiffres complètement bidons (dommage).

Github Copilot

À 11h35, j’ai assisté à une démonstration de Github Copilot, réalisée par Kim-Adeline Miguel et Sandra Parlant en particulier sur les dernières fonctionnalités.

Les deux speakeuses ont montré le chat en mode immersif, le changement de modèle, la configuration des instructions personnalisées. N’ayant pas encore utilisé Copilot (oui oui…), ça donne envie d’essayer.

J’ai été plutôt impressionné par la capacité de Copilot à faire des revues de code sur les PRs et la même chose sur les analyses de sécurité.

Ne perdez plus vos photos de vacances (ou tout autre fichier important)

Mon talk du jour !!

C’était un sujet qui me tient assez à cœur et ça s’est très bien passé. J’ai eu de bons retours, notamment avec des discussions assez riches qui ont suivi.

Je suis vraiment content, j’ai déroulé comme je voulais. J’ai eu des suggestions pertinentes et je postulerai à nouveau (peut-être) ailleurs :).

Les slides :

Ne perdez plus vos photos de vacances 🔥🏠🔥 (ou tout autre fichier important)

Comment nous avons transformé les Restos du Coeur en Cloud Provider

À 13h30, (mon ancien collègue) Julien Briault et Stéphane Trognon nous ont raconté comment ils ont contribué à transformer les Restos du Cœur en véritable fournisseur de cloud.

De l’organisation initiale chaotique à une infrastructure professionnelle, ils nous ont partagé un voyage de transformation, du “DC au WC” jusqu’aux 3 DCs multi AZs from scratch gérés par 11 bénévoles.

Ils utilisent désormais OpenStack avec Kubernetes, et plus globalement des solutions open source pour la plupart de leurs besoins. Ils ont même développé des solutions spécifiques, comme des systèmes de monitoring pour les chambres froides qui coûtaient avant ça “un pognon de dingue” (ça, c’est moi qui le dit).

Ce projet est vraiment un coup de cœur (pun intended) que je suis depuis longtemps (j’avais déjà vu un autre talk de Julien qui en parlait).

Grâce à leur approche d’éco-conception et à l’utilisation d’équipements de récupération, ils ont réussi à économiser des millions ~~d’euros~~ de repas distribués, tout en fournissant des services essentiels permettant de s’affranchir d’AWS (en particulier dans le contexte géopolitique actuel).

Ca marche dans mon .devcontainer

À 17h00, j’ai assisté à une présentation sur les devcontainers par Benoit Moussaud.

J’ai souri quand il a commencé en plantant le décor en disant qu’il avait dû re-travailler sur Windows en étant embauché par Microsoft et que c’était la galère (il ne l’a pas dit comme ça, mais ceux qui font du WSL ont compris).

Pour celles et ceux qui ne connaissent pas bien les CDE (pour cloud development environments), cela permet de créer des environnements complets de développement dans des containers, ce qui est extrêmement utile pour l’onboarding, la gestion des versions et des outils, ainsi que pour l’isolation entre l’environnement du laptop et l’environnement spécifique au projet.

La démo s’est bien passée, avec la création d’un devcontainer qui clone le repository dans le container. Dans la spécification, on peut aussi ajouter des “features” pour customiser l’environnement, comme ajouter Vegeta pour du load testing.

Le côté “automagique” de l’injection des credentials Git de l’utilisateur dans le devcontainer a été aussi abordé, mais ça soulève autant de questions que de réponses…

Cependant, il n’y a pas de support pour Windows, GPU, ou private endpoints via GitHub Codespace.

Burrito est un TACoS : une alternative open-source à Terraform Cloud

À 17h50, j’ai découvert Burrito, une alternative open-source à Terraform Cloud, qui adresse plusieurs soucis de l’IaC, en particulier avec Terraform.

Luca et Lucas (ahah) nous ont présenté Burrito, leur opérateur Kubernetes inspiré d’ArgoCD, offrant des fonctionnalités de réconciliation, détection de drift pour terraform.

Clairement, je me suis tout de suite retrouvé dans leurs constats des faiblesses de terraform et j’ai été séduit par leur approche.

Burrito est compatible avec Terraform, Terragrunt et Opentofu, et exécute terraform plan/apply dans un container Kubernetes.

Ils ont parlé ouvertement des challenges qu’ils ont rencontrés à l’échelle :

Problématiques I/O pour le téléchargement des providers et des binaires.
Problématiques CPU avec des plan/apply très réguliers.

Pour y répondre, ils ont implémenté un caching de provider et des fenêtres de synchronisation pour gérer 800 layers Terraform en parallèle. Pour la suite, ils envisagent d’ajouter du polling, l’autodiscovery, le RBAC, et l’intégration de plugins (Checkov, Terracost).

J’ai eu une discussion très intéressante par la suite avec tous les deux, c’était très sympa.

Diner des speakers

La soirée s’est terminée par un diner des speakers, où j’ai pu parler avec pas mal de gens :)

Impossible de citer tout le monde (j’ai beaucoup parlé XD), mais j’ai particulièrement apprécié parler avec Olivier, Marie, Alice & Théotime, Jean-Christophe, Aline, Thierry, et aussi Erwan, pendant cette soirée :).

Bon… on avait faim… alors, on a dû finir par un MacDo 💀.

Monter une CoP (Community of Practice)

Tue, 23 Mar 2021 07:20:00 +0000

T’es ma meilleure CoP !

Il y a 6 mois, quand j’ai changé d’entreprise, j’entendais parler pour la première fois du terme CoP (« Community of Practice », « Communauté de Pratique » en français).

L’entreprise dans laquelle je travaille est une des rares licornes Françaises. J’y ai découvert tout un tas de pratiques et en particulier les CoP.

Ça tombait super bien que je n’y connaisse rien, parce que la première chose qu’on m’a demandé de faire lorsque je suis arrivé dans ma nouvelle entreprise, c’est de monter une CoP. Et vous le savez, j’adore apprendre des nouveaux trucs ;-).

Mais revenons un instant aux fondamentaux

Ce terme a été inventé par Etienne Wenger, est un théoricien de l’éducation. Dans les années 90, il a étudié comment des groupes de personnes qui travaillent ensemble faisaient pour résoudre plus efficacement des problèmes qu’ils ont en commun.

Ce terme est ensuite repris par le SAFe (le Scale Agile Framework), qui voit les Community of Practices comme des piliers prépondérants des entreprises LEAN et qui en donne la définition suivante (Agile bingo spotted).

Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain. © Scaled Agile, Inc. www.scaledagileframework.com/communities-of-practice/

Une CoP est donc :

un groupe de personnes qui se retrouvent régulièrement
pour parler d’un centre d’intérêt commun (souvent un sujet technique, mais pas forcément)
pour partager et faire profiter les autres de leurs succès comme de leurs échecs et ainsi faire progresser tout le groupe

On retrouve donc 3 notions importantes, qui sont d’ailleurs des notions qui proviennent du travail de Wenger (ça tombe bien !), que vous verrez peut-être sur Internet sous les noms « Domain (2.) », « Practice (3.) » et « Community (1.) ».

[Edit] Un point que j’oublie d’aborder et que la CoP, doit être un lieu de partage et d’inclusion. Il faut qu’elle se déroule dans un climat bienveillant pour que tout le monde puisse se sentir à même de partager. De ce fait, il est également conseillé d’y privilégier un cadre informel/détendu (ce qui me convient parfaitement, je peux faire des jeux de mot pourris en toute impunité).

Mais est ce que ça sert vraiment ?

Jean Michel Petit Chef : Ben oui, parce que ça coûte cher quand même tous ces meetings entre Dev (et Ops) alors bon faudrait pas que ça coûte plus cher que mes meetings productivity-bingo-bullshit. (troll inside)

Si jamais comme JMPC vous êtes un peu sceptiques, vous pouvez aussi jeter un œil au programme DORA (DevOps Research and Assessment) et son State of DevOps 2019, qui montre que les plus great-performers (ceux qui sont agiles et shiny) sont ceux qui implémentent, entre autres, ce genre de communautés. A l’inverse, les low-performers ont plutôt tendance à monter des centres d’excellence ou de formation, qui ont tendance à « siloter » la connaissance.

High performers favor strategies that create community structures at both low and high levels in the organization, likely making them more sustainable and resilient to reorgs and product changes. The top … strategies employed are Communities of Practice […]

Low performers tend to favor Training Centers (also known as DOJOs) and Centers of Excellence (CoE)—strategies that create more silos and isolated expertise.

DORA State of DevOps 2019

Si vous vous présentez comme « le nouveau Google/Amazon/Uber français », vous savez maintenant ce qu’il vous reste à faire (troll, encore).

Dans mon entreprise, il existe une petite dizaine de CoP, de taille et de fréquence très diverses les unes des autres.

La plupart du temps, le but est de partager l’expérience et les bonnes pratiques entre tous les membres de la CoP, mais aussi présenter de nouveaux outils, de nouvelles façons de travailler, discuter des « pain-points » qui pénalisent les équipes, leur trouver des solutions rapides ou bien préparer les arguments pour prioriser leur résolution au prochain trimestre.

Grosso modo, dès que vous avez des groupes d’experts quelconques qui rencontrent plus ou moins les mêmes genres de problématiques, ça vaut le coup de monter une CoP pour éviter de réinventer la roue. Ou qu’au contraire une partie du groupe utilise des roues carrées alors qu’une autre équipe a déjà des roues rondes à disposition.

Tu m’as convaincu, comment j’en monte une ?

Avant de monter une CoP, il faudrait peut-être qu’elle ait une raison d’être, non ? Pour la trouver, il va falloir répondre aux questions suivantes :

« Quel sujet avons nous en commun et nous intéresse ? » (Domain)
« Qu’avons nous à partager ? Des retours d’expériences, des bonnes pratiques, de la technique pure? » (Practice)
« Qui sont les membres de la communauté ? » (Community)

Pour ces 3 questions, il n’existe pas de réponses universelles.

Domain

Il n’y a pas deux entreprises pareilles et il est donc normal qu’il n’y ait que vous qui puissiez savoir si une CoP sur le dernier framework Javascript à la mode, sur l’UX Design ou bien sur les principes SRE a du sens dans votre entreprise.

Community

On distingue deux types de communautés pour créer un CoP. Les communautés par Rôle (role-based), c’est à dire qui vont regrouper un certain type d’individus/de métier bien précis et les communautés par Sujet (Topic-based).

Pour ces derniers types de communautés (Topic-based), je pense qu’il faut construire la communauté la plus large possible du moment que les participants sont motivés. Ne soyez pas sectaires, tous les points de vue sont les bienvenus, pourvu qu’ils soient constructifs.

Un exemple un peu bateau mais parlant, n’hésitez pas à intégrer des Devs qui s’intéresseraient à votre CoP sur les bonnes pratiques Ops (ou l’inverse).

Regardez bien, je suis à deux doigts d’inventer le DevOps

Practice

Posez vous dès le début la question de ce que vous voulez partager en CoP (j’ai donné des exemples plus haut), mais aussi de la façon dont vous allez les organiser.

Quel format (présentation, séance de questions/réponses, brainstorming, mob, dojo …) ?
Quelle durée (30 minutes, 30 minutes + 30 minutes de questions, 2h, …) ?
Quelle fréquence (hebdomadaire, mensuel, toutes les lunes gibbeuses, …) ?

Il faut trouver la combinaison durée/créneau horaire qui arrange le plus de membres possible, tout en essayant de trouver une régularité qui favorisera la durée de vie de la CoP. Ne décidez pas de faire une CoP hebdomadaire si vous n’êtes pas capable de tenir le rythme sur le long terme !

Ce n’est pas un sprint mais une course de fond

La vie de la CoP

Comme toute organisation, une CoP n’a pas forcément vocation à être éternelle. On imagine bien qu’une CoP sur un framework qui n’existe plus dans l’entreprise disparaîtra d’elle même…

De même, il est normal que certains membres de la CoP soient plus impliqués que d’autres. Si vous voulez que votre CoP ait un intérêt maximal, le but du jeu sera évidemment de fédérer le plus de gens motivés possibles.

C’est évidemment plus facile à dire qu’à faire… #Yakafokon

Pour vous aider, n’hésitez pas à confronter l’idée que vous vous faites de votre CoP (Domain/Community/Practice) avec les gens que vous imaginez être vos futurs membres. Interrogez-les, faites un sondage sur ces points.

Demandez à vos collègues s’ils ont des sujets dont ils souhaiteraient discuter en groupe. Voire même des sujets qu’ils souhaiteraient présentez eux même.

Ce dernier point est capital pour le succès de la CoP. Si c’est toujours la même personne qui présente, cela risque fort de devenir son travail à temps complet (surtout si vous avez une fréquence hebdo).

Pire, les autres membres communauté seront passifs et les membres risquent de s’en désintéresser progressivement.

Il faut donc recruter des membres actifs, que tout le monde se sente impliqué.

Les outils de la CoP

Pour faciliter la collaboration des membres et maintenir une activité, n’hésitez pas à mettre en place des outils.

Vous utilisez très probablement un outil de messagerie instantanée, n’hésitez pas à créer un channel public dans lesquels vos participants pourront échanger entre les réunions, soit pour rediscuter d’un point vu en CoP, soit pour partager un article déniché pendant la veille. Ce channel servira aussi à recruter d’autres membres et à rappeler les futurs meetings.

Vous pouvez aussi créer un board (type Kanban) dans lequel tous les sujets à venir sont listés dans des tickets. Les membres de la CoP peuvent en ajouter, voter pour les sujets qui les intéressent le plus (aka les aideront le plus dans leur travail), prendre certains sujets pour les présenter eux même. Les tickets sont déplacés dans les colonnes « En cours », « Planifié » et « Terminé » en fonction du planning.

Dans la CoP que j’ai créé, j’ai également souhaité qu’à la fin de chaque meeting, un ROTI (Return on Time Invested) soit organisé. De cette manière, tous les participants peuvent donner un feedback honnête sur l’intérêt qu’ils portent sur le temps qu’ils viennent de consacrer. Cela permet de jauger l’intérêt que la communauté a pour les meetings que vous organisez, voire de corriger si jamais certains membres s’ennuient.

Une sorte de prise du pouls de votre CoP.

En cette période de confinement, vous pouvez trouver des outils en lignes pour éviter de compter les doigts sur chaque main levée.

Le facilitateur

En tant que « CoP leader », vous aurez un rôle de facilitateur. A vous de vous assurer qu’il y a suffisamment de sujets pour faire vivre la CoP, de recruter des orateurs pour présenter des sujets, d’animer le channel et le board.

Pendant la CoP, vous devrez aussi jouer le rôle de timekeeper. Entre passionnés, les discussions ont vite fait de traîner en longueur, car on s’égare sur un point précis qu’on trouve intéressant (moi le premier !). Or, il faut absolument se tenir au créneau choisi pour que tous les membres puissent participer dans de bonnes conditions.

A vous aussi de vous assurer que ce n’est pas toujours les mêmes qui prennent la parole. C’est la partie que personnellement je trouve la plus dure, car je travaille avec des passionnés qui ont une très grande connaissance, mais il faut absolument laisser de la place pour tout le monde, notamment ceux qui maîtrisent moins.

Enfin, vous aurez peut-être besoin de jouer le rôle de scribe (prise de note et retranscription résumée des débats/questions, tenue d’une page de wiki, sauvegarde des vidéos, etc) pour garder une trace du travail réalisé et de l’éventuel suivi des actions réalisées et à faire.

Il n’est pas impossible que ce travail « autour de la CoP » soit aussi consommateur en temps (voire plus !) que la CoP.

Conclusion

J’ai vraiment adoré avoir la responsabilité de monter une Community of Practice. Les débats qu’on a lors des réunions sont passionnants et pour ne rien gâcher, les retours sont vraiment bons.

Après quelques meetings, la CoP semble maintenant bien implantée chez nous, avec plusieurs sujets à venir, de plusieurs speakers et une vingtaine de membres à chaque fois (sur 40 inscrits).

Plusieurs sujets utiles pour les membres ont été présentés, dont certains qui ont eu des impacts sur les déploiements en Prod (best practices).

La quantité de travail est conséquente. Je l’avais anticipé, mais j’ai été surpris par la quantité de travail autour de la CoP (le rôle de facilitateur).

Enfin, pour la fréquence des meetings, j’ai été un peu frileux. J’avais trop peur qu’on s’épuise, j’ai proposé un rythme mensuel, alors qu’on a trop de sujets à traiter. Résultat, les sujets n’avancent pas aussi vite qu’on voudrait et ça créé de la frustration pour ceux qui attendent les sujets pas encore traité. Pour autant, je préfère ça que le contraire, et il est encore temps de corriger en augmentant la fréquence.

J’espère vous avoir convaincu :)

Sources

Au secours, le métier d’Ops va disparaître !

Wed, 29 Jul 2020 08:00:00 +0000

Echo au post d’Olivier Poncet, version Ops

Il y a une semaine, Olivier Poncet a posté un long article intitulé Je fais partie d’une espèce menacée d’extinction, dans lequel il raconte, entre autres choses, qu’il ne reconnaît plus son métier.

Je vous conseille d’aller le lire, il y parle de beaucoup de choses qui sont vraies pour tous les métiers de l’IT.

Un des sujets qu’Olivier aborde est l’arrivée des magiciels, du cloud et du NoCode. Vous savez, tous ces bidules magiques qui vous promettent de pouvoir faire un business dans l’IT sans en faire (de l’IT).

En filigrane, les développeurs sont nuls et le nocode permet de copier Airbnb en 1 week end

N’étant pas développeur (je bidouille du Python pour le fun), l’article a pour autant réveillé en moi un article similaire que je rumine depuis des années. Ce brouillon avec ses premières phrases traîne depuis 2016 si on en croit la date dans WordPress…

On va rentrer tout de suite dans le vif du sujet : ça fait des années qu’on nous prédit la fin du métier d’Ops (ou tout autre variante, Sysadmin, NetOps, DBA, …). C’est vraiment pas de bol que j’en ai fais mon métier (passion).

TL;DR. je ne crois pas une seule seconde que le métier d’Ops va disparaître.

The end is nigh!

Retour en arrière.

On est en 2013. Je commence tout juste à être un admin correct, à savoir à peu près de quoi je parle et être pertinent sur 2-3 sujets niches (Vulture, Shinken, …). Je me décide à créer un compte Twitter pour pouvoir en discuter avec mes pairs.

Et là, c’est le drame. Un des premiers tweets que je lis, que je n’ai malheureusement pas su retrouver, qui disait :

Sysadmins, you should learn how to code quickly. With cloud adoption, you will soon be out of a job.

Et c’est drôle, car c’est littéralement le pitch de l’article d’Olivier Poncet, qui a l’impression que l’industrie lui explique qu’il appartient à une espèce en voie d’extinction.

STEVEN SPIELBERG: « You’re out of a job »

Back to my tweet

En lisant le tweet de 2013 qui me prédisait une fin proche et douloureuse, sur le moment, je me suis dit : “comment quelqu’un qui travaille dans l’IT peut écrire un truc aussi stupide ?” (En bien moins poli).

Et pourtant, les années passant, il faut se rendre à l’évidence. Même dans un monde où on prône* le DevOps depuis plus de 10 ans, cette croyance est finalement assez bien ancrée dans une partie de la communauté.

*Une des premières personnes que j’ai follow sur Twitter, @bitfield en parle depuis 2009 et je suis sûr que d’autres en parlent depuis bien plus longtemps…

Les Ops, ces techosses chevelus confinés au sous-sol, à la IT crowd, sont voués à disparaître.

Hello IT. Have you tried turning it off and on again?

Avant-hier, l’automatisation

D’abord, on nous a promis que les Ops allaient disparaître à cause de l’automatisation de l’infrastructure.

Chef, Puppet, Ansible, … plus besoin d’être un Ops pour faire de l’Ops. Je peux installer/mettre à jour des softs en quelques lignes de YAML !

Dans l’absolu, ouais… D’ailleurs, j’ai même donné une conf à BDX.IO là-dessus, avec comme titre “Ami développeur, deviens un ops sans effort avec Ansible”.

Mais c’était plus pour avoir un titre accrocheur qu’autre chose, car une fois installé, qui va gérer l’infra en cas de problème ?

Même pour régler un problème aussi trivial qu’un filesystem rempli par des logs, il va falloir que quelqu’un fasse de l’opérationnel : vider les logs, le temps de corriger la verbosité de l’appli… Et on est bien d’accord que dans la vraie vie ça sera pas aussi simple tous les jours.

C’est la raison pour laquelle je ne conseille pas Ansible lorsqu’un Ops junior me demande s’il peut commencer à apprendre le métier comme ça. Ansible, que j’utilise tous les jours, nécessite a minima de comprendre comment ça marche, sous le capot.

C’est comme un mécanicien qui apprendrait uniquement à se servir de la valise et pas comment marche un moteur ou le circuit de refroidissement (attention, semi-troll).

Sans cette compréhension, propre à quelqu’un qui a déjà fait une fois à la main, le temps gagné lors du déploiement sera perdu 10 fois (100 fois ?) quand il y aura un bon gros plantage.

Hier le cloud

Quand on parle de la fin des Ops, le suspect n°1 qui revient le plus souvent est sans aucun doute le Cloud.

Mais c’est quoi, le Cloud ?

Je vous passe la vision des non techniciens, à qui on a vendu que le cloud, c’était le stockage de leurs photos de vacances sur leur iPhone partout dans le monde. Ce n’est pas de leur faute, c’est BFMTV qui leur a dit.

Mais même dans le monde IT, pour beaucoup d’experts (autoproclamés ?), le cloud, ça se limite à une idée floue, à mi-chemin entre le SaaS et le IaaS, qu’il existe une solution magique pour tous les workloads, prête à l’emploi et à payer à l’usage.

Dans ces conditions-là, c’est vrai, les Ops ne servent plus à grand-chose…

J’exagère ? Il y a même une personne, de passage sur un de mes articles, qui a pris le temps de chercher l’email du blog, pour venir m’écrire :

De nos jours, avec la montée en puissance du cloud, comment un architecte système comme toi s’en sort, alors qu’il suffit d’un clic pour obtenir une instance système ?

Il faut dire aussi que les gros cloud providers n’hésitent pas à entretenir cette idée (ça les arrange !), comme par exemple dans ce Manga (officiel) édité par Microsoft Azure :

Prend moi pour une buse, Azure

I have no idea what it means

github.com/msdevjp/AzureStaticWebApps-ComicBook/blob/master/AzureStaticWebApps_Fullver.pdf

Day 2 operations

Le truc, c’est que, une fois que vous l’avez, cette “instance système” (notez le terme ultra flou), ou cette webapp vous en faites quoi ?

La question, elle est vite répondue

Désolé de casser vos rêves, jeunes entrepreneurs. Cette solution magique fantasmée, elle n’existe pas. Au mieux, ce qu’on appelle vulgairement “le cloud”, c’est une collection hétéroclite de services, qui, mis bout à bout, vous permettent de faire tourner votre appli. Soit. Mais :

Personne ne va les mettre “bout à bout” pour vous.
Personne ne va s’assurer que tout fonctionne parfaitement, h24…

Je ne vais pas vous détailler la complexité de mon métier (maintenir en ligne des services accessibles dans le monde entier). Pour que vous puissiez appréhender le problème, il me suffit de citer cet excellent article sur la panne en cours depuis jeudi dernier chez Garmin.

www.nakan.ch/wp/2020/07/24/indisponibilite-de-garmin-connect-chronique-dune-catastrophe/

Il n’y a qu’à voir la complexité qu’une entreprise mondiale a pour remettre en ligne Garmin Connect pour comprendre que sans une armée d’Ops, ça ne peut pas marcher, même dans le cloud.

Il y a carrément des pans entiers de nos métiers qui auront disparu en 2024

Bon… venant de so-called expert sur LinkedIn ou d’un visiteur sur mon blog,… Admettons.

Mais même Gartner (entreprise de conseil dans les domaines techniques) s’y met !

Stockage : les analystes urgent les ingénieurs de changer de carrière

Le cloud et l’hyperconvergence ont à ce point réduit la demande pour des spécialistes du stockage que, d’ici à cinq ans, il sera tout simplement impossible de trouver un tel profil sur le marché de l’emploi. - Operations & Cloud Strategies de Gartner, fin 2019.

Carrément. “tout simplement impossible”

Gartner, nous explique, droit dans les yeux, que dans 4 ans il n’y aura plus dans le monde de baies de stockage opérées par des humains.

Mais alors, ils vont devenir quoi les “ingé sto” ?

Plus personne n’a vocation à devenir administrateur ou ingénieur en stockage. Les nouvelles générations préfèrent désormais s’orienter vers des carrières de développeurs.

Aaah voilà. On y est ! Les Ops c’est has been, il faut devenir Dev maintenant monsieur. On en revient au tweet du début de l’article, la boucle est bouclée, je suis moi aussi membre d’une espèce en voie d’extinction.

Dans son article Kubernetes présent partout, visible nulle part), Didier Girard le VP Engineering de SFEIR nous dit :

L’infrastructure est le domaine en voie de disparition. Il existe actuellement des racks d’ordinateurs dans des pièces fermées à clé, avec des lumières clignotantes et mystérieuses et beaucoup de ventilateurs qui vibrent.

On retrouve le champ lexical de l’espèce menacée, les clichés à la IT Crowd (blip, blip… double blip),…

Si vous lisez l’article, vous verrez que c’est un peu plus nuancé que cette phrase, sortie de son contexte. Mais l’image, elle, est bien présente et selon moi elle alimente dans l’inconscient collectif l’idée que les Ops vont disparaître.

Incrédulité

Je ne comprends pas que des pros (Gartner) puissent écrire des choses pareilles…

Comment peut-on imaginer les équipes d’infra vont disparaître au profit du tout sur le cloud, dans un monde où il existe encore un nombre incalculable d’entreprises (banques inclues) fonctionnent encore avec ce type de systèmes informatiques avec des interfaces vert/noir 640×480 :

Si jamais il y a une transition, n’imaginez pas que ça ait lieu avant 20-30 ans (de manière progressive).

Et c’est pas fini !

Et quand on pense que ça peut pas être pire, il y a toujours un esprit malin pour venir inventer autre chose…

Roulement de tambour

Maintenant on nous vend du serverless ! Plus besoin de serveurs pour faire marcher votre code, vous l’uploadez sur Internet et à vous les millions ! Enfin débarrassé des Ops…

Hum… vraiment ?

En vrai, on est d’accord qu’il y a bien un serveur pour faire tourner votre code, hein ? Vous n’avez juste plus la main sur la façon dont il est lancé : ce serveur, il est géré par votre fournisseur de service.

Êtes vraiment sûr que cette personne vous aidera quand vous aurez un gros problème de perf, a mi-chemin entre le code (vous) et la plateforme (eux) ?
Avez-vous vraiment confiance dans le fait que l’opérateur n’analysera pas votre trafic ou les données que vous traitez ?
Êtes-vous certains que vous n’aurez jamais besoin de modifier un paramètre système ou applicatif, géré par votre hébergeur (qui pourra vous répondre : “non j’ai pas envie”) ?

On pourrait continuer longtemps… Si le serverless, comme n’importe quel outil, a des usecases qui lui sont particulièrement favorables, les usecases où il ne vaut mieux pas en faire sont pour l’instant encore nombreux…

Toujours plus…

Et dans la courbe de la hype, on peut monter plus haut.

Depuis quelque temps je vois aussi tourner des articles sur le NoOps. Si vous ne voyez pas de quoi il s’agit ce n’est pas grave, personne ne s’accorde vraiment sur ce que c’est. Moi je le vois comme l’évolution dystopique du DevOps dans laquelle les Devs ne parlent même plus avec les Ops puisqu’il n’y en a plus :-p.

Pas encore assez hype ?

Pas de souci, je vous ajoute de l’IA et vous avez maintenant de l’AIOps…

Artificial intelligence for IT operations (AIOps) refers to the automation of IT operations tasks through artificial intelligence (AI). AIOps platforms free ITOps and drive better business outcomes, by ingesting operations data to identify and resolve issues automatically.

Il ne manque plus que la blockchain et on peut crier Bingo !

Je vais même pas argumenter, je pense que c’est du même niveau que le no-code dont nous parle Olivier Poncet.

Pourquoi tant de haine ?

Derrière ces formules chocs qui m’annoncent la fin de mon métier, se cache, je pense, une part de méconnaissance de celui-ci et une part de gloubiboulga marketing.

Ça ne se limite pas au métier d’administrateur système, je pense que tous les métiers avec une “fonction support” (RH, juridique, etc) ont tendances à être vus négativement par les “utilisateurs” qui les sollicitent.

Et ça s’explique.

Les “utilisateurs” ne se préoccupent de l’infrastructure (ou autre) que quand il y a un problème. Ça génère forcément de l’agacement de tous les côtés. Les utilisateurs qui veulent qu’on les dépanne d’un côté, les admins qui doivent gérer le stress qu’on leur transmet tout en résolvant les problèmes vite mais sans empirer la situation de l’autre.

Mais il y a aussi les directions, qui considèrent parfois que ces fonctions “support” n’apportent pas de valeur à l’entreprise (contrairement au dev, qui développe de nouvelles features, monnayables).

Je le redis, ce dénigrement n’est pas limité aux admins. Tout métier “support” vit ce genre de situation, parfois injuste. Combien de fois j’ai entendu dire :

Les gens ne viennent que pour se plaindre, jamais nous remercier quand ça fonctionne…

On ne communique pas super bien non plus…

Bon, une fois que c’est dit, faut pas se voiler la face non plus.

Si on est incompris, c’est peut être un peu dû au fait que la réputation des admins barbus et peu amènes n’est pas toujours injustifiée ;-).

On manque très probablement aussi de bons communicants pour expliquer notre métier, ainsi que pourquoi tout ce que je vous ai cité plus tôt, c’est pour l’instant du bullshit en barre.

Pour avoir passé pas mal de temps en conf, mon opinion, c’est qu’il y a trop peu d’Ops en conf de Dev. Et pour ne rien arranger, il y a peu de conférences Ops (en France) du niveau de qualité et de diversité des sujets traités que dans les conférences de Dev.

Exception faite des conférences de libristes et/ou sécurité qui elles sont souvent très bien, les conférences “connues” d’Ops, c’est au mieux des retours d’expériences, au pire, l’événement d’un constructeur/éditeur (VMware, Microsoft, whatever). Dans ces dernières, on ne parle de rien d’autre que des nouveaux produits géniaux dudit constructeur/éditeur (SAP 29, Exchange 730)…

Pas de quoi intéresser un développeur, encore moins un manager.

J’ai rien prévu pour demain, mais… c’est déjà bien d’y penser.

Je vais pas me la jouer prédicateur… Quand je regarde comment l’informatique a changé depuis 2010, difficile de deviner ce que sera le métier en 2030. Pour autant, je suis quand même optimiste.

Il y a 10 ans, on m’a promis la fin du métier d’Ops. Force est de constater qu’aujourd’hui, c’est loin d’être vrai. Je dirais même que c’est le contraire, je pense qu’on n’a jamais autant eu besoin des Ops.

Oui, c’est maintenant trivial de déployer un serveur. Du coup, beaucoup de projets informatiques qui n’auraient pas pu se lancer (ou beaucoup moins vite), faute d’Ops pour bootstraper l’infra, se lancent. Toutes les tâches “sans valeur ajoutée” disparaissent peu à peu.

Mais pour autant, dès qu’un projet prend de l’ampleur, la réalité revient au galop : déployer, c’est facile ; maintenir, c’est une autre paire de manche ! Le fameux “Day 2 operations” que je vous ai cité un peu plus haut.

Pire ! Pour palier à la pénurie d’Ops, on a tendance à mettre en place des systèmes de plus en plus complexes (loadbalancers, clusters, virtualisation, multicloud, Kubernetes pour les plus foufous). Et plus les systèmes sont complexes, plus on se rend compte qu’il faut d’Ops pour les maintenir.

Roald Dahl à la rescousse

J’ai lu quelque part une comparaison qui m’a fait sourire car ça m’a rappelé mon enfance quand je lisais du Roald Dahl.

Au début du film de Tim Bruton Charlie à la chocolaterie, adapté du livre de Roald Dahl, le père de Charlie perd son travail à l’usine, remplacé par une machine (je sais plus si cette scène existe aussi dans le livre, sorry).

Le cloud et l’infrastructure as code sont 2 moteurs qui font évoluer de manière rapide le métier d’administrateur systèmes. Une partie toujours plus importante des tâches d’hier sont en train de disparaître (doucement) : le plus simple, le plus automatisable. D’où le fantasme que le métier va disparaître.

Mais en réalité, c’est que cela ne va pas nous conduire à moins de systèmes à maintenir, mais des systèmes plus complexes.

A la fin du film, le père de Charlie retrouve un emploi à l’usine, en tant que réparateur de la machine qui l’a remplacé.

Je le concède volontiers, cette comparaison est un peu triviale, mais je pense qu’il y a du vrai dans cette image, car c’est ce que je vis depuis 10 ans.

Cette transition vers moins de tâches à faible valeur ajoutée va nous permettre de dégager le temps des admins pour se concentrer sur tout ce qui a vraiment de la valeur ajoutée : l’architecture, l’amélioration continue, l’expertise lors de crises.

Alors, en attendant la fin du métier d’Ops, have fun ;)