Pourquoi DevOps échoue : ce n’est pas vous, ce sont les outils

Nous connaissons tous l’adage – “Les mauvais travailleurs blâment leurs outils”. Mais voici cinq raisons pour lesquelles les outils logiciels impliqués dans DevOps en général, et le pipeline CI/CD en particulier, font désormais partie du problème plutôt que de la solution.

1. Ils prennent trop de temps à se déployer

Ceci, il faut le dire, est une ironie massive. Lorsque le développement logiciel s’est engagé sur la voie agile au cours du dernier millénaire, c’était pour rompre avec les modèles en cascade – non pas parce qu’ils étaient faux en soi, mais parce qu’ils étaient trop lents. Tout comme un cycle de développement de deux à trois ans est beaucoup trop long car le monde (technologique) aura changé, il en va de même pour le déploiement d’un outil dans une entreprise.

En plus des échelles de temps fondamentales, la durée d’attention à la prise de décision ne s’étend tout simplement pas aussi loin. Le résultat est que les outils sont souvent à moitié déployés avant l’arrivée de la prochaine vague d’outils, ce qui ajoute à la complexité plutôt que de la réduire.

2 . Ils sont toujours vendus comme des balles magiques

Dans à peu près tous les webinaires axés sur les solutions auxquels j’ai participé, la ligne « mais ce n’est pas une solution miracle » est utilisée (c’est juste, si personne d’autre ne le dit, je le ferai). Néanmoins, on nous dit toujours que les outils logiciels sont la solution : ils peuvent transformer la façon dont vous fournissez des logiciels, ils ont tout ce dont vous avez besoin, etc.

Ce serait vraiment bien si ces déclarations marketing étaient vraies, mais elles ne sont que partiellement correctes. Contrairement aux instruments financiers, cependant, les fournisseurs d’outils ne sont pas tenus d’inclure des clauses de non-responsabilité sur leurs pages d’accueil – “Le succès nécessite une diligence raisonnable du client et une gestion du changement”, par exemple.

3. De nouveaux apparaissent tout le temps

C’est aussi ironique que 1. Un chemin raisonnablement standard est celui où des ingénieurs intelligents travaillant pour une grande entreprise expriment leur frustration face à leurs propres pipelines et finissent par créer une solution intéressante. Tout aussi intelligents, ils se rendent compte qu’ils sont sur quelque chose, créent une startup, trouvent quelques clients et vont chercher des investissements, dépensant des sommes raisonnables en marketing et, en fait, en conseils d’analystes.

Dans l’espace DevOps, qui regorge inévitablement de développeurs, cette situation est plus courante que (disons) l’infrastructure réseau – les gens ne démarrent généralement pas des entreprises de télécommunications en tant que projets parallèles. Le problème est que cela tombe dans le piège de supposer que personne d’autre n’a jamais résolu le même problème, créant des côtés supplémentaires sur la même montagne à traverser.

4. Ils sont vendus sans contrôles

D’après mon expérience du déploiement d’outils de développement logiciel (ce qui n’est pas mal), ils ont tendance à se diviser en deux camps. Certains sont tactiques – un petit widget de test de performance, un tableau de bord ou une capacité d’intégration. Les autres, presque à tort, ont une sorte d’attente stratégique sur la façon dont les choses sont faites. Les responsables d’environnements de développement ont besoin d’équipes pour travailler avec la notion d’environnements. Les outils de test ont besoin d’une méthodologie de test.

Alors que de nombreux outils peuvent avoir un cadre, une façon de penser ou une approche associée, ils ne mènent pas souvent avec cela. Cependant, soyons clairs, tout nécessitera des changements au niveau de la direction dans la façon dont les choses sont faites, voire plus haut. Des exceptions existent – ​​certains vendeurs vendent au niveau du conseil – mais voir aussi 5.

5 . Ils sont vendus et achetés par des ingénieurs

Cela se chevauche avec 4, mais il s’agit davantage de la mise sur le marché, qui est souvent un modèle freemium ou open-source-plus. Essentiellement, les outils sont présentés comme tactiques, dans la connaissance directe que tôt ou tard, ils devront être perçus comme stratégiques.

Dans l’industrie, ce modèle de vente s’appelle « atterrir et s’étendre » – il suffit d’entrer dans n’importe quelle manière et de grandir à partir de là. Cependant, la réalité est plus « atterrir, s’étendre et ensuite commencer à rencontrer des problèmes » – les organisations se retrouvent avec des poches d’outils déployés de différentes manières et un environnement très fragmenté. Les fournisseurs peuvent également revendiquer les logos des clients, mais ont ensuite du mal à transformer les déploiements tactiques en clients plus stratégiques.

Tous ces problèmes peuvent être résumés comme suit : “Des outils stratégiques, vendus et achetés de manière tactique”. Je ne vais pas pointer du doigt exclusivement les vendeurs (bien que cela me rappelle une conversation que j’ai eue sur les tactiques de vente, dans un domaine différent. Moi : « Pourquoi tu fais comme ça, ce n’est pas sympa. » Eux : « Parce que ça marche. »).

Et puis de nouvelles fonctionnalités, telles que les indicateurs de fonctionnalités, sont présentées comme améliorant encore les choses, alors qu’en fait elles sont le contraire. Je pense que les feature flags sont excellents pour l’enregistrement, mais vendus/achetés sans contrôle, ils sont une voie vers encore plus de fragmentation et de désespoir.

Y a-t-il une réponse ? Étant donné que les fournisseurs d’outils logiciels n’adopteront guère l’approche «vendons moins et qualifions toute organisation qui n’est pas suffisamment organisée pour utiliser nos produits», la responsabilité doit s’arrêter aux organisations d’utilisateurs finaux, en particulier à leurs équipes d’ingénieurs et comment ils sont gérés. Alors que les vendeurs doivent rendre des comptes, il faut être deux pour danser le tango.

L’indice est avec le mot “outils” lui-même. Nous devons arrêter de penser à des outils comme nous pourrions voir des tournevis et des maillets, et commencer à les voir comme nous pourrions fabriquer des systèmes – nous construisons une usine de logiciels, pas un atelier hipster.

Les organisations doivent voir leurs chaînes d’approvisionnement logicielles internes de la même manière qu’une usine de fabrication (troisième alerte ironique – c’est exactement le point soulevé dans le projet Phoenix, écrit il y a 15 ans).

Cela signifie également empêcher directement les développeurs de prendre des décisions d’outillage incontestées. Je suis désolé, mais je n’adhère pas entièrement à la ligne “les développeurs sont les nouveaux faiseurs de rois”, car je parle à trop de gens des opérations et des infrastructures qui doivent pelleter les tas de fumier qu’ils créent s’ils ne sont pas contrôlés.

Nous avons tous besoin d’être protégés contre nous-mêmes – et la conséquence d’une culture du tout-va-au-nom-de-l’innovation est une série de fiefs fragmentés, pas de grands empires. La question du « prototype/PoC devient la plate-forme » est aussi vraie pour l’outillage que pour le logiciel sur mesure si le temps est limité, ce qui est inévitablement le cas.

Du point de vue des fournisseurs, cela signifie se concentrer sur une liste plus restreinte de fournisseurs, leur donner potentiellement plus d’argent et travailler avec eux pour comprendre les changements culturels nécessaires pour adopter pleinement leurs capacités.

Et les chefs d’entreprise, tant que vous laissez la situation se répandre, vous encouragez l’inefficacité et le gaspillage. Les bonnes choses ne sortent du chaos que par exception. Sur le plan positif, particulièrement pertinent en ces temps de récession, cette fragmentation crée des opportunités majeures pour réduire le gaspillage et accroître l’efficacité, libérant des fonds pour l’innovation.

Surtout, nous avons créé une jungle en ne faisant pas attention en amont. Il n’est jamais trop tard pour commencer à s’attaquer à ce problème, mais franchement, si toutes les entreprises sont des entreprises de logiciels, elles doivent commencer à agir en conséquence.