You build it, You run it
Ça claque, c'est bien balancé et c'est marqué au coin du bon sens. Cette phrase, par la suite devenue mantra du DevOps, résume à elle seule l'approche de Werner Vogels, CTO d'Amazon. La citation date de 2006 :
The traditional model is that you take your software to the wall that separates development and operations and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
Mais on le sait, le bon sens est la chose du monde la mieux partagée, de sorte que 2 ou 3 arguments seront toujours les bienvenus pour étayer le propos.
Werner Vogels suggère de responsabiliser les équipes de développement : on ne laisse pas une équipe support gérer les 💩 dont on est responsable, parce que c'est une incitation à en créer sans cesse de nouvelles. Perdre de vue l'utilisateur est la source de bien des maux en informatique : c'est la porte ouverte aux complications inutiles, à l'opposé du pragmatisme qui fait avancer le business. Il faut donc "internaliser les externalités", comme disent les jeunes.
C'est aussi une façon de mieux gérer les délais : le "ça marche sur ma machine" n'est plus entendable. A vous, développeurs, d'anticiper l'étape critique du passage en production dès la mise en place de la codebase (en fait lors du walking skeleton). Cela afin de ne pas découvrir au dernier moment (+3 mois dans la vue) qu'il vous reste à mettre en place l'authentification, la gestion des droits applicatifs, la gestion des logs et que vous n'avez en fait aucune idée de comment déployer votre application 🙄
Mais je dirais que l'injonction de Werner Vogels s'adresse avant tout à ceux, CTO et VP of Engineering, qui façonnent les organisations : pour eux, pour elles, c'est éviter de mettre des bâtons dans les roues de leurs équipes avec une organisation structurellement défaillante. C'est très bien de responsabiliser les développeurs, mais encore faut-il éviter les injonctions contradictoires. Elles conduisent à l'épuisement des personnes les plus volontaires.
On le sait, on le redit : créer une équipe "Production" ou "Plateforme" ne marche pas, pas plus qu'une équipe "Support" (équipe à tout faire), ni même une équipe DevOps (essaie encore) : cela éloigne les développeurs de la finalité métier et crée des silos.
Alors pourquoi créer de telles équipes est-il si tentant ?
Parce que l'entreprise souhaite rationaliser les coûts, éviter un foisonnement incontrôlé des technologies, pousser des bonnes pratiques de sécurité etc.
Alors comment satisfaire ces besoins, qui bien sûr ne disparaissent pas par magie lorsqu'on décide enfin de casser les silos ?
Comme souvent, c'est subtil : il faut diriger, encadrer, contraindre peut-être, sans toutefois se substituer aux équipes de développement. Cela passe par des bibliothèques de code partagées, des normes d'architecture et de sécurité, mais avant tout de la sensibilisation et de la formation. Autrement dit, toute une animation transverse, complémentaire de l'organisation orientée produit précédemment évoquée.