Cet article fait partie d’une série dans laquelle je parle de mon nouveau NAS que j’ai construit moi-même : Mon NAS en 2024 - Jonsbo N2 × Intel N100 - hardware Mon NAS en 2024 - Jonsbo N2 × Intel N100 - software Mon NAS en 2024 - Jonsbo N2 × Intel N100 - stress tests Bonus - Installer plex sur TrueNAS (SCALE) Les critères software Dans la partie précédente, j’avais listé mes critères hardware (et un à mi-chemin hard/soft, le fait de pouvoir faire des VMs). Ici, passons donc aux critères software : Mon critère principal est de pouvoir utiliser ZFS. Je suis fan inconditionnel de ce système de stockage qui sait tout faire. Je ferai peut-être un article rien que pour en parler d’ailleurs (et j’ai déjà plusieurs articles dont c’est le sujet secondaire). Le second critère est la possibilité d’avoir une interface pour gérer facilement les fonctions principales du NAS. J’ai géré mon NAS avec un OS linux et tout géré “à la main” pendant des années Dans les must have, il y a évidemment la possibilité de faire tout ce qu’on fait habituellement avec un NAS, à savoir la possibilité de faire du NFS, du Samba, du iSCSI, un serveur rsync, gérer des droits d’accès, monter des tunnels VPN…, Mais est-ce vraiment un critère ? N’importe quel OS linux peut le faire. Je note quand même 😉. La possibilité de lancer des apps, pour étendre les fonctions de base, de façon simple (comme un serveur Plex par exemple) La possibilité de lancer des containers ET des machines virtuelles Aparté sur ZFS et les prérequis en termes de RAM J’en ai ma claque de lire sur le net ou sur Twitter que ZFS n’est pas adapté pour les petits besoins / petites machines. Je lisais encore hier un article qui disait qu’il ne fallait pas choisir un OS qui ne gère que ZFS car ZFS serait hyper gourmand , en particulier en RAM, et que cela empêcherait de l’utiliser sur des machines avec moins de 32 Go de RAM, et ECC en plus ! 😒 Il y a une extrêmement mauvaise compréhension des fonctionnalités de ZFS. Oui, ZFS nécessite effectivement 1 Go de RAM (et vous avez réellement intérêt à ce que ce soit de l’ECC) par To d’espace disque… SEULEMENT SI VOUS ACTIVEZ LA DE DÉDUPLICATION !. Et autant dire que ce n’est recommandé que si vous savez ce que vous faites et les risques que cela implique. Je ne rentre pas dans les détails ici, on en reparlera dans l’article sur ZFS. Et deuxième erreur, effectivement aussi, par défaut, ZFS réserve pour son cache la moitié de la RAM. Sauf que ce paramètre est… un paramètre ! S’il est déconseillé de le mettre à 0, ça fonctionne extrêmement bien, même si vous le réduisez fortement. #Limiter la taille du cache RAM de ZFS à 4 Go echo 4294967296 |sudo tee -a /sys/module/zfs/parameters/zfs_arc_max cat /proc/spl/kstat/zfs/arcstats|grep -e "^size" size 4 4119613272 Je l’ai mis à 512 Mo sur des serveurs Proxmox VE qui n’ont que 4 Go de RAM, par exemple, et je sais qu’on peut encore descendre. The minimum amount of memory needed to install a Solaris system is 768 MB. However, for good ZFS performance, use at least one GB or more of memory. ZFS Hardware and Software Requirements and Recommendations La philosophie derrière ce choix et que de la RAM inutilisée est de la RAM gâchée, et en tant qu’ingénieur, je recherche l’efficience. L’apparente gourmandise de ZFS pour la RAM n’est pas un bug, c’est une feature. Choisir l’OS Avec de rapides recherches, on trouve les usual suspects des NAS maison : OpenMediaVault TrueNAS (anciennement FreeNAS), historiquement basé sur FreeBSD (Core), mais qui dispose maintenant d’une version Linux (SCALE) Depuis quelques années, on parle aussi pas mal de UnRAID, un OS orienté NAS sous Linux. Le produit est payant. En plus confidentiel, il y a aussi : XigmaNAS (ex NAS4Free, un fork de FreeNAS) RockStor (base CentOS + btrfs) Xpenology, un projet qui récupère le DSM de Synology, dont j’ai un gros doute sur la légalité ou même, l’OS QNAP qu’on peut installer sur n’importe quel matériel moyennant un coût mensuel La tribu réunifiée a décidé de vous éliminer Mes critères éliminent directement Windows (ce n’est pas vraiment comme si ça avait été un candidat sérieux 🤣). Quoique, j’avais fait brièvement du Windows Media Server à l’époque où ça existait encore, et aujourd’hui avec ReFS, on aurait presque (presque ?) un candidat pour un NAS de hobbyist. J’élimine aussi Xpenology, projet que je connais depuis très longtemps, et dans lequel je n’ai strictement aucune confiance. Et je pars de l’écosystème QNAP en partie à cause de son OS, donc ce n’est pas pour y retourner 😅 RockStor est trop confidentiel à mon goût, et je suis pas fan de btrfs qui a été trop instable pendant de nombreuses années. XigmaNAS (ex NAS4Free) a sûrement des arguments, mais c’est TrueNAS qui a tiré son épingle du jeu et raffle le gros de la communauté. UnRAID m’intéresse, mais le côté payant du projet est un problème. La version d’essai est très courte, et je n’avais pas spécialement le temps pour le tester de fond en comble au point de pouvoir décider si j’étais prêt à lâcher 49$ par an (tout de même !). Le choix final OpenMediaVault et TrueNAS (Core et SCALE) sont les alternatives les plus crédibles par rapport à mes critères. TrueNAS Core (sous FreeBSD) était mon premier choix, pour son support naturel du ZFS et aussi le fait que je voulais apprendre à utiliser l’univers BSD que je n’ai jamais exploré. C’était d’ailleurs FreeNAS que j’avais voulu choisir à l’époque (pour les mêmes raisons) de mon NAS de 2011, mais j’avais finalement choisi Ubuntu, car cette machine me servait aussi de mediacenter. TrueNAS dispose bien d’une interface web, de containers et de VMs (pour les deux versions). Cependant, plusieurs personnes m’ont alerté sur la possibilité que la version TrueNAS Core disparaisse à terme au profit de la version Linux (SCALE). Et le critère “gestion facile d’apps” n’est pas disponible sur Core (ce sont des charts helm, et Core n’a pas la fonction Kubernetes qu’à SCALE) Restait donc TrueNAS SCALE et OpenMediaVault, qui sont très similaires en termes de fonctionnalités et qui cochent toutes les cases. Et même si OpenMediaVault supporte ZFS, le fait que ce ne soit pas l’option par défaut m’a fait opter TrueNAS SCALE (mais ça aurait très bien pu être OMV). Installation Rien d’incroyable ici, il suffit d’installer l’OS comme n’importe quel autre linux. On suit la doc : on récupère l’ISO sur le site, on l’écrit sur une clé USB bootable et on suit ensuite le processus d’installation. TrueNAS SCALE demande 8 Go de RAM ou mieux. A mon avis, c’est surestimé (pour être large) et on doit pouvoir lancer SCALE dans de bonnes conditions avec moins, mais je suis content d’avoir pris 16 Go. TrueNAS SCALE is very flexible and can run on any x86_64 compatible (Intel or AMD) processor. SCALE requires at least 8GB of RAM (more is better) and a 20GB Boot Device. “Bêtement”, j’ai acheté un NVMe avec pas mal de patate de 512 Go, sauf que TrueNAS utilise tout l’espace par défaut. J’ai donc un NVMe quasiment inutile… Un peu rageant. Une fois installé, on redémarre la machine et on peut se connecter sur l’UI : Le dashboard principal est customisable : on peut modifier les tuiles qu’on veut afficher. Sur la gauche, les menus avec toutes les opérations courantes à réaliser sur le NAS apparaissent. Conclusion Je m’arrête là-dessus, on créera notre pool et les premiers partages lors des tests de performance dans le prochain article. D’ici là, have fun !

Cet article est un article “bonus” d’une série d’articles où je parle de mon nouveau NAS que j’ai construit moi-même. Vous pouvez retrouver la première partie ici, où je parle de la sélection matérielle : Mon NAS en 2024 - Jonsbo N2 × Intel N100 - hardware Plex sur mon NAS Un des prérequis quand je construis / achète un NAS, c’est la possibilité d’installer dessus Plex Media Server. D’expérience, même s’il est possible d’avoir une VM sur un hyperviseur à côté qui gère la médiathèque “à côté” du NAS, ou même de déléguer ce rôle “serveur plex” à la box de l’opérateur ou même notre smartTV, c’est souvent plus pénible qu’autre chose : je n’ai pas toujours un hyperviseur allumé à la maison et monté la médiathèque sur Internet est hors de question le volume partagé qui héberge les médias entre le NAS et la VM peut sauter, et c’est pénible à debug / corriger quand ça arrive les box / smartTV sont souvent trop limitées en hardware (espace disque pour les apps, CPU rachitique, RAM insuffisante…) je change de box opérateur plus souvent que de NAS Note : je suis certain qu’on ne sera pas d’accord avec moi sur certains de ces points, et c’est OK. Moi, je trouve que c’est mieux comme ça, mais vous faites bien comme vous voulez ;-P. J’ai donc envie d’avoir Plex sur mon NAS et de ne pas trop m’embêter pour la gestion au quotidien. Les “apps” dans TrueNAS Et ça tombe plutôt bien, car nos amis de chez TrueNAS maintiennent à jour une application Plex pour TrueNAS. Sauf que sur le papier, elle est pas hyper simple à installer, d’où cet article pour vous guider ;-). Tout cet article part du principe que vous utilisez TrueNAS SCALE et pas TrueNAS Core. Si vous ne connaissez pas la différence, le mieux est que vous alliez voir par vous-même la documentation officielle - compare TrueNAS software. TL;DR TrueNAS Core, c’est la version historique basée sur FreeBSD (qui s’appelait d’ailleurs FreeNAS, initialement). Cependant, depuis quelques années, iXsystems, l’entreprise qui développe TrueNAS, met à disposition une version basée sur Debian (donc GNU/Linux). Pour des raisons que j’expliciterai dans l’article sur le choix du software (oui je viens donc de vous spoiler l’article suivant), j’ai TrueNAS SCALE et pas Core. Pour faire tourner les “apps”, TrueNAS s’est appuyé sur un standard du marché : Kubernetes. Et oui, n’en déplaise à ses détracteurs, Kubernetes est devenu un standard du marché. Ca ne dit pas si c’est une bonne chose (on peut juger le précédent standard, aka VMware, à l’aune de l’actualité, par exemple). Mais c’est juste un fait. Activer les apps Par défaut, TrueNAS n’active pas les “apps”. Ca va être à nous de le faire. En soit, ce n’est pas forcément un mal : si vous n’en avez pas besoin aucune raison de consommer des ressources pour rien. Et quand on parle de consommation de ressources et de Kubernetes je vois déjà les gens dans le fond qui font les gros yeux. Rassurez-vous (pas sûr que ça vous rassure, mais moi oui), les équipes d’iXsystems ont eu la sagesse de choisir k3s et non un kubernetes vanilla pour héberger Kubernetes sur notre NAS. Les ressources consommées par le control plane seront donc minimales (quelques centaines de Mo au max). On va donc dans l’onglet “Apps” et on active k3s en l’installant simplement sur un de nos pools. Dans mon cas, j’en ai deux. Un avec mes disques durs classiques, et un avec un (unique) SSD. Initialement j’avais installé le k3s sur le pool de HDDs, histoire de mutualiser le stockage et de maximiser la disponibilité (j’ai un RAID-Z1). Cependant, le k3s de TrueNAS a tendance à écrire pas mal sur les disques, qui se retrouvaient à gratouiller sous mon bureau pendant une demie seconde toutes les 5 secondes environ. Très énervant. J’ai donc recréé un pool spécial pour les apps sur un SSD que j’avais en rab. On clique sur Settings en haut à droite, puis Choose Pool Installer plex media server via les apps Au bout de quelques secondes / minutes, k3s est installé et on peut commencer à chercher une app parmi le catalogue (>100). Ici on recherche plex et on clique sur Install A partir de là, une fenêtre avec plein de paramètres va apparaitre. Mais avant d’aller plus loin, on va aller sur la page https://www.plex.tv/claim/. Une fois loggué sur votre compte, la page va vous générer un token temporaire, qui va permettre de relier directement le serveur une fois qu’il aura démarré sur votre NAS avec votre compte. Pratique ! Dans la looongue page de configuration, on a que quelques paramètres à changer. D’abord, il faut renseigner le token qu’on vient de générer dans la section Plex Configuration. Si vous avez le Plex pass, vous pouvez aussi changer Image : Ensuite, dans la partie Storage configuration, il va falloir indiquer le chemin vers le pool qui contient les médias. Moi c’est /mnt/rpool/tank/Vidéos. rpool est le nom de mon pool RAID-Z1, tank est mon volume principal. Attention : assurez-vous que l’utilisateur unix (local) “apps” a bien accès en lecture/exécution sur toute l’arborescence, sinon vous ne verrez pas le dossier quand Plex sera lancé (très frustrant, il n’y a aucun message d’erreur, juste “rien”). De manière optionnelle, vous pouvez tuner les “limits” (au sens docker/kubernetes du terme) de votre app. Par défaut, la chart plex de TrueNAS propose 4 CPUs et 8 Go de RAM, ce qui est beaucoup. Mon plex ne consomme que 100 Mo au repos. J’ai baissé à 2 CPUs (avec un risque de throttling, mais là on rentre dans des notions un peu tricky de Kubernetes que je préfère esquiver aujourd’hui dans cet article) et 4 Gio de RAM (j’en ai 16 mais je veux garder le plus de cache possible). Une fois terminé, l’application se déploie, puis affiche Running. On a alors un cartouche Application Info dans Details qui devrait afficher un bouton Web Portal qui devrait nous rediriger sur l’IP de notre NAS sur le port 32400 (celui habituel de plex). On peut donc se laisser guider par le wizard de configuration de Plex Media Server, lui donner un nom mignon et aller chercher nos médiathèques dans /data. Normalement, le dossier que vous avez donné lors de l’étape Storage configuration devrait apparaitre.
Bonus Pour une raison que j’ignore (peut être parce que c’est un container avec un adressage à part), j’ai dû explicitement indiquer le port public (32400 sur ma box, qui redirige sur l’IP de mon NAS et le port 32400) pour que le Control à distance fonctionne et que l’accès direct (sur le réseau local) fonctionne correctement.

Cet article fera partie d’une suite d’articles dans lesquels je sélectionne, construit et teste mon nouveau NAS. Mon NAS, quatrième itération ? Depuis 2011, je change de NAS régulièrement. 2011, c’était de la récup’ (un vieux Qbic Soltek, une carte mère avec un Atom fanless). 2014, c’était encore plus bidouille, car j’avais juste posé une carte mère dans mon Red Helmer. 2018, j’en avais marre de gérer moi-même l’OS, les problèmes d’upgrades de l’OS, etc. J’étais donc passé sur un NAS du commerce (un QNAP). Après 6 ans de bons et pas très loyaux services (QNAP désactive des features au fur et à mesure), j’ai décidé de m’en reconstruire un nouveau, moi-même. Les critères hardware À force d’itérations, je commence à savoir ce que je veux / ne veux pas pour mon NAS. En voici la liste : quatre emplacements un ou plusieurs ports ethernet 2.5 Gbps un beau boitier, qui fasse un peu sérieux, relativement compact (pas une tour) pas de bruit, peu de chauffe une consommation électrique raisonnable possibilité de hotswap les disques Ces critères sont surtout hardware, mais j’en rajoute qui est plutôt software, tout en restant lié au hard : la possibilité de faire des machines virtuelles (si jamais j’en ai l’envie) et des containers Le choix des composants C’est l’étape la plus compliquée quand on fait un NAS DIY. Le problème principal est de trouver un boitier qui convient. Ça fait des années que je cherche (même en 2011 / 2014) et souvent les boitiers sont rares, chers, volumineux et/ou moches. Le côté hotswap et fréquemment absent. Heureusement, j’ai trouvé un boitier qui coche toutes les cases, même s’il est difficile à trouver en France : le Jonsbo N2. J’avais entendu parler de cette marque sur Next Inpact avec le Jonsbo N1, plus compact, mais qui n’avait pas de hotswap. Le Jonsbo N2 corrige ce défaut. C’est grosso modo un cube de 22 cm de côté, il est plutôt beau même si un peu gros à mon goût.
Niveau compatibilité, on peut l’alimenter avec une PSU au format SFX et une carte mère au format Mini ITX. C’est relativement attendu, vu la compacité, mais ça nous rajoute tout un tas de problématiques complémentaires. Alimentation D’abord, les alimentations SFX sont plus rares, plus chères et moins efficaces. Trouver un modèle peu puissant, économe, bon marché et semi-passif (pour le bruit) est impossible. Le mieux que j’ai trouvé est une alimentation Be Quiet SFX Power 3 de 300w. Elle n’est pas semi-passive (donc fait continuellement du bruit, même si c’est raisonnable) et seulement 80Plus Bronze (donc il y a des pertes significatives d’énergie). En alternative, j’aurais pu prendre (à vérifier, la taille n’est pas claire) les SFX-L de Be Quiet, qui ont l’avantage d’être 80 Plus Gold et modulaires. Carte mère Ensuite, les cartes mères mini-ITX ont souvent peu de ports SATA, ce qui ne colle pas avec mon besoin de quatre disques. À partir de là, il y a 3 solutions, aucune n’étant vraiment “ouf”. La plupart des cartes Mini ITX ont 2 (voire 1) ports SATA, mais certaines ont aussi des ports M.2 pour NVMe et/ou un port PCIe : Il existe des adaptateurs 1 NVMe => 6 SATA Il existe des cartes d’extension PCIe => SATA
Mais je n’ai absolument pas confiance dans la qualité de ces machins, donc j’ai abandonné l’idée. D’autant que j’aurais peut-être besoin du port PCI-e pour ajouter une carte d’extension pour avoir le 2.5 Gbps. J’avais trouvé une carte avec quatre ports SATA et le support du socket AM4 (exemple ASRock B550M-ITX/AC). Si je rajoute un Ryzen 5 5600G, je coche la case “possibilité de faire des VMs”, mais c’est relativement cher (~260€ au total) et surtout le CPU consomme beaucoup d’électricité (TDP 22w). Dernière solution, il existe aussi quelques OVNI comme la carte ASRock Rack X570D4I-2T avec des ports OCuLink permettant de gérer 4 SATA chacun, mais c’est quasiment impossible à trouver et très cher. En fouillant Aliexpress, je suis assez vite tombé sur ce genre de modèles de cartes “noname” :
Il existe plein de modèles et de variations du même genre de cartes. Grosso modo, c’est un chipset intel compatible Atom de différentes générations avec 4 ports Ethernet 2.5 Gbps, 6 SATA, parfois fanless, parfois non. Sur le papier, c’est pile ce que je cherche. J’ai une carte mère et son N100 (seulement 6w de TDP) + ventirad qui coche tous mes critères. Il faut juste pas trop avoir peur du côté “carte mère noname”. J’ai pris le risque, j’ai choisi cette carte, que j’ai réussi à avoir autour de 200€ (ici 250 sur la capture d’écran). Misc Pour installer l’OS de mon NAS, j’ai ajouté un SSD NVMe de 500 Go (le moins cher de marque que j’ai trouvé). J’ai aussi ajouté 16 Go de RAM DDR5, dans l’idée que j’aurais peut-être besoin de ça pour des containers / VMs. Comme je n’ai pas encore de réseau en 2.5 Gbps chez moi, j’ai donc dû faire l’upgrade. J’ai choisi un switch “noname” sur Aliexpress (là encore), une carte PCI-e pour mon PC perso. Pour les disques, j’ai fait l’erreur (on en reparlera) de récupérer des vieux disques Western Digital Red de 4 To que j’avais en stock…
Montage Le boitier est très beau, bien conçu, semble être de bonne qualité / bonne facture. La carte mère est en haut, l’alimentation se positionne sur le bas + côté et les disques de l’autre. Côté carte mère, elle est livrée avec une grosse surface de contact en cuivre sur laquelle j’ai ajouté le ventirad low profile.
Pour être parfaitement honnête, je me demande si le ventilateur est réellement nécessaire. On en reparlera dans le prochain article. Pour pouvoir être hotswap, les disques durs sont connectés à un backplane, aéré par un ventilateur low profile (15 mm d’épaisseur) que j’ai remplacé par un 25mm (classique) car j’ai lu qu’il était bruyant. Le souci, c’est qu’il y a très peu d’espace, pas assez pour un 25mm, mais ça rentre au chausse-pied.
Note : il existe des plans d’impression 3D pour corriger ce problème, si nécessaire. Mais je n’en ai pas eu besoin. Conclusion Une fois le montage fini, je trouve ça plutôt clean :)
Dans le prochain article, on parlera des différents tests de performance que j’ai réalisés.

Note : cet article est la version longue / version litteraire, d’un long thread Twitter, et du débat qui a suivi. Il s’agit de mon expérience personnelle et tout le monde n’est pas d’accord avec mon point de vue. YMMV comme disent les anglosaxons. Marronnier et contexte Début avril, j’ai lu un message qui m’a fait tiquer sur Twitter. Grosso modo, une personne (j’irai même jusqu’à dire “un habitué”) raconte que “les gens” qui vont faire des talks en conférence, le font pour l’argent, allant même jusqu’à affirmer qu’un speaker lui aurait secrètement avoué que depuis qu’il était speaker, son salaire avait été multiplié par 3. Argent, théorie du complot, société secrète. Tout ce qu’il faut pour buzzer sur X. Alors bien sûr, quand d’autres personnes viennent expliquer que non, eux le font par passion, l’énergumène leur répond par un GIF d’une personne qui nage dans des billets de banque avec comme légende “la passion en question” (ça vous donne une idée du niveau de l’argumentaire du bonhomme). Donc allons-y : qu’est-ce que j’en pense, moi ? Me, myself and I Je suis speaker depuis 2018, avec une trentaine de talks, quelques podcasts, quelques interviews à mon actif. J’imagine que je rentre donc dans la catégorie des “habitués” des confs en France dont on parle ici. Plus récemment, je suis aussi organisateur de conférences (KCD France 2023, BDX I/O 2024). Et avant ça, je blogue ici depuis 2010, avec plus de 400 articles techniques, des milliers d’heures (sur mon temps personnel) à faire de la veille, tester des trucs, rédiger, poster, améliorer ce blog. Un investissement en temps et en énergie considérable. Pour rappel (ou info ???), tout ceci est entièrement bénévole. L’écosystème tech français ne rémunère pas les speakers ou les orgas en conférence (sauf exceptions très rares). Je ne tire pas un centime de cet engagement personnel. Et la question est donc : est-ce qu’en échange de tout cet engagement personnel pour la communauté, j’ai multiplié mon salaire par 3 depuis 2018 ? TL;DR : non. J’ai un très (très) bon salaire, mais clairement, je n’ai pas triplé mon salaire depuis 2018. Ni même doublé. Et les confs n’y sont pour rien dans les augmentations que j’ai eues (le full remote a eu bien plus d’impact, par exemple). Back to reality On passe notre temps à nous dire qu’il faudrait avoir des side projects pour se différencier au moment du tri des CVs ou pendant les entretiens. La réalité que moi, j’ai expérimenté est tout autre. La plupart du temps, lors des entretiens que j’ai pu passer ces cinq dernières années, la mention (pourtant bien visible sur le CV et j’insiste oralement) de mon blog est ignorée. Ça me met un peu en rogne, car j’en retire une grande fierté. Pour ce qui est de l’expérience en tant qu’organisateur de conférences ou de mon “habitude” d’aller en conférence partager des sujets, dans la grande majorité des cas, c’est aussi ignoré. Au pire, c’est vu comme une contrainte plus qu’un atout. Pour illustrer ça, on m’a dit lors d’un processus de recrutement : Denis, c’est bon ! J’ai négocié avec le CTO, tu pourras aller en conférence de temps en temps. Euh… Merci ? Note : pour être parfaitement honnête, il y a eu deux exceptions, où c’était vu comme quelque chose de chouette, mais avec un peu de méfiance quand même, notamment sur la fréquence ou sur le hype driven development. Pour beaucoup d’entreprises, sortir du cadre de ce qui est prévu pour les salariés est impensable. Et comme beaucoup n’ont pas ou plus (post COVID) de stratégie concernant la marque employeur ou les contributions externes à l’écosystème tech, aller en conférence présenter le travail de l’entreprise n’est pas vu comme une partie de mon travail en tant que “staff engineer”, mais comme un “privilège”. Mon actuel employeur accepte que j’aille en conférence et que je prépare en partie mes sujets sur mon temps de travail, et me paie le transport et l’hébergement pour aller à ces conférences. C’est déjà mieux que beaucoup de speakers qui doivent tout faire sur leur temps perso, et parfois doivent poser des congés, voire se payer les transports eux même si quand ils sont pris comme speaker. Certains speakers dépensent beaucoup d’argent pour partager leur passion et ça me fait ch**r qu’on fasse croire qu’ils le font pour s’enrichir, alors que c’est l’inverse. Tout n’est pas à jeter non plus Il y a cependant des avantages réels à participer à des conférences en tant que speaker. D’abord, ça force à bosser et se documenter sur des sujets que vous pensez maîtriser. Le risque à ne pas le faire, c’est que vous disiez une énormité et qu’une personne vous le fasse bruyamment remarquer. Pas super agréable. Donc, on se documente et on apprend beaucoup. Autre avantage indéniable, ça entraîne à la prise de parole. Ça peut paraître difficile à croire, car j’ai l’air à l’aise en public aujourd’hui, mais j’ai longtemps été paralysé en groupe par une phobie sociale. Aller en conférence est un moyen (certes un peu brutal) de dépasser ce genre d’angoisses : après le talk, les gens viennent vers vous d’eux-mêmes, vous n’avez pas à combattre l’angoisse de leur parler, et en plus, ça sera un sujet que vous maîtriserez. Le vrai “game changer”, le réseau Dernier point, qui a été évoqué sur Twitter à un moment : ça agrandira considérablement votre réseau. Toutes les opportunités intéressantes que j’ai eu récemment, j’ai su qu’elles existaient grâce à mon réseau. Attention, ça ne veut pas dire que j’ai directement eu le poste ! J’ai passé les entretiens comme les autres et j’ai ensuite eu le poste, ou pas ! J’ai juste eu connaissance de ces opportunités GRÂCE à mon réseau, sans passes droits. Cependant, il y a 1000 autres façons de se faire un réseau pro. Les conférences ne sont qu’une manière parmi d’autres et je ne vois personne s’insurger contre ça. Pourquoi se faire un réseau en conférence serait une mauvaise chose (spoiler, ça n’en est pas) ? Conclusion On en a beaucoup discuté sur Twitter et j’ai échangé avec des gens pour qui faire des conférences avaient eu un impact significatif sur leur carrière. Tant mieux pour elles/eux, c’est mérité ! Mais je pense qu’il ne s’agit pas de la mentalité majoritaire des entreprises, en particulier en France. Sauf exceptions, faire un amphi bleu DevoxxFR ne vous rendra pas riche. Tripler votre salaire (ou même juste l’augmenter) n’est pas une fin en soi. À vous de savoir si vous avez besoin de cet argent ou pas. Avoir un salaire à six chiffres peut quand même faire de vous un individu triste comme les pierres. Bref : ne soyez pas speaker (ou écrire un blog, ou écrire un livre tech) parce que vous pensez que vous allez en retirer de l’argent. Faites-le parce que partager sa connaissance, c’est hyper gratifiant et ça vaut tous les dramas Twitter.

Cet article fait partie d’une suite de 4 posts : Récap du premier jour de Kubecon Europe 2024 - Mardi - colocated events Récap du (vrai) premier jour de Kubecon Europe 2024 - Mercredi Récap du deuxième jour de Kubecon Europe 2024 - Jeudi Récap du dernier jour de Kubecon Europe 2024 - Vendredi This is the end 4ème (en comptant les colocated events) et dernier jour de Kubecon. C’était intense !! La keynote de la journée a été ouverte par Chris Anisczcyk, CTO de la Linux Foundation (CNCF). Quelques chiffres amusants : c’est la 20ème Kubecon, en juin 2014, Kubernetes a été open sourcé (il aura donc 10 ans cette année).
Chris a fait un petit récap du chemin parcouru depuis cette date : 2015 - Kubernetes devient 1.0 novembre 2015, première Kubecon à San Francisco avec seulement quelque centaines de participants 2016 - création de la CNCF 2019 - Création des événements KCD 2020 - Création des Cloud native community groups Pour fêter les 10 ans de Kubernetes, la CNCF a créé un site kubertenes.cncf.io. Dernier point, un nouveau groupe de personnes reconnues dans la communauté a été créé (en plus des ambassadors), les Kubestronauts. Il s’agit des personnes qui ont fait toutes les certications (CKA, CKAD, CKS, KCNA, KCSA). Keynote: Success Not Guaranteed La keynote suivante, de Bob Wise, CEO de Heroku, était aussi, d’une certaine manière, un regard dans le rétro, mais plus orienté sur sa propre carrière… Bob Wise a déroulé les choix dans sa carrière qu’il a dû faire pour créer du “cloud native” quand ça n’existait pas encore. We had built our own orchestration system, everything was working in dev, but not in prod Lorsqu’il était dans la team Coud Native de Samsung, Bob a parlé des obstacles que lui et son équipe avaient décelé et qui auraient pu freiner l’adoption de Kubernetes. Le premier était les problématiques de performance (comment dépassér les 100 nodes, supporter plusieurs patterns de déploiements, comme par exemple des clusters multi AZ). Ces challenges ont été traités par le Scaling SIG dont il faisait partie. Le second était la gouvernance. Bob a estimé que la création de la CNCF et que la standardisation des containers avec OCI plutôt que forker docker avaient été les “bons moves”. Open source is not enough, you need true community gouvernance Keynote: A 10-year Detour: The Future of Application Delivery in a Containerized World À croire que réminiscence était le mot d’ordre de la journée, car c’était ensuite au tour de Solomon Hykes de jeter un coup d’œil dans le rétroviseur. Cependant, lui l’a fait avec de la sensibilité et une touche d’humour qui était très agréable. Solomon a reparlé de son parcours, notamment au sein de dotCloud puis de Docker, de ce qui a mené à l’adoption de la technologie des containers Serious people don’t launch serious workloads in the cloud Après avoir expliqué qu’on ne devait pas céder aux sirènes de la nostalgie en repensant aux PaaS des années 2010 (en mode “winner takes all”), et qu’il ne fallait pas y revenir. Pour finalement changer complètement de sujet et parler tout à coup d’usine logicielle (“ne pas céder à la tentation de tout faire soi-même”). Difficile de ne pas y voir un clin d’œil à Dagger.io. Keynote Panel Discussion: Unity in Diversity: A Decade of Inclusive Growth in the Cloud Native Community Kasper Borg Nissen a animé un panel sur la diversité dans l’écosystème cloud native : Jinhong Brejnholt, Saxo Bank Andrea Giardini, Independent Anastasiia Gubska, BT Group Stéphane Este-Gracias, ITQ
Au travers des différentes actions des panélistes, nous avons pu nous rendre compte qu’il existe de nombreuses initiatives pour rendre la communauté cloud native plus diverse, plus durable (au sens écologique du terme). On a parlé du SIG deaf and hard on hearing, des non-code contributions (la documentation), de Kubetrain (l’initiative visant à venir à la kubecon en train sponsorisé), des KCD, … Le témoignage de Anastasiia Gubska (sourd-muette) était particulièrement fort, touchant, inspirant. Three’s a Crowd: How to Achieve 2-Node HA at the Edge and Make Your CFO Smile Tyler Gillson et Pedro Oliveira de Spectro Cloud (les développeurs principaux de Kairos, une distribution de Kubernetes) nous ont présenté les challenges qui les ont motivés à trouver une solution pour obtenir un cluster Kubernetes en “edge” avec seulement deux machines et non pas trois. Les problématiques edges sont particulières. On ne peut pas se permettre dans certains cas de ne se reposer que sur un seul node, au risque d’avoir un SPOF. On ne peut pas non plus utiliser de cluster etcd externe ou de compter sur un “witness” (3ème vote, pour un quorum) car on peut avoir une mauvaise connectivité. Le but était aussi de pas réinventer trop de choses, notamment dans les couches basses. Il a donc été choisi d’utiliser k3s avec kine (kine is not etcd) avec une base postgres en mode actif passif. Si le nœud principal tombe en panne ou devient inaccessible, le nœud secondaire est promu, l’instance postgres devient principale et le control plane du node secondaire est redémarré. En théorie, ça fonctionne, sans trop de choses à modifier. La démo n’a malheureusement pas fonctionné, mais la discussion qui a suivi avec les développeurs du projet était très intéressante. Trimaran: Load-Aware Scheduling for Power Efficiency and Performance Stability Asser Tantawi & Chen Wang d’IBM nous ont présenté des plugins pour le scheduler qui permettent de placer de manière plus intelligente les pods sur les nodes, via un calcul de “score” basé sur des données des nodes et de statistiques. Il en existe pour l’instant trois, mais il est en théorie très facile d’en écrire des similaires en modifiant les paramètres.
À tester. Sponsors Une conférence comme la Kubecon se fait surtout grâce à la présence des sponsors. Au cours de ces 3 derniers jours, j’ai pu faire le tour des sponsors. J’ai eu des discussions intéressantes avec Canonical, OVHCloud, Rancher, Nirmata (Kyverno), Isovalent, Mirantis, Otterize, Postman et VictoriaMetrics. J’ai passé aussi beaucoup de temps sur le “rooftop”, pour parler avec des gens de tous les horizons, certains ayant des problématiques très semblables aux nôtres sans qu’on le sache (coucou Boursorama !). Merci à toustes pour ces grands moments :). See you next year?

Cet article fait partie d’une suite de 4 posts : Récap du premier jour de Kubecon Europe 2024 - Mardi - colocated events Récap du (vrai) premier jour de Kubecon Europe 2024 - Mercredi Récap du deuxième jour de Kubecon Europe 2024 - Jeudi Récap du troisième jour de Kubecon Europe 2024 - Vendredi TODO Keynote: 🇫🇷 Hip, Hip, Beret! No Cap, Just Cloud Native Facts Dans cette keynote d’ouverture, Taylor Dolezal, Head of Ecosystem de la Cloud Native Computing Foundation nous a présenté quelques statistiques de la CNCF, avec un focus particulier sur les contributions des “end users”. Sans surprise, Backstage arrive comme d’habitude largement en tête, avec KCL et Argo ensuite. Pour faciliter les contributions, la CNCF a lancé un programme “from Zero to merge project” pour inciter les personnes qui n’osent pas contribuer à le faire. À voir si c’est vraiment utile, ou non ? Keynote Panel Discussion: Revolutionizing Cloud Native Architectures with WebAssembly Le talk suivant était un panel avec : Ralph Squillace, Principal Product Manager, Microsoft Michelle Dhanani, Principal Software Engineer, Fermyon Technologies Kai Walter, Distinguished Architect, ZEISS Pour faire simple, Michelle Dhanani nous a montré les avantages de lancer des workloads WASI (WebAssembly mais côté serveur, pas dans un navigateur) depuis Kubernetes, avec une mini-démo. Pour en savoir plus, je suis allé voir une session dans l’après midi. Suite à cette keynote, j’ai écouté d’une oreille la suite (les awards pour les end users) mais pas de quoi en faire un récap. We Tested and Compared 6 Database Operators. The Results are In! Ce talk avait été fait en français l’an dernier à KCD France. J’en avais eu d’excellents retours, mais je n’avais pas vu le voir puisque j’étais moi même organisateur de l’événement (eh oui, c’est le côté ingrat de l’orga ;-P). Jérôme Petazzoni et Alexandre Buisine ont fait un REX de l’usage des opérateurs de base de données pour les clients d’Enix, le tout en étant habillés comme des Pirates. Voici les 6 opérateurs qui ont été comparés : CNPG, StackGres, postgres-operator (Zalando) Moco, mariadb-operator, percona operator Sur une liste de critères (d’opérabilité surtout), Jérôme et Alex ont comparé les différents opérateurs et expliqué pourquoi ils les aimaient / n’aimaient pas, et à la toute fin, lesquels ils utilisent en production. Plutôt que de tout paraphraser, voici les slides : Lien docs.google.com Kubernetes Controllers in Rust: Fast, Safe, Sane Le talk que j’ai vu ensuite était une présentation de Matei David, ingénieur chez Buoyant (les développeurs de Linkerd). Matei nous a expliqué qu’une des raisons (ce n’est pas la seule) pour laquelle la plupart des controllers d’opérateurs Kubernetes sont codés en golang : les libraries client-go et controller-runtime sont les bibliothèques les plus complètes pour interagir avec l’API server. Cependant, ça ne veut pas dire que rust n’est pas un langage de choix pour coder des operateurs. Il existe un crate kube-rs, qui est l’équivalent de client-go et qui permet déjà de rédiger du code de qualité pour intéagir avec Kubernetes. Il existe kubert qui ajoute une couche d’abstraction au code rust pour coder des opérateurs. Matei a ensuite montré des exemples de codes et expliqué pourquoi ils avaient commencé à écrire du code rust pour Linkerd (problématiques complexes de mutex en go et gestion de la mémoire plus safe en rust). N’était pas très à l’aise en rust, j’ai compris juste assez pour que ce soit intéressant, mais pas assez pour avoir envie de tester. C’était un bon talk. Leveling up Wasm Support in Kubernetes Ce talk sur les produits de Fermyon Spin et KubeSpin était relativement intéressant. C’était une version longue de la keynote du matin, avec les mêmes intervenants, et une démo plus longue et live. Pour faire simple pour ceux qui ne sauraient pas, WASM est un format permettant d’exécuter du code bas niveau sur n’importe quel device et n’importe quel architecture dans un environnement sandboxé et sécurisé. boring definition: it’s another bytecode format Pour donner un exemple concret, Figma utilise du code C++ compilé en WASM pour exécuter du code nécessitant des performances importantes depuis un navigateur et importé simplement avec du javascript. On nous a présenté Spin, un ensemble d’outils pour développeurs permettant de faciliter l’adoption de WASM dans un environnement serverless, puis SpinKube, le framework permettant de faciliter l’intégration de ces stacks dans Kubernetes. Spin is like “rails” SpinKube utilise runwasi, un containerd shim écrit en rust (encore du Rust…). La démo (sur 5 RPi) était sympa et donne envie de tester. Keeping the Bricks Flowing: The LEGO Group’s Approach to Platform Engineering for Manufacturing Ce talk de Mads Høgstedt Danquah & Jeppe Lund Andersen, de The LEGO Group, était mon petit bonbon. Comme beaucoup de nerds, je suis un fan de briques Lego depuis mon enfance et travailler là-bas serait un peu un rêve. Je ne suis donc pas du tout objectif dans mon récit de ce talk. Mads et Jeppe ont commencé par poser le décors. Lego est une entreprise industrielle qui se repose beaucoup sur l’automatisation pour rester compétitive. Il y a donc beaucoup de machines, nécessitant beaucoup de services logiciels et donc beaucoup d’infrastruture. Ce talk était donc un REX des pratiques que The Lego Group a mis en place pour obtenir une infrastruture agréable à utiliser pour ses 1200 ingénieur⋅es logiciels. Voici quelques conseils qu’ils ont pu donner au cours de la présentation : Provide a cloud like experience (self service, API enabled) accessible with IDP User adoption is not a given, it must be earned. But how do we earn our users trust? Focus on early value
Private on-prem cloud is way easier than it ever was
Value time over quality Quality over speed (pick from the landscape) Words to live by. Make Your Cluster Fly: Embed a Multi-Node Kubernetes Cluster Inside an Aircraft Using Puppet & Flux En toute fin de journée, je suis allé voir ce talk de Thalès de Alexis Bonnin & Guillaume Maquinay. En réalité, j’y suis allé parce que je connais quelqu’un qui a participé en partie à ce projet et j’avais envie de voir ce qu’ils allaient en dire, même si j’étais bien fatigué de la journée… Grosso modo, Alexis et Guillaume ont bien présenté les problématiques liées à des avions qui n’ont par définition par toujours du réseau et qu’il faut réussir à mettre à jour de manière automatisée et industrialisée dans des conditions pas habituelles (edge). Si les technos ne sont pas super sexy (Puppet ☠️☠️☠️), les challenges sont intéressants, car non conventionnels, et nécessite des solutions à base d’operator pour éviter de pull des images quand on a plus de réseau. Blabla Honnêtement, j’ai vu tellement de monde aujourd’hui que ça n’a plus vraiment de sens d’en faire une liste. J’ai eu plusieurs conversations super enrichissantes avec Aurélie, Stéphane, Théotime et Eddy sur le stand OVHCloud, au café avec Laetitia, passé un bon moment avec Zed pendant la pause, profité de la team deezer pendant le déjeuner et au food court le soir, revu Thoms (le bouncer) et Christian totalement par hasard dans le métro en rentrant de diner… Et surtout, j’ai fait une super photo avec la team frenchies sur le rooftop : Good times.

Keynotes Aujourd’hui, c’est mercredi. C’est donc parti pour les premières Keynotes !! Priyanka a commencé par nous donner quelques chiffres sur l’édition en cours (qui va rassembler 12000 personnes sur site, la plus grosse Kubecon de tous les temps). Elle a ensuite donné le ton pour les prochaines keynotes (et aussi toute la conférence, en vrai). AI is everywhere, with irrational exuberance Même si Kubernetes a maintenant 10 ans, il est probable qu’on en parle encore pendant un moment, puisque ce sont aujourd’hui les technologies “cloud native” (et donc Kubernetes) qui sont la base de cette révolution de l’IA. Elle a ensuite insisté sur le fait qu’à l’instar de ce qui avait pour standardiser les technologies liées aux containers (OCI par exemple), il allait falloir s’extirper du modèle propriétaire dans le monde de l’IA. Elle a terminé par une petite démo à base de LLAVA / BAKLLAVA (description d’images) et ollama (model registry service) github.com/cncf/llm-in-action
Panel Juste après, elle a accueilli 3 personnes du monde de l’IA Timothée Lacroix - Mistral Paige Bailey - Google Jeffrey Morgan - Ollama Il y a eu quelques discussions intéressantes dans ce panel : Ollama est très proche de l’architecture des projets cloud native, tout simplement par ce que son créateur a travaillé dans ces technologies pendant 10 ans Mistral utilise Kubernetes pour s’abstraire de toutes les problématiques d’infrastructure et se concentrer sur sa valeur ajouté il y a beaucoup d’Opensource washing en ce moment Accelerating AI Workloads with GPUs in Kubernetes La keynote suivante, présentée par Kevin Klues et Sanjay Chatterjee, parlait du travail qu’il reste à faire pour tirer parti au maximum des GPUs dans Kubernetes. Il y a deux niveaux d’améliorations sur lesquelles il faut travailler : bas niveau : comment rendre les GPUs mieux “partageable” haut niveau : comment rendre “topology aware” nos clusters Kubernetes et nos workloads Sans trop rentrer dans les détails, il reste du travail, mais ça avance. Quand j’ai regardé la suite des keynotes (AI, AI, AI, AI, …), j’ai laissé tomber et je suis parti faire un petit tour des sponsors… 10 Years of Kubernetes Patterns Evolution Étant administrateur de cluster Kubernetes en production depuis bientôt 8 ans, je n’ai pas appris grand-chose à cette session. Cependant, ce talk était très agréable. Les speakers Bilgin Ibryam & Roland Huss sont pédagogues et quand j’ai appris qu’ils étaient en fait les auteurs du livre “Kubernetes patterns”, j’ai voulu le récupérer. L’idée du livre (et de ce talk, qui en est une version très raccourcie) est de lister des éléments de design réutilisables pour concevoir des applications cloud native. Note : l’idée de ce livre est inspirée d’autres livres plus anciens, comme “A Pattern Language”, un livre d’architecture, et “Design patterns” (principes logiciels orienté objet) Les auteurs ont présenté les patterns suivants : Health probes Structual patterns (avec l’exemple du sidecar) Behavioural patterns (avec l’exemple du singleton) Configuration patterns Security patterns Advanced patterns Je suis allé récupérer le livre juste après ;-) Impossible de rentrer dans les salles Je suis vraiment en colère. Je n’ai pas pu rentrer ni dans I’ll Let Myself In: Kubernetes Privilege Escalation Tactics (pourtant au même niveau dans le bâtiment), ni dans Crossplane Intro and Deep Dive - the Cloud Native Control Plane Framework. Les files interminables pour rentrer dans les salles semblent être la norme cette année (encore). A quoi bon faire venir 12 000 personnes sur site si c’est pour que la moitié d’entre elles se retrouvent obligés de regarder les talks en replay trois semaines plus tard ? Podcast et Brussels Beer Project Pour ne rien arranger, j’ai dû partir tôt, car j’avais l’enregistrement d’un podcast qui était prévue de longue date. Je n’ai donc pas pu tenter ma chance dans une autre session, mais j’ai cru comprendre que c’était à peu près pareil. L’après midi n’était pas perdue pour autant puisque après le podcast, j’ai pu prendre un verre avec mes collègues parisiens que je ne vois pas si souvent que ça. Networking, again J’ai eu la chance de pouvoir parler un long moment avec mon ex-binôme et ses collègues de BackMarket. La discussion était productive ;-). J’ai aussi croisé Mathieu, Philippe, James, Nicolas, Remy et par un hasard à peine croyable, Paul.

Mardi Cette année, pas de DevoxxFR pour moi (c’est pendant les vacances scolaires de Bordeaux). En revanche, je participe à la Kubecon Europe 2024, qui se déroule cette année à Paris ! Les deux précédentes Kubecon que j’ai faites en présentielles (2018 et 2022), je n’avais pu participer qu’au 3 jours (““seulement”” mdr) de conférences, pas les “colocated events” qui se déroulent un jour avant. Cette année, je teste donc l’expérience complète (qui a même commencé lundi, avec la “Kubetrain party” où j’ai été gentiment invité :-D). Platform Engineering day En première partie de journée, j’ai décidé de choisir de regarder les talks de la track “Platform Engineering Day”. Ce colocated event se concentre sur les problématiques de “developer experience”, c’est-à-dire, comment améliorer l’expérience qu’ont les développeurs pour que le temps entre l’écriture du code et le moment où il est en production soit le plus court possible. Ça nécessite évidemment un changement de mentalité (on parle de shift-left), car plus d’autonomie nécessite également plus de responsabilités. Note : la liste des talks de cette journée est disponible sur un sched.com séparé. Sometimes lipstick is just what a pig need J’ai vraiment adoré ce talk, qui est une très bonne introduction aux problématiques de la dev experience. Le talk est très bien présenté, plein d’énergie positive, avec la juste dose d’humour. C’était aussi très malin de le mettre en tout début de journée. Le pitch du talk était de démontrer que dans certains cas, les différents types d’interfaces versus les fonctionnalités qu’elles ont sont parfois peu pratiques, mais il est difficile de mettre le doigt sur LA raison pour laquelle, c’est le cas. Abby Bangser et Whitney Lee ont fait tourner deux “roues” aléatoires pour faire des paires interface/capabilities : Pour chaque paire, elles ont essayé de trouver des interfaces existantes, puis elles se sont demandés quels problèmes pouvaient avoir ces interfaces. Et à chaque exemple, nous avons exploré un axe de réflexion pour ces paires : Autonomy L’échelle de l’autonomie qu’on souhaite donner à notre application et sa fonctionnalité. Exemple : si un développeur veut déployer un service ou une brique d’infrastructure : Est-ce qu’on veut donner un portail (exemple Backstage) aux développeurs pour qu’ils puissent déployer des objets eux même en prod ? Est-ce qu’on veut juste ouvrir un ticket pour demander de l’aide à un administrateur. Contextual distance Est-ce qu’on reste sur le même outil (un plugin d’IDE), ou est-ce qu’on change d’outil ? Capability skill Est-ce que l’outil nécessite une connaissance approfondie pour être utilisé (un CLI), ou est-ce que l’outil cache la complexité totalement (un sidecar) ? Interface skill Est-ce que l’outil est simple/intuitif à utiliser ou non ? Pour cette catégorie, les speakers ont eu une réflexion intéressante : les templates (de code) ne sont PAS des interfaces simples à utiliser. Dès qu’on veut changer quelque chose qui n’est pas le comportement par défaut, il faut modifier du code (pire, du code “de quelqu’un d’autre”). Le “takeaway” principal de ce talk est qu’il n’y a pas de réponse universelle et que lorsqu’on crée ou met en place un nouvel outil, il faut se poser ces questions, en fonction du contexte. Beyond Platform Thinking at Ritchie Brothers - Build Things No One Expects, in a Place No One Expect Ce talk de Bryan Oliver était un REX de l’implémentation de la philosophie Platform Engineering au sein d’une société globale d’enchères d’engins de chantiers. Parmi les quelques retours intéressant que j’ai bien aimés, Bryan a notamment rappelé qu’il fallait : voir la plateforme comme un produit qu’il s’agit avant tout d’un projet logiciel, pas un projet d’infrastrute que le but premier est avant tout de supprimer toute friction pour le développeur Après quelques chiffres rapides pour la mise en contexte, Bryan a ensuite donné quelques exemples de ce qui pouvait être fait pour atteindre cet objectif. Ça a donné quelques exemples assez “drôles”, comme le fait qu’un admission controller ait été créé pour attendre la validation d’un JIRA pour mise en prod finale, ou alors l’usage intensif d’opérateur (concepts assez lourds, mais qui peuvent être indispensables pour aller au bout de la démarche d’autonomisation des devs quand aucune alternative sur étagère n’existe). L’important est de séparer le travail pour rendre ce qui est livré “compliant” (qu’on peut “shift-left”) du fait de vérifier que le travail compliant a été fait (qu’on garde côté “ops”). Sponsored Keynote: Crossplane - The Best Kept Secret in Platform Engineering - Bassam Tabbara, Upbound N’ayant toujours pas trouvé la page listant les talks par colocated event, je suis resté, un peu par erreur, pour ce “sponsored talk” d’Upbound. Le CEO d’Upbound a raconté l’histoire de “l’API mandate” chez Amazon dans les années 2000 (la génèse d’AWS), décrété à marche forcée et par la menace par Jeff Bezos. Ça commençait bien… Aussi brutal que soit ce changement, il faut quand même reconnaitre que c’est grâce à ça qu’a été construit, en un temps recort, des APIs pour tous les “services” offert par les équipes techniques d’Amazon (compute, storage, caching, etc), puis les API “control plane” (IAM, metering, …) et enfin, le cloud computing tel qu’on le connait aujourd’hui. Cependant, le talk a tourné au très mauvais goût quand le CEO d’Upbound a “réécrit” l’API mandate à sa sauce, en nous disant qu’il fallait qu’on migre tous nos services dans Kubernetes et Crossplane (LOL), et que sinon il fallait nous virer (pour reprendre la brutalité de Bezos). Je n’ai qu’un regret, ne pas être parti avant la fin. Building a Platform Engineering API Layer with kcp Je suis arrivé alors que le talk avait déjà commencé, mais je pense avoir saisi la majorité du talk. Globalement, il s’agissait d’une présentation sur kcp, un outil open source permettant de segmenter un cluster Kubernetes en un ensemble de sous-clusters en forme d’arbre (via des workspaces). On peut restreindre l’accès aux objets via héritage entre les branches de l’arbre et faciliter la création de plateformes par l’ajout d’API custom via des APIExports et des APIBindings. Ce n’est pas totalement clair pour moi puisqu’il me manque un bout du talk mais j’imagine qu’un petit test sera le plus simple pour bien comprendre l’intérêt de l’outil dans la pratique. Hands on lab sysdig / docker scout Après une pause bien méritée sur le rooftop avec mes collègues…
… Il était grand temps de se diriger vers le Courtyard by Marriot pour un “hands on lab” avec Sysdig, plein à craquer : Avant de commencer le lab, un intervenant dont je n’ai pas enregistré le nom nous a fait un talk assez bien construit sur tout ce qu’il faut sécuriser quand on est sur le cloud There is no “perimeter” in the cloud You have to combine open source tools to get proper security in the cloud Le problème le plus problématique étant que dans la majorité des cas, les incidents de sécurité dans le cloud sont dus à des erreurs humaines (permissions trop grandes, secrets leakés, …), il faut une combinaison de plusieurs outils pour s’en sortir. Après un tour d’horizon de plusieurs solutions couvrant une partie du scope (snyk, notary, wolfi, …), l’intervenant a ensuite introduit Falco (développé par sysdig), l’un de ces outils. Je connaissais l’outil donc je n’ai pas appris grand-chose (falco ne fait que détecter des comportements suspects, falcosidekick se charge des notifications, on doit ensuite agir via des outils tiers), mais la présentation était très bien faite et l’intervenant agréable à écouter. J’ai passé un très bon moment. Le lab, en revanche était trop orienté super débutants et a eu un ou deux petits glitchs (429 sur les pulls, navigateurs figés…). Dommage Quelques citations : It takes 207 days for a company to realize there was a breach, 70 days to contain it In reality, you have 10 minutes to fix the problem
“I enjoy writing rego. Said no one ever”
Paas Forward Pour terminer la journée, j’ai ensuite filé vers l’événement conjoint OVHCloud + Rancher (et Enix, AMD, Netapp, NVidia), Paas Forward. Après un peu de networking, nous avons eu droit à des conférences pour présenter les nouveaux produits sortis conjointement par OVHCloud et Rancher (pour faire court, un Rancher managé). Le tout animé par Alex Williams, le fondateur de The New Stack. On a fini la soirée par du networking à nouveau et un concert de Kungs. C’était sympa :) (mais trop fort x-o). Chit-chat Comme d’habitude, les conférences sont aussi un endroit parfait pour se retrouver, se rencontrer et discuter. Entre hier soir et aujourd’hui, j’étais super content de pouvoir revoir ou rencontrer en vrai pour la première fois (après des échanges sur le net) Katia, Stéphane, Aurèl, Jérôme, Réda, Smaine, Kévin, Olivier, Christian, Quentin, JC, Rachid, Jérôme (bis), Alan, Thomas, Olivier (bis), Thierry, Aurélie, Stéphane, la team frenchies sur Telegram, Alex, Sébastien, Fanny, Laurent, Boris, Rémi, Thomas (Bis) et tous les gens que j’oublie ou qu’on m’a présentés, car il est tard (bien trop pour écrire un article). À demain pour le “vrai premier” jour !

Fin 2022, je faisais un bref article sur mes lectures des 12 mois précédents, et ça se résumait surtout à des livres techs. Pour 2023-2024, je me suis dit que j’allais refaire l’exercice, car j’ai plus lu qu’en 2022, et surtout de manière plus variée. Accelerate A la toute fin de l’article de 2022, je disais que j’allais lire deux autres livres “techs”. People powered, et Accelerate. J’ai discuté avec des collègues, qui m’ont convaincu de NE PAS lire Accelerate. En effet, sans l’avoir lu, je baigne depuis suffisamment longtemps dans des organisations qui en sont grandement inspirées pour en connaître les grandes lignes, ce que m’a confirmé d’ailleurs la lecture d’un résumé. Je me suis récemment convaincu à nouveau que j’étais dans le vrai en lisant ce thread de Mathieu Corbin, qui vient de le lire. People powered Autre livre que j’avais dans ma liste de l’an dernier. J’ai mis beaucoup de temps à me lire et je ne l’ai d’ailleurs pas terminé. On m’a conseillé ce livre de Jono Bacon (qui a été notamment responsable de faire monter la communauté d’Ubuntu dans le monde) car j’avais demandé des références pour animer et faire vivre une communauté de pratique (cf mon article sur les communautés de pratique). Or, ce livre est un peu hors sujet. Si le début explique bien ce qu’est une communauté, comment on la construit et comment on la fait vivre, et donne des exemples très intéressants, il ne s’agit pas d’un livre destiné à un leader de communauté “bénévole” (ou disons “dont ce n’est pas le métier” dans mon cas). Il s’agit d’un livre à destination d’équipes marketing, dont le but est commercial. Pas de jugement de valeur (il y a de très chouettes communautés pilotées par des entreprises avec un but commercial), mais ce n’était pas ce que je cherchais. Osez la semaine de 4 jours Le livre de Laurent De La Clergerie, énigmatique patron de LDLC, qui prône une vision de la qualité de vie au travail que les patrons du CAC40 pourraient qualifier d’extrémiste. Non seulement il prône la semaine de 4 jours, avec réduction horaire (35 => 32h) et sans réduction de salaire, mais en plus il a mis en place des congés “second parent” très généreux par rapport à ce qui se fait en France et encore bien d’autres choses pour améliorer l’égalité femmes-hommes au sein de son entreprise. Un social traitre parmi la caste des patrons, en somme. Au fil du livre, Laurent explique le cheminement qui l’a fait arriver à cette décision, puis comment elle a été mise en place. Il parle des craintes de l’équipe dirigeante, mais aussi de certain⋅es salarié⋅es. Il parle également des défis qui ont dûs être relevés et du bilan (extrêmement positif) qu’il en retire en tant que chef d’entreprise. Selon lui, non seulement la semaine de 4 jours ne lui a pas couté de l’argent, elle lui en fait gagner, car selon lui la productivité est globalement meilleure sur 4 jours que sur 5. Si jamais ce livre vous intéresse, vous avez de la chance. Vous pouvez soit : le lire gratuitement en PDF car Laurent de la Clergerie l’a mis à disposition gratuitement depuis peu aller voir le replay d’une conférence à Cloud Alpes où il explique en résumé le contenu du livre Nos mutineries Nos mutineries, BD féministe écrite par Eve Cambreleng et Blanche Sabbah se veut être un recueil de “réponses imparables aux idées reçues sur le féminisme”. Par exemple : « J’ai rien contre les féministes, mais faut pas être extrême. » « Quand même, il faut séparer l’homme de l’artiste ! » « De toute façon, on peut plus rien dire. » Globalement la BD est top, très drôle. Même en me renseignant et en m’intéressant à ces sujets, j’ai forcément appris des choses. D’ailleurs, ce livre se veut un peu comme une introduction à tous les pans du féminisme, et donne beaucoup de références pour aller creuser plus loin certains sujets particuliers. Dans certains chapitres, je suis resté un peu sur ma faim par rapport à la promesse d’avoir des “arguments imparables” (comme sur l’explication du fait qu’il ne faut pas prendre personnellement le “Not All Men”). Mais comme première introduction à pourquoi le féminisme est important de nos jours, c’est clairement top. A mettre en toutes les mains, même le tonton macho réac. J’y vais mais j’ai peur Pour donner un peu de contexte, ma famille est originaire des Sables d’Olonne, et pour moi le Vendée Globe, c’est une religion. Je suivais avec mes parents les tous premiers sur une mapemonde dans ma chambre, où nous déplacions à la main toutes les semaines des petits drapeaux à l’aide des coordonnées des navigateurs. J’ai aussi suivi en bateau plusieurs départs et de nombreuses arrivées. J’y vais, mais j’ai peur est une BD relatant le Vendée Globe 2020 de Clarisse Crémer, une ex-cadre en quête de sens qui a tout plaqué pour faire de la voile et qui raconte comment, de navigatrice amateur, elle s’est faites embarquée dans un Vendée Globe (3 mois en solitaire au départ des Sables d’Olonne). Les dessins sont beaux, c’est un récit émouvant d’une navigatrice qui fait le tour du monde. On y apprend beaucoup de choses sur les coulisses d’une préparation à un événement sportif de cette ampleur, avec l’équipe technique, et sur la façon dont se déroule cette traversée, dans la tête de la navigatrice. Inspirant. Climax J’ai aussi lu plusieurs romans. Le premier c’était Climax, un roman de Thomas B. Reverdy. Sans spoiler quoique ce soit, le roman relate l’histoire de plusieurs personnes vivant dans une communauté proche du cercle polaire en Norvège. Le récit mêle habilement présent, passé, considérations écologiques, tensions économiques et de manière plus étonnante : jeu de rôle. C’est vraiment ce mélange qui m’a scotché, et j’ai dévoré le livre alors qu’il ne m’attirait pas du tout, au début. Le procès En allant chez un ami il y a des années, j’ai par hasard ouvert une page du procès de Kafka. Je n’avais jamais lu de Kafka et au-delà de l’expression “kafkaïen”, je n’avais qu’une vague idée d’à quoi m’attendre. Ce que j’y ai lu était tellement absurde que ça m’a donné envie de le lire. Envie qui a été d’ailleurs renforcée par une visite au Musée Kafka à Prague, où j’ai découvert à quel point Kafka était torturé. Mais je n’avais jamais pris le temps de le faire et maintenant c’est chose faite. Le procès a été publié à partir d’un manuscrit inachevé et ça se sent, même si l’absurde et l’incompréhensible auraient quand même fait partie de l’oeuvre, si elle avait été achevée. Passé la fascination des premières pages, j’ai quand même eu du mal à le finir. Mais je comprends que ce soit considéré comme un chef d’oeuvre de la littérature. Humus Roman que je viens de terminer. Humus, de Gaspard Koenig a reçu plusieurs petits “prix”. Là encore, sans trop spoiler (on comprend très vite) il s’agit d’une bromance entre deux étudiants en agro qui réalisent la futilité de leurs propres combats pour l’écologie, chacun à sa manière. Le roman est très plaisant, bien construit, visiblement bien documenté. Sorti en aout 2023, il mêle habilement des choses qui se passeny, se sont passés, où allaient tout juste se passer dans le monde réel, ce qui ancre le récit dans une réalité alternative crédible. Seule déception, l’avant-dernier et l’avant-avant dernier chapitres, qui m’ont parus “hors sol” et qui gâchent le plaisir en détruisant toute la crédibilité du livre dans le dénouement (à mon goût). Ca reste un bon roman.

DevWorld Conference J’ai eu la chance d’être invité par un ami (merci !) à la DevWorld Conference. Il s’agit d’une conférence de développeurs qui a lieu annuellement à Amsterdam. Les sujets qui y sont abordés sont généralistes, allant des sujets Frontend, Backend, Devops, “Engineering management” sans oublier l’incontournable IA. Sur le chemin du retour, comme à mon habitude, j’ai pris le temps de mettre au propre mes notes pour que vous puissiez vous faire une idée de l’événement. Déroulement La conférence a lieu au RAI Amsterdam, le centre de conférence proche du centre. Pour vous donner une idée de comment c’est organisé : il y a un grand hall, divisé en une scène principale (mainstage) et quatre scènes plus petites dans un grand espace au milieu des sponsors. Évidemment, pour pouvoir entendre les conférences dans les plus petits espaces (les “Duck Stage”), des casques audios connectés en radio au micro du speaker sont mis à disposition. Dans le principe, “ça marche”. Dans la pratique, quand il n’y a plus de place, il n’y a plus de place… Vous ne pourrez que lire les slides et n’entendrez pas le speaker. J’ai “loupé” plusieurs talks à cause de ça. Une fois n’est pas coutume : je ne vais pas lister tous les talks que j’ai vu. En effet, j’en ai vu BEAUCOUP, car quasiment tous les talks avaient une durée de 25 minutes, avec 5 minutes de battement entre chaque talk. How good of a developer are you? La première session que je suis allé voir. Dans ce talk Roy Wasse nous a parlé des différentes méthodes que nous mettons en place dans les processus de recrutement pour “juger” de la compétence d’un développeur. La plupart de ces méthodes sont peu efficaces, et ce n’est pas Roy qui le dit, c’est la science. En effet, pour la plupart des méthodes couramment utilisées pour “tester” et classer les candidats par niveau de technicité (et ainsi choisir le/la meilleur⋅e), des papiers de recherches scientifiques montrent que c’est peu corrélé à un niveau de compétence réel. Que ce soit le fameux l33tcode / renverser un binary tree, l’interro sur tableau blanc (qui met beaucoup de pression et qui n’est pas représentatif du travail sur IDE), des critères comme le CV, les références, les certifications ou même le niveau d’étude (qui a un impact positif lors des premières années uniquement), tout y est passé. Si intuitivement ces conclusions ne vous surprendront peut-être pas (on connaît tous des gens talentueux qui ne sont pas ingés, n’ont que peu d’expérience et ne savent pas inverser un arbre binaire au tableau), ce talk donne pas mal à réfléchir sur notre industrie et les parcours de recrutement en 7 étapes ou plus (coucou les GAFAM), qui sont très certainement conscients que ces recherches existent, mais les ignorent quand même. A la toute fin, Roy donne une autre manière de tester les développeurs sur différents types de taches, via un framework a priori plus pertinent et “scientifique” pour “tester”. Ça parait un peu trop beau pour être vrai, et c’est aussi assez cher… greps.com - Accurately Measure Your Coding Skills with GrepS Climbing the product management career ladder Ce talk de Nicole Van Alphen m’a beaucoup plu. Ayant commencé comme réceptionniste, Nicole (aujourd’hui Director of Product chez Vinted Go) détaille son parcours dans le product management, ce qui lui a permis d’y réussir et les différents attendus dans les différents postes. Ce talk m’a permis d’avoir une meilleure vision du monde du produit, dont j’avais une vague idée, mais sans plus. Évidemment, un must est de comprendre le “langage” des gens avec qui lesquels on travaille, autant du côté business (ex. connaitre le langage du retail si on travaille dedans) que du côté de la technique (comprendre le minimum pour être capable de saisir les difficultés rencontrées par les équipes techniques). En y réfléchissant bien, les fois où j’ai travaillé avec des Product Managers talentueux/talentueuses ont toujours été les fois où je sentais que, sans comprendre la totalité de mon métier, iels étaient capables d’appréhender les concepts principaux de mon quotidien. Nicole a terminé sur un message d’encouragement envers nous même, qui sommes parfois trop exigeants : Be kind to yourself. Even those that you consider as “technical gods” sometime doubt themselves and wonder what they are doing there" “If you are where you are, you are probably at your place, and probably being good at it” De Nederlandse Kubernetes Podcast Un petit peu par hasard, en m’assaillant sur fatboy pour me reposer, je me suis retrouvé à être spectateur de l’enregistrement du podcast “De Nederlandse Kubernetes Podcast”, qui comme son nom l’indique est un podcast néerlandais sur Kubernetes. Ça m’a intéressé à deux titres. D’abord le sujet était intéressant, c’était un speaker du vendredi qui venait parler de son talk, que je suis allé voir par la suite. Mais surtout parce que l’enregistrement se faisait en plein milieu de l’espace de conférence, dans le brouhaha. Mais au sein de cette “bulle”, le son était de bonne qualité et était retransmis en temps réel à l’extérieur, ce qui permettait d’avoir à la fois un son de qualité pour le podcast, tout en donnant la possibilité d’avoir un public. En tant qu’organisateur de KCD France, j’ai eu cette problématique : j’étais responsable de l’enregistrement de quatre tables rondes où le son était difficile à maîtriser et où nous n’avons pas pu avoir de public. À garder en tête ! From Engineer to Engineering Manager Je connaissais Emma Bostian de nom (elle a 200k followers sur Twitter). J’ai donc été voir son talk, dans lequel elle explique comment elle est passée (un peu malgré elle) d’ingénieure logicielle à manager. Elle explique notamment les différences de compétences attendues entre les deux, donne des conseils et met en garde : tout le monde n’est pas fait pour devenir manager. Sans tout lister, je retiens surtout que la composante principale d’un bon manager est le capital confiance qu’iel doit construire et conserver avec ses “direct reports”. Cela passe par le fait de faire ce qu’on dit, savoir avoir les conversations difficiles (don’t be a people pleaser), reconnaître l’excellence, aider à la création de relations entre ICs (individual contributors). Ce talk fait forcément écho à des situations que j’ai vécu ou qu’on m’a rapporté. How to be an adult in (professional) relationships Ce talk de Rachel Nabors est LE TALK qui m’a le plus marqué de toute la conférence. J’espère qu’il y aura un replay (si ce n’est à DevWorld, dans une autre conférence) car j’ai peur de ne pas y rendre justice dans ce blogpost. Grosso modo, ça se résume en “We s**k at human relationships”. Au travers du talk, avec la juste dose d’humour et d’expériences personnelles, Rachel nous donne une liste d’outils pour améliorer ça. Comment éviter de projeter ses propres pensées dans les actions des autres pour deviner leurs intentions réelles, se concentrer sur notre propre part (own your half of any situation), apprendre à dire “désolé” (et ne pas rajouter un “mais” derrière) et chercher sincèrement comment réparer une erreur. Elle a également beaucoup insisté sur les “power dynamics” au sein d’un groupe, avec une analogie que j’ai trouvée très parlante big dog/small dog. Le gros chien, c’est la personne qui a plus de pouvoir, de légitimité, de charisme, dans l’entreprise. Il peut arracher la tête du petit chien d’un coup de griffe (influer sur la carrière du petit chien). Il doit être conscient de sa “taille”, et en profiter pour instiller le calme, le sentiment de protection. Two people in the room, the third is power dynamics En fin de talk, elle a parlé des problématiques liées à notre “work / life balance” (qui selon elle est un mensonge dans nos vies hyper connectées), de savoir gérer et reconnaître quand on ne maîtrise plus nos émotions et enfin, de l’importance de ne pas rajouter de la détresse aux personnes qui sont déjà en train de perdre le contrôle des leurs. Vous le voyez, j’ai un mal fou à résumer tout ça. Je vais le revoir dès qu’il sort en replay. The Cathedral, the Bazaar, and the Coffeehouse Ce talk de Claude Warren à propos des stratégies pour limiter les risques (réels) liés à l’usage des logiciels open source était assez intéressant. Entre les problématiques de maintenabilité des logiciels, exacerbés par les problématiques de dépendances, les problèmes de licences incompatibles et les communautés trop restrictives (coucou Hashicorp) ou au contraire trop laxistes sur les contributions, gérer ces risques ne doit pas être laissés à la chance dans une organisation. Claude a introduit le concept d’OSPO (Open Source Program Office) pour gérer ces problématiques. Les OSPO sont des équipes au sein d’organisations qui sont responsables de jauger les projets utilisés dans l’entreprise, contribuer à ces projets et ainsi garantir leur pérennité, assurer un premier niveau de support pour les utilisateurs des logiciels open sources que l’entreprise utilise. Il a également introduit le principe de “Coffee house” (grosso modo, regrouper des OSPO de plusieurs entreprises différentes avec des besoins similaires) pour mutualiser les efforts. C’est un des seuls talks où j’ai réussi à trouver les slides 🙃. Lost in Cyberspace: Tracking Down the Missing TCP Packet Adrian Precub, staff engineer chez Tomtom nous a fait un postmortem d’un bug qu’ils ont eu entre des dizaines de milliers de voitures connectées et leur service de navigation. TL;DR: nginx ingress controller, c’est vraiment pourri jusqu’à la moelle (ok, j’exagère, mais je vous jure, je n’en peux plus de ce logiciel qui n’a rien à faire dans Kubernetes, cf mon article Je déconseille nginx en tant qu’IngressController en production). Sans trop rentrer dans les détails techniques, leur loadbalancer F5 savait gérer le ssl_handshake_timeout (fixé par défaut à 5 secondes), mais pas le nginx ingress controller derrière, ce qui faisait que certaines connexions entre les voitures et leurs services n’étaient fermées qu’au bout d’une heure d’inactivité (c’est plus compliqué que ça, il y a aussi une notion de packet resets qui n’arrivent pas dans le bon ordre, je vous invite à voir le replay). La conclusion m’a un peu surpris. Adrian avoue que le bug leur a pris 5 mois à résoudre, et a mobilisé (pas à plein temps, bien sûr) 50 personnes différentes de quatre entreprises. De quoi remettre en perspectives les fois où je m’en veux quand j’ai perdu tout seul 2 jours sur une mauvaise configuration de cilium… Beaucoup de networking Comme les sessions étaient parfois complètes ou démarraient en décalées (retards + pas assez de battement), j’ai eu beaucoup plus de temps que d’habitude pour aller voir les sponsors, engager des discussions. J’ai eu une longue conversation avec LeafCloud, un cloud provider “green” qui utilise la chaleur des serveurs pour chauffer de l’eau et des bâtiments (même principe que Qarnot, mais à une plus petite échelle). Ils proposent un Kubernetes Managé (au-dessus d’OpenStack) auquel on peut ajouter des GPUs que je ne manquerai pas de tester. J’ai aussi discuté avec ScyllaDB, Cloudinary, et d’autres. Ce n’étaient pas les sponsors que j’ai l’habitude de voir dans les conférences en France et c’était donc “rafraîchissant”. J’ai passé du temps avec Pascal et j’ai eu la chance de pouvoir rencontrer Julien (👋) avec qui j’avais déjà échangé plusieurs fois sur Twitter. Nous avons eu des discussions passionnantes, c’était vraiment une parenthèse plus que bienvenu dans mon quotidien. Vous l’aurez peut-être remarqué dans ce blogpost, les sujets qui m’ont le plus marqué sont majoritairement des sujets “non techniques”. Ça s’explique notamment, je pense, parce que les sujets techniques sont difficiles à “bien” traiter dans seulement 25 minutes (on reste vite sur sa faim). De plus, plusieurs sujets qui m’intéressaient étaient pris d’assaut et je n’ai pas pu les voir (j’ai loupé une super présentation sur Tauri 2.0 notamment). Il faudra attendre les replays. Je suis cependant content de cette conférence dans sa globalité (même si tout n’était pas parfait…), particulièrement grâce à ces moments d’échanges entre les sessions et à des talks “non techniques” de très grande qualité. Peut-être à refaire ! Au revoir, Amsterdam…