J’ai eu une expérience a peut pres similaire ou l’implémentation de l’approche DevOps et de ses piliers a réussi à briser les silos entre Ops, Dev et Client, mais celle-ci s’est heurtée à une vision qui ne voyait cela que comme un produit ou ensemble d’outils.
Générant des fustrations des uns et des autres (adopteurs précoces et les retardataires) avec pour résultats une implosion de l’équipe.
Comment peut on garder l’esprit DevOps et arriver à faire face aux “vendeurs” ?
Avez-vous déja eu des expériences similaires ?
Le souci ne sont pas les vendeurs mais les adopteurs. Notamment les grosses DSI qui pensent qu’appliquer un jargon et 2/3 outils est suffisant pour révolutionner leur organisation et résoudre l’ensemble de leurs problèmes.
Il y a aussi les effets liés aux dinosors historiques qui essaient de mettre un pied dans le train en marche, je pense notamment ITIL dont la v4 fait référence au DevOps tout en favorisant le silotage ce qui est un anti-type.
Ce que je n’aime pas dans l’article mentionné est qu’il fait l’amalgame entre des outils à la mode comme Kubernetes ou Ansible et DevOps.
L’approche DevOps nécessite effectivement un certain nombre d’outillages, notamment pour mettre en oeuvre des pratiques de CI/CD mais elle ne promulgue aucunement un outil particulier, ni même les plateformes cloud.
A l’opposé des outils à la mode, il y a le recours excessif aux outils fait maison. Dans la majorité des cas ces derniers sont développés en dehors des pratiques standards, mal documentés et peu voir pas maintenus.
Personnellement, j’apprécie :
La standardisation.
La mutualisation des efforts, si un outil existe et répond à mon besoin ou presque, je préfère y contribuer que de réinventer la roue.
Bref, tout ça pour dire que ce n’est pas la faute à l’approche si elle est mal implémentée mais plutôt aux exécutants.
Je partage ton avis sur la standardisation et la mutualisation des outils en fonction des forces et faiblesses de l’organisation.
Mais je trouve que de nombreux adopteurs et dinosaures créent plus de confusion dans l’esprit des personnes qui s’intéressent à l’approche DevOps et biaisent du coup les attentes, faisant fi de l’esprit et espérant avoir le même résultat.
Juste le nombre de podcasts ou d’articles qui font l’amalgame entre K8s ,DevOps et Cloud Native illustrent bien la situation actuelle.
Là ou la méthode préconise l’intelligence collective,un “Guru DevOps / Dinosaur” préconise un outil qu’il maitrise et essai de l’imposer, créant plus de dettes techniques et de problèmes qui n’existaient pas.
Oui aujourd’hui les choses sont très confuses et c’est pour cela que personnellement je promulgue l’approche Plateforme engineering qui est pour moi du DevOps à grande échelle et qui a le mérite d’être plus claire et précise dans son implémentation.
Arf je déterre ce post, mais je viens de lire l’article de Christophe Casalegno, et … que dire … Le gars est surtout la pour exprimer la frustration qu’il a l’air d’avoir emmagasiné depuis de nombreuses années.
Et franchement en me baladant sur son site, je vois des “articles” du même genre que celui-ci : Peu ou mal documentés, des opinions utilisées comme des faits etc etc…
Il m’a l’air bien aigri et tout aussi dogmatique que ceux dont il critique les dires.
Bref, je ne vais certainement pas mettre son site bookmark :D, rien d’intéressant la bas e ce qui me concerne.
Je ne remet pas e cause que le terme devops soit galvaudé, ni même que son implémentation est très compliqué dans les grosses structures, n’empêche que de la a dire que cela “cause plus de problème qu’avant”, que cela “règle des problèmes qui n’existait pas avant” il y a un monde a mon avis.
Il y a quelques contradictions aussi, bref… Le gars n’est ni intéressant ni très bon rédacteur d’ailleurs.