“Dans une démarche Devops, le choix des outils peut conditionner un succès. Ou un échec…” - Interview d’Arnaud Mazin, auteur de Culture DevOps Vol.02
Après un premier livre blanc centré sur la culture et l’organisation, la tribu DevOps d’OCTO poursuit son tour d’horizon du métier. Plus axé sur la technique, ce second volet de la trilogie Culture DevOps se focalise sur l’outillage qui gravite autour de l’automatisation des applications et des infrastructures.
Mais encore ?
Télécharger Culture DevOps Vol.02
A qui s’adresse la trilogie Culture DevOps, et plus particulièrement ce volume 2 ?
A tous ceux qui veulent comprendre les enjeux et les bonnes pratiques DevOps.
Le second volume concerne particulièrement les personnes confrontées concrètement à des problématiques techniques de déploiement et d'industrialisation – côté dev, ops ou côté architecture.
Les volumes 1 et 3 (à venir), qui traitent respectivement des sujets d’organisation et des pratiques de qualité portent des messages qui ne laisseront pas le top management insensible...
Pourquoi ce focus sur les technologies et les outils vous semblait-il particulièrement utile ? Est-ce qu’il existe un flou autour de ces notions ?
Parce que nous avons éprouvé ces technos dans la vraie vie, et qu’elles nous rendent plus performants et plus véloces. Qu'est-ce qu’on nous demande en tant que DevOps ? De la qualité et de la vélocité. Ces outils nous permettent d’atteindre ces deux objectifs simultanément. Ils en existent beaucoup, que nous n’avons pas évoqués, mais ceux-ci vont pour nous dans la bonne direction.
Il y a un vrai malentendu technologique autour de DevOps. On pense qu’on peut en faire dans toutes les situations, et avec toutes les technos. Autant parfois vouloir sortir toute la panoplie peut avoir du sens, mais vouloir absolument toutes les utiliser relève de l’utopie et peut entraîner de réelles difficultés. C’est l’intention qui fait le bon usage, pas les outils. Le choix de ces derniers peut conditionner un succès. Ou un échec…
Nous voulions attirer l’attention là-dessus.
Est-ce que ca veut dire que vous recommandez systématiquement l’utilisation de la conteneurisation, par exemple ?
Pas forcément. On peut obtenir de très bons résultats sans aller aussi loin, en utilisant des outils plus historiques comme l'infra as code traditionnel. Le coup d’après n’est pas forcément intéressant.
C’est le cas parfois aussi dans certains contextes sans cloud ni architectures distribuées.
Est-ce que ces technos suffisent pour faire sauter tous les verrous ?
Non, en réalité ces technos – et la démarche qu’on a derrière – sont des catalyseurs. Elles permettent de focaliser son travail sur l’architecture et développement des applications. On ne fait pas de l’infra pour de l’infra. Le but est d’éliminer rapidement les problèmes qui peuvent être résolus par des automatisations de bonne qualité, rendre l’infra la plus transparente et invisible possible… pour se consacrer davantage aux applications.
Vous parlez à la fin du Vol. 02, de trois éléments qui vont profondément modifier votre approche : la cryptographie, l’IA et la conception responsable. Pourquoi avoir choisi ces trois-là en particulier ?
Nous n’en avons cité que trois parce qu’il fallait faire un choix. Mais nous aurions pu en évoquer d’autres : Serverless et DevSecOps par exemple, auraient mérité leur place ! (Quelque chose me dit qu’on parle déjà de DevSecOps chez OCTO !)
Pourquoi ces trois-là ? Parce qu’ils nous remettent en question, et ce questionnement est notre moteur !
Ce que nous aimons, c’est être en recherche perpétuelle de moyens de faire mieux. Si le Volume 1 de Culture Devops a des chances d’être atemporel, celui-ci ne l’est absolument pas ! On rigolera peut-être dans 5 ans de s’être trompé à ce point. Certaines des technologies que l’on utilise aujourd’hui n’existaient pas il y a 10 ans et il y a peu de chance qu’elles survivent aux 10 prochaines années. Gérer l’obsolescence fait donc partie de l’exercice et l’accepter est fondamental.
Qu’est-ce que vous faites déjà chez OCTO pour vous préparer à affronter ces éléments perturbateurs ?
Pour la cryptographie, nous avons déjà pris l’habitude de la mettre en œuvre de plus en plus à travers une démarche disciplinée de notre métier, qui nous permet déjà de pallier les difficultés que cela peut entraîner.
En ce qui concerne l’IA et la conception responsable, les bouleversements sont plus profonds. Mais des groupes de travail et des initiatives internes sur ces sujets ont vu le jour chez OCTO ! Ils commencent à nous y préparer… et nous gardons nos chakras ouverts.
Quels sont les grands défis auxquels la pratique DevOps est confrontée aujourd’hui et en quoi vos deux premiers volumes permettent d’y répondre ?
Nous voulions déjà sortir du buzzword. On ne fait du DevOps parce que c’est hype ! Parfois, ce n’est pas pertinent et on est les premiers à le dire.
Il y a aussi un énorme travail sur l’accompagnement des personnes qui vont utiliser les outils. Il faut mettre le paquet sur l’humain et cela manque encore.
Nos livres permettent d'éliminer les premiers mauvais choix (d’organisation, d’outils, de pratiques…). C’est un premier niveau d’écrémage ; on ne prétend pas tout résoudre, mais nous posons au moins des bases saines.