November 29, 2023

Kubernetes, Cloud, Observability... Quand l'écart technique et de pratiques tue le débat

Pourquoi certaines technologies créent des débats sans fins et souvent stériles ? Je pense que c’est parce que l’écart s’est trop creusé entre les différents partis.

Et je vais commencer cet article par une anecdote.

Il y a de ça quelques années, je présentais sur Twitter un de mes projets open source, projet évoluant dans le monde du monitoring/observability.
Une personne "très connue" de la communauté tech Française est rapidement venue troller en disant que le projet était inutile, que des tonnes d’alternatives existaient déjà, et qu’il fallait à un moment arrêter de réinventer la roue.

Je n’étais bien sûr pas d’accord avec ces affirmations pour de nombreuses raisons mais lors du débat qui a suivi une chose m’a marqué: j’étais en totale déconnexion en terme de technique et pratiques avec mon interlocuteur.

Je décrivais mon projet en expliquant ce qu’il apportait en terme de bonnes pratiques de monitoring par rapport à d’autres produits, et donc parlais de blackbox vs whitebox monitoring, de labeling, de formats d’expositions, de service discovery, de l’intêret d’avoir des outils "API first", de hot reload…​ là où mon interlocuteur était bloqué à "on n’a jamais fait mieux que Nagios pour monitorer des infras".

Bref, Dunning-Kruger tambourinait très fort à la porte. La discussion s’est évidemment enlisée car au final toutes les pratiques "modernes" de monitoring n’était il paraît que de la hype inutile.

Un pattern courant

Cela ne vous rappelle rien ? Des sujets sur le cloud et Kubernetes sont également victimes de ce phénomène. Trop hypes, trop chers, inutiles, "de toute façon je fais mieux en roulant mon infra sous les aisselles"…​

Le point commun de tout ça ? Expliquer l’apport en terme de pratiques et de fiabilité technique en apportant des faits ne permet plus de convaincre, car la communauté tech est disloquée en plusieurs mondes difficilement réconciliables.

J’ai beaucoup essayé sur ce blog ou ailleurs (podcast, conférences…​) de parler d’abord pratiques: qu’est ce que ça veut dire avoir une prod de qualité ? Comment on rend des développeurs autonomes dans leurs tâches quotidiennes sur la production, sans avoir des ops dans leurs pattes ? Comment on arrive à déployer 10, 20, 50, 100…​ fois par jour en prod de manière fiable ? Comment lutter contre l’alert fatigue et avoir une gestion d’incidents efficace ? Qu’apporte une approche "self-service" dans un département tech ? Comment on arrive à ne (presque) plus faire de run ? Comment je fiabilise au maximum ma prod en terme de tolérance aux pannes et sécurité sans avoir à restreindre les fonctionnalités de la plateforme ? Je pourrai rajouter de nombreuses choses à cette liste.

Toute cette vision pourrait se résumer à "comment produire de la qualité en tant qu’ops pour tirer la boîte vers le haut". Il y a un travail organisationnel et d’alignement pour porter ce type de vision mais faire les (bons) choix techniques est également important notamment sur les projets non triviaux.
J’insiste sur le "non triviaux" pour ceux au fond de la salle qui me sortiront le fameux "oui mais moi j’ai juste un wordpress à déployer". Cool, dans ce cas là n’importe quelle solution fera l’affaire.

L’ops est un milieu conservateur

Les ops adorent généralement critiquer les développeurs et notamment les différentes "hypes" du moment des dev: nouveaux frameworks, outils, pratiques. Et c’est vrai qu’il y a parfois de l’abus dans certains écosystèmes.

Mais il faut également remercier les développeurs pour cela. Le monde de l’ops est un milieu extrêmement conservateur (même si cela s’améliore avec la nouvelle génération), où les nouvelles technologies et pratiques sont souvent vus avec méfiance voir haine. Et dans de nombreuses boîtes c’est clairement les dev (souvent des dev ayant également un pied dans l’infra, soyons honnête) qui ont réussi à pousser de nouvelles manières de bosser.
Quand en 2023 vos ops sont toujours à se demander si il faut faire du conteneur en production, voir débattent encore de l’intérêt de systemd, la meilleure chose à faire est en effet de les bypass dans le but de retrouver de la productivité.

Et c’est ce conservatisme que l’on retrouve dans les longs "débats" tech dans les réseaux sociaux.

Je me rappelle il y a longtemps un manager infra disant quelque chose comme "Des machines virtuelles à la demande? J’en ai jamais eu besoin dans le passé je vois pas pourquoi on investirait là dedans". Pourtant l’apport aurait été énorme pour les projets (qui eux étaient demandeurs), mais son manque d’expérience des pratiques modernes ne lui permettait même pas d’entrevoir ce que cela allait apporter.

Remplacez machines virtuelles par cloud, Kubernetes ou autre. Combien "d’anti cloud" ou "d’anti Kubernetes" ont réellement une expérience en production avec ? Je me suis par exemple rendu compte récemment que j’avais débattu pendant des années avec des gens sur le sujet de Kubernetes alors qu’ils ne l’avaient en fait jamais utilisé.

Certains vont probablement me dire "oui mais le contexte c’est important, certains contextes techniques sont difficiles etc". Et c’est vrai. Et j’ai travaillé dans le passé dans ce type de contexte. Mais jamais je ne serais aller faire la leçon à tout ceux qui m’ont permis de progresser en leur disant "Ah non, vu que moi je bosse dans une organisation broken personne n’a le droit de faire mieux", voir, comme on me l’a déjà dit "ce que tu décris est impossible, tu mens sur tes pratiques".
Le pragmatisme et le "ça dépend" est souvent une réponse valable dans notre domaine mais seulement si on a les connaissances pour comprendre les différentes possibilités.

Je reste quelqu’un d’optimiste. Je pense que globalement tout le monde est capable de progresser dans le bon contexte, et on a tous des expertises différentes. Je suis nul sur des sujets comme la virtualisation, le stockage, ou le choix de hardware. On ne me verra jamais aller tenter d’imposer mon point de vue sur ces sujets avec des personnes bossant dessus depuis des années, par contre j’écouterai avec attention ce qu’elles ont à dire si je me retrouvais à travailler sur ce type de technologie. Savoir où s’arrêtent ses connaissances est je pense très important en tant qu’ingénieur.

Mais je suis aujourd’hui assez fatigué de discuter avec des gens qui ne souhaitent ni écouter ni progresser mais qui par contre ont des convictions fortes sans l’expérience ni l’expertise pour les soutenir. Je pense pourtant qu’il est important de ne pas se décourager et de continuer à démonter le FUD sur les réseaux pour une seule raison: les sysadmin/SRE juniors.

Un junior peut vite se laisser influencer par certains discours "anti hype", où l’ops est vu comme quelqu’un de cool à contre courant, incarnation du pragmatisme qui peut tout faire à coup de scripts bash et insensible au "marketing" (le mot marketing incluant tout ce qui est sorti après 2005). Dommage de laisser quelqu’un commencer sa carrière avec cet état d’esprit.
Cette vision passéiste (et anti modernité) de l’ops doit disparaître, et c’est aussi notre rôle de faire en sorte que cela arrive.

Tags: devops

Add a comment








If you have a bug/issue with the commenting system, please send me an email (my email is in the "About" section).

Top of page