De retour de la conférence PlovDev, j’ai eu à répondre à quelques questions pour la newsletter de mon ESN Proxiad. Si j’y suis responsable DevOps, je suis surtout un passionné et un profond convaincu de ce mouvement. Il entre dans la dynamique du surgissement d’un nouveau monde. Une ère passionnante s’ouvre à nous !

Ayant à coeur de dynamiser et partager cette nouvelle approche, je me permets de publier ici cet interview.

Une application est absolument tout ce qui existe et se passe entre le push et l’exploitation d’un commit. Quand on intègre cette notion, on comprend le DevOps.

Comment t’es venu l’idée de donner une conférence DevOps à Plovdiv ?

L’idée n’est pas de moi mais de nos collègues bulgares qui souhaitaient la présence d’un proxiad français à leur conférence PlovDev, le choix du sujet était ouvert. Quand j’ai reçu un appel pendant mes vacances pour me faire part de l’idée d’y présenter le DevOps, j’ai tout de suite été séduit par ce projet.

Que ce soit en anglais ne t’a pas freiné ?

Pas du tout. Non que je sois excellent en anglais ! M’est avis qu’il ne faut pas s’arrêter parce qu’on n’est pas à l’aise, il faut savoir se préparer. Cet adage s’applique à beaucoup de domaines.

Et tu étais donc préparé ?

Pour mon intervention plutôt bien. Pour mon séjour beaucoup moins ! J’ai découvert à l’aéroport que la Bulgarie applique avec une certaine distance les accords de Schengen et surtout qu’elle n’a pas adoptée l’euro !

Comment s’est passé ta présentation ?

J’avais prévu quelques phrases de transition et surtout la phase d’introduction du sujet. Pour des questions de disposition je ne pouvais lire mon laptop et j’ai dû improviser dès le départ. La difficulté a été l’absence de chronomètre, j’avais 43 slides à passer en 45 minutes. Sans mesures, c’est compliqué de livrer avec qualité.

C’est une phrase DevOps ça ?

Tout à fait ! Et c’est même l’un de mes deux regrets. J’ai dû accélérer les choses, voire les précipiter à la fin, et j’ai donc pris des raccourcis et sans doute mal communiqué l’importance de la mesure dans une démarche DevOps.
Le second regret est d’avoir été trop léger sur le redesign de l’application devant une assistance de Dev. J’aurais dû m’assurer de bien leur présenter qu’il ne faut plus penser l’application comme un monolithe de fonctions, mais comme un ensemble de services. Si tu exposes des APIs ton application peut être requêtée par elle-même tout autant que par les autres applications !

Pourquoi est-ce si important ?

Parce que cette fragmentation en petites briques indépendantes est le prérequis pour livrer juste des segments de ton application et non toute l’application. En opérant ainsi tu peux livrer des fonctionnalités indépendamment des autres. Autrement dit, tu n’attends plus le gnou le plus lent pour tout livrer. Une fonctionnalité prête à être livrée doit l’être pour apporter de la valeur à l’entreprise. Attendre c’est créer un stock (Lean).
Quand certains parlent de livraison quotidienne voire encore plus fréquente, ils ne parlent pas de toute l’application mais d’une fonctionnalité de l’application.

Aurais-tu un exemple ?

Par exemple un nouveau filtre sur la liste des clients. C’est aisé à coder, à tester, les effets de bord devraient être mineurs. Disons que ce soit prêt en moins d’une semaine.
Dois-je attendre la fin du mois la fameuse livraison mensuelle ? Ou livrer de suite pour contenter le business avec une fonctionnalité les aidant au quotidien à créer des opportunités commerciales ? Dois-je générer des bénéfices immédiatement ou à la fin du mois ?

Le DevOps serait une histoire de Time-to-Maket ?

Disons que l’objectif de réduire le Time-to-Market à force d’addition de concepts et de bonnes pratiques, a amené à la fin de l’histoire l’approche DevOps. Il faut comprendre le mouvement DevOps non pas comme un début mais comme une conséquence. C’est une histoire qui finit par « … ainsi naquît le DevOps. »

Quelle est donc cette histoire ?

Il est assez difficile de la faire tenir en 43 slides sur 45 min ! Va plutôt pour une liste à la Prévert : Continuous Integration, Continuous Delivery voire Deployment, penser as-a-service, une stratégie de tests, infra-as-code, l’infrastructure élastique, les environnements éphémères, la métrologie, mesure-everything, pipeline, all-involved, et non-event.

Et pour toi lequel de ces concepts est le plus important ?

Tous sont importants. Néanmoins le concept le plus important est de bien percevoir qu’une application n’est plus seulement du code compilé, une application est absolument tout ce qui existe et se passe entre le push et l’exploitation d’un commit. Quand on intègre cette notion, on comprend le DevOps.