Le DevOps : d’une idée géniale à Kubernetes : chronique d’un effondrement ?
Préambule
C’est depuis mon fauteuil à l’hôpital Bon Secours de Galway, drapé d’une couverture, alors que l’Infliximab se diffuse lentement dans mes veines que je décide d’écrire ce post. Dans 3 jours, j’aurai 48 ans, un moment comme un autre pour se pencher sur le fail d’un concept qui aurait pu tout changer dans l’univers de la Tech : le DevOps.
Disclaimer : ce texte reflète mon avis ainsi que cet univers à travers le prisme de mon expérience personnelle.
En préambule, et si on s’en réfère à la définition écrite sur Wikipedia aujourd’hui : « Apparu autour de 2007 en Belgique avec Patrick Debois, le mouvement Devops se caractérise principalement par la promotion de l’automatisation et du suivi (monitoring) de toutes les étapes de la création d’un logiciel, depuis le développement, l’intégration, les tests, la livraison jusqu’au déploiement, l’exploitation et la maintenance des infrastructures. »
Selon cette définition, cet article n’aurait pas réellement de sens, alors laissez-moi vous raconter ce qu’est pour moi ainsi que ma rencontre avec le DevOps.
Introduction
Au début des années 2000, la plupart des grosses structures avec lesquelles je travaille, ont leurs services informatiques découpés de la sorte :
1) Les « devs » : ils conçoivent les applications ou parfois même des briques d’applications ou de bibliothèque, selon un cahier des charges et un dossier de specs précis, certains sans même savoir ce que fait l’application finale qui découle de leur travail.
Je passe sur les différentes « classes » de « devs » programmeur, l’analyste programmeur, etc.
2) Les « Ops » : ils sont en charge de l’opérationnel, avec notamment le déploiement et la mise en service des applications, ainsi que de la maintenance applicative.
3) Les « sysadmins » en charge de la conception et de l’exploitation des infrastructures. Là encore, je passe sur les différentes « classes » de techniciens, ingénieurs, architectes système, réseau, etc. Leur périmètre s’étend du hardware aux services en passant par le réseau, les systèmes d’exploitation, etc.
Première remarque : les « ops » ne sont pas des sysadmins. C’est un métier à part.
Dans ces sociétés, pour lesquelles j’interviens, ces 3 services sont complètement cloisonnés, à tel point que les équipes ne sont souvent même pas situées dans la même zone géographique.
La tension entre ces différents services est palpable, chacun se plaignant du travail des autres.
Certains vont commencer à se pencher sur le problème, et arriver à la conclusion qu’une partie non négligeable de ces problèmes, pourraient être due au manque de connaissance du métier, des contraintes et des objectifs des autres « groupes », les uns vis-à-vis des autres.
Ils vont alors chercher à créer un rapprochement entre ces différentes unités, et observer les résultats : tout d’abord via des sessions d’échanges où le membre d’un service ira travailler en étant immergé durant quelques jours au sein d’une autre unité et vice-versa.
Ces opérations, vont porter leurs fruits et entrainer de nouvelles expériences, : des membres de chaque service sont nommés comme des interlocuteurs « permanents », en charge d’assurer un lien fort entre les différents services, en permettant une meilleure circulation des informations ainsi qu’une collaboration plus efficace. Dans le même temps, les échanges avec immersion se généralisent.
Enfin, dernière grande étape : des rapprochements géographiques sont initiés afin que ces différents services travaillent au même endroit.
Ce moment maintenant loin derrière moi est celui que je qualifierai d’apogée du DevOps : il ne s’agit pas ici de technologie, mais davantage d’une approche organisationnelle, opérationnelle et philosophique, permettant la création et le développement d’une véritable synergie, entre les différents services techniques de l’entreprise.
La tension baisse, l’efficacité et la productivité augmentent, chacun comprenant mieux l’autre, ces échanges assurant par ailleurs une meilleure compréhension de l’objectif commun. Je pense avoir fait partie, à ce moment-là, des plus grands admirateurs de ces initiatives et de ce mouvement « DevOps » naissant.
Les vendeurs (voleurs ?) de mots
Alors que le DevOps portait ses fruits, ceux que j’appelle « les vendeurs (voleurs) de mots » n’allaient pas tarder à essayer de s’emparer du concept pour le dépouiller de tout ce qui fait son âme, et tenter nous le vendre à la manière des vendeurs de surimi : en essayant de nous fourguer cette pâte industrielle infâme en lieu et place de la chair de crabe…
L’hype doit prendre, et avancer vite : et tout est bon pour y arriver. « DevOps » commence à devenir un mot fourre-tout pour décrire un ensemble de solutions logicielles, et, progressivement, étape par étape, tous ceux qui n’utilisent pas ces logiciels sont méprisés puis « exclus » du mouvement.
L’ambiance devient glauque et le monde de la Tech précédemment réunifié va commencer à se fragmenter de nouveau. Dans un premier temps, une cassure va apparaître entre ceux qui utilisent certains outils connus d’automatisation ou d’industrialisation, et les autres, tel qu’Ansible, qui sont « ringardisé » par les utilisateurs de technologies décrites comme « plus modernes », mais cela ne va pas s’arrêter là.
Je ne parlerai même pas de ceux qui ont choisi ou continué d’autres approches, comme faire reposer leur automatisation sur des outils maison écrits en shell ou en d’autres langages : cela reste à peu près le seul point de convergence des premiers qui commencent à se battre entre eux.
La chute
De multiples autres fissures vont se produire, jusqu’à se transformer en fracture ouverte entre plusieurs mondes : cela ne se limite plus seulement aux outils d’automatisation : les outils de gestion du code, les méthodes de développement et même les choix d’infrastructures sont touchés.
Dans le même temps, le terme « DevOps » a perdu de sa superbe ainsi qu’une grande partie de sa substance, et défini désormais un nouveau métier : une sorte de croisement, entre le sysadmin et le développeur (le plus souvent un développeur qui se met à essayer de faire de l’infrastructure avec des résultats plus que mitigés dans certains cas…) censé tout comprendre, tout faire, et résoudre tous les problèmes.
Mieux encore, le DevOps serait un magicien grâce auquel aucun problème n’arrive. « Serait » est ici le mot à retenir, car lorsque je questionne les directions des structures avec qui je suis en contact, les retours vont plutôt de « passable » à « c’est un désastre, mais on ignore comment faire marche arrière : nous avons sur-communiqué en interne et voté des budgets pharaoniques qu’il est maintenant temps de justifier… ». « Pire encore nos effectifs et/ou nos coûts ont triplé se plaignent d’autres ».
Le mouvement DevOps va continuer de se radicaliser chaque jour un peu plus : pour mériter son « titre », le DevOps doit désormais être « cloud native« , utiliser des logiciels et des méthodes déterminées par « le groupe », et ne jurer que par Kubernetes (c’est en train de changer avec une nouvelle dissidence autour de Nomad) pour son infrastructure, sous peine d’être frappé de l’infamie.
Cerise sur le gâteau, pour devenir le DevOps ultime : il doit cracher (vomir) sur tous ceux qui ne pensent ou ne font pas comme lui (et au passage sur les technologies, méthodes ou langages qu’ils utilisent).
Les « bonnes pratiques » semblent maintenant être celles de l’auto-congratulation d’avoir conçu une usine à gaz plus lourde et complexe que celle du voisin et qui résout des problèmes qui n’existaient pas, tout en demandant des équipes complètes pour fonctionner là où une ou deux personnes suffisaient largement avant (tout en prétendant qu’il n’y a aucune autre bonne manière de faire et que ce serait le prix à payer pour la « qualité »… laquelle ?). On n’est plus très loin du syndrome du pompier pyromane…
L’explosion ?
Comme dans tout mouvement radical, il suffit d’attendre… car il y aura toujours des plus radicaux pour s’attaquer à ceux qui ne le sont pas assez : un extrémiste est, par définition de toute manière, un insatisfait permanent. Certains « crêpages » de chignons et autres « flame wars » se déclarent par-ci par là, que ce soit en interne ou sur les réseaux sociaux et autres messageries de groupes.
Ce mouvement (qui n’est en réalité plus le même depuis longtemps), qui semblait au premier abord uni contre tous, commence à son tour à se fissurer. Dans le même temps, des personnes qui étaient plutôt neutres et n’appartenant à aucun groupe, se radicalisent à leur tour contre cette « bonne pensée » qu’on tente de leur imposer contre leur gré, et finissent par devenir allergique à ces technologies et principes, indépendamment de toute analyse logique.
La suite logique sera-t-elle l’explosion ? Nul ne peut le prédire ou le savoir avec certitude, mais ce dont je suis sûr, c’est qu’il n’est jamais bon pour la Tech, de se retrouver limitée, voire enfermée dans des « bonnes pratiques« . Certains voudraient vous faire croire que si des milliers de personnes ont travaillé sur un sujet avant vous, alors elles ont forcément raison.
Il suffit pourtant de jeter un coup d’œil en arrière sur l’histoire de l’informatique pour constater que c’est factuellement faux.
Ne vous limitez pas à ces croyances qui n’ont rien de scientifique. Contrairement à ce que certains essaient de vous imposer : testez un maximum de solutions par vous-même, itérez, innovez hors des sentiers battus, et retenez ceci : chaque fois que la solution que l’on vous présente à un problème est complexe, c’est qu’il existe très probablement une solution beaucoup plus simple pour le résoudre.
 |
Utilisez, testez un maximum d’approches, via les systèmes, logiciels et langages qui vous plaisent, et faites votre propre expérience. Mais, ne tombez pas dans le piège de faire des choses seulement pour vous faire plaisir (réservez les pour le fun).
À la fin de l’histoire, il n’y a qu’une seule chose qui déterminera si vous aviez raison ou tort : le niveau de satisfaction de vos clients. Les critères qui déterminent la pertinence de vos choix, sont le résultat qu’ils attendent, rien d’autre (même chose si votre client est vous-même).
Sur ce, portez-vous bien, passez de bonnes fêtes de fin d’année, et joyeux Noël !
—
Christophe Casalegno
Vous pouvez me suivre sur : Telegram | YouTube | Twitter | Facebook | LinkedIn | Twitch
Étant chargé de proposer la mise en place DevOps chez des clients, je ne peux pas être totalement d’accord…
mais je ne suis pas, malheureusement, totalement en désaccord.
L’erreur que j’aie vue trop souvent est la mise en place d’outils avant la réflexion sur la démarche.
Il faut encore et toujours rappeler que DevOps est une démarche, pas une méthode, pas des outils, pas des processus, etc.DevOps consiste tout simplement à (re)faire communiquer les développeurs avec les exploitants, afin qu’ils comprennent les besoins et complexités de l’autre et sachent en tenir compte et s’adapter.
De là peut découler des outils mais, dans certaines missions que j’aie réalisé, nous n’avons mis en place que des réunions de travail et tout le monde s’est en satisfait sans avoir à mettre en place du Jenkins, Artifactory, Ansible, etc.
L’autre biais extrêmement gênant que je rencontre est la tentation du NoOps.
C’est à dire que les développeurs ne voient les exploitants que comme une contrainte et veulent absolument tout automatiser pour ne plus dépendre d’eux.
C’est souvent là que Kube, AWS, etc. arrivent car les dev ont l’impression que tout se passe chez eux.
Puis, dès la première crise avec une armée de développeurs plantés comme des poules devant une boite à clous, ils réalisent qu’ils sont allés trop loin… mais refusent de revenir en arrière car il faudrait qu’ils admissent qu’ils ont eu tort.Bonsoir Olivier, j’ai lu ton commentaire avec attention, et je ne me sens pas en désaccord avec ce que tu dis, et même plutôt assez d’accord :) Mais, je dirais également que tu fais partie dans ce cas des (très) rares à avoir conservé le sens initial de la démarche DevOps dans son approche. J’en croise parfois, mais c’est rare. Pour beaucoup, DevOps = une suite d’outils et le profil qui les opère, ce qui n’a que peu de rapport avec ce que tu proposes, ou avec ce que j’ai connu au début. Excellente soirée.
Tu as totalement raison
Là par exemple ca fait 6 mois que je règle des problèmes que je n’avais pas auparavant parcequ’un gars m’a imposé d’utiliser DOCKER alors que tout marchait très bien auparavant sans docker
C’est tout le problème lorsque le besoin se met à découler des choix techniques plutôt que le contraire :/
True Story ! Merci
Tellement buzzword à un moment que les entreprises recrutaient du « DevOps » sans que les fiches de postes soient raccords.
Et souvent en grattant, sans savoir ce que cela voulait dire.
Il en fallait… quitte à y mettre le prix.Il est vrai qu’il y a tous ceux qui également ont conservé leurs anciennes annoncent et ont juste remplacé le mot par « devops », parce qu’apparemment il y avait plus de candidats mdr.
Oui il y a beaucoup de vrai dans ce que tu dis.
Perso je reste persuadé que cette Philo de 2007 est une des clés pour réunir les Devs et las Admins.
Si on pousse encore plus loin, on tape en Agile à l’échelle ou enfin on réunit autour d’une même table Devs, Admins et Client Final (c’est quand même lui qui paye) afin que tous les acteurs des Projets discutent pour faire évoluer le SI.
@+
7 Commentaires