Les "vendeurs" ou decideurs vont-ils faire echouer l'approche DevOps?

,
#1

Bonjour,

Je me permets d’e demander vos points de vue suite à la lecture de cet article [Le DevOps : d’une idée géniale à Kubernetes : chronique d’un effondrement] (Le DevOps : d’une idée géniale à Kubernetes : chronique d’un effondrement ? | Christophe Casalegno) tres réaliste de la situation actuelle dans de nombreuses ESN.

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 ?

1 « J'aime »
#2

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.

4 « J'aime »
#3

Merci pour ton retour .

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.

#4

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.

1 « J'aime »
#5

J’ai lu quelques articles sur le sujet. Mais c’est pas applicable pour de la petite PME ou pour une simple pizza team non ?