headerphoto

Devops - premières rencontres et survol

Ce mercredi 1er décembre j'ai eu le plaisir de participer à la première rencontre Devops parisienne; en voici un compte-rendu, et bien sûr je vais tenter de répondre à la question que vous vous posez déjà: "Devops, qu'est-ce que c'est encore que ce bidule ?"

Commençons par les ingrédients: un petit groupe (une douzaine de personnes) qui se réunissait dans une ambiance informelle et très auto-organisée, la plupart ne connaissant pas les autres participants présents, simplement pour discuter d'un sujet qui leur tenait à coeur: recette classique pour passer une soirée passionnante. (Merci au passage à nos hôtes, Theodo, et aux initiateurs, Philippe, Samuel et Fabrice.)

Ajoutons des bières et des pizzas; en effet "Devops" est un raccourci pour "developers and operations", c'est à dire des intervenants du développement (appelés diversement programmeurs, développeurs, codeurs, "softeux", etc.) et de l'exploitation ("exploitants", ingénieurs de production, administrateurs systèmes, etc.). Vous aurez compris qu'on est entre techniciens...

Pourtant il y a là deux cultures très différentes, et on s'en aperçoit vite à mesure que le tour de table pour faire les présentations commence, chacun y allant de son "troll", petite pique pour deviner à la réaction de chacun qui fait partie de quel bord, ça donne à peu près: "je m'appelle X et je préfère vi à emacs, il faut que j'en dise plus?" Le sujet qui nous réunit c'est justement le rapprochement entre deux cultures que l'organisation usuelle des projets de développement a eu tendance à séparer. (Parfois littéralement, au sens "les développeurs dans la grande salle du 3è étage, les exploitants à la cave".) Certains des effets néfastes de cette séparation sont proverbiaux dans la profession: "excuse n°1 du développeur: ça marche sur ma machine!".

Après le tour de table Raphaël a proposé d'organiser le reste de la réunion en Open Space, ce qui nous a permis d'apprécier l'étendue des sujets qui nous intéressaient. De mémoire et en vrac:
  • des outils (Chef ou Puppet) pour gérer les configurations système
  • exploiter la virtualisation du développement à l'exploitation
  • intégrer la création de packages dans le build automatisé
  • déploiement maîtrisé des applications Web 
  • ...et d'autres que j'oublie...
 Cette liste ne vous apprend sans doute pas grand-chose sur ce que veut dire "Devops"? C'est justement tout l'intérêt de cette communauté naissante.

Je m'explique: de façon très similaire à l'invention en 2001 du terme "Agile", la communauté Devops est née du sentiment diffus d'un certain nombre de personnes qu'elles avaient, chacune dans leur coin, eu des idées convergentes pour résoudre des difficultés lancinantes dans leur métier. En se rencontrant et en donnant un nom (une étiquette, certes) à cette convergence elles espèrent donner plus de visibilité à la fois à ces difficultés et aux solutions proposées.

Il s'agit donc de briser les "silos" qui isolent les développeurs et les exploitants chacun dans leur coin, avec de nombreuses conséquences néfastes: par exemple des projets qui semblent "réussis" techniquement (code propre et bien testé) et fonctionnent très bien... jusqu'au jour de la "mise en prod" où rien ne va plus: quelques connections simultanées et le serveur "tombe", ou encore une base de données ralenties par des accès mal conçus.

On retrouve dans cette volonté de "déspécialiser" une constante de la culture Agile, au sein de laquelle d'ailleurs les fondateurs de Devops ont fait leurs armes. Le discours Agile a cherché à modifier, voire à effacer les frontières entre développeurs et clients, entre développeurs et testeurs, ou plus récemment entre développeurs et ergonomes; Devops vise à abolir une frontière supplémentaire. Plutôt que développer dans leur coin des applications qu'ils vont ensuite "balancer par-dessus le mur" aux exploitants, les développeurs sont encouragés à travailler dès le début du projet avec eux et à les intégrer à l'équipe.

De même que le discours Agile s'oppose à des approches "cérémoniales" ou totalisantes du développement, de même Devops se positionne comme une réponse "Agile" aux démarches ITIL ou Cobit très prisées dans le domaine de l'exploitation.

On retrouve donc dans l'approche Devops, d'une part des outils et pratiques "empruntés" à l'approche Agile:
  • outils de management visuel (on parle de "visible ops") pour créer de la transparence
  • alignement sur un rythme itératif et incrémental (mettre en production au rythme du développement)
  • automatisation du test
  • intégration continue
Mais on va également trouver dans Devops des solutions spécifiques, transposant l'approche Agile au métier de l'exploitation, ou qui visent à établir un nouveau contrat avec les développeurs:
  • l'automatisation du "build" ne doit pas se cantonner à produire un exécutable mais va jusqu'au bout de la chaîne en produisant un "package" dont l'installation est répétable et même automatisable
  • considérer la description d'une infrastructure système comme du code, et intégrer ce code à la gestion de version au même titre que le code applicatif; c'est l'intérêt d'outils comme Chef ou Puppet
  • de même qu'on ne teste pas à la main, on n'installe pas à la main, on ne configure pas à la main, etc. - tout ce qui est manuel et répétitif représente de la connaissance et il faut capturer cette connaissance sous la forme de fichiers texte ou de code
  • intégrer très tôt dans le cycle de développement les questions de surveillance et de gestion de l'application, de benchmarking des performances, etc. - en d'autres termes adopter une vision d'ensemble
  • plus généralement considérer qu'on est "tous dans le même bateau" et qu'il n'est pas productif de chercher "à qui reviennent les reproches" lors d'un incident en production: abolir les petits jeux qu'on voit fréquemment pour savoir si c'est un bug ou un défaut de surveillance qui est à l'origine d'une panne par exemple; adopter des outils, des processus et surtout une responsabilité partagées
Vous pourrez trouver plus d'information ailleurs sur le Web:
Les parallèles avec la communauté Agile sont intéressants, notamment le fait que la question "qu'est-ce que DevOps" ne donne pas pour l'instant lieu à une réponse brève, précise et circonstanciée, le mouvement se dérobant aux tentatives de définition. On pourrait le réduire à des outils: de fait au cours de la soirée de mercredi nous avons beaucoup parlé d'outils (j'ai découvert l'existence de Chef, Puppet, Vagrant et d'autres outils et je vais m'y intéresser, par curiosité et pour ma culture générale), mais ce serait la même erreur que de réduire l'approche Agile à des outils.

Dans les deux cas, il ne s'agit ni de définir des méthodologies, d'imposer des processus ou des outils,  mais de créer, d'animer et de se réclamer d'une communauté; l'objet de cette communauté étant l'élaboration et la conservation d'un ensemble de pratiques, non pas pour leur valeur en soi (on ne "sacralise" pas les pratiques) mais pour les bénéfices que ces pratiques apportent aux projets.

3 commentaires:

Sébastien Douche a dit…

Je possède les 2 cultures : je fais du dev depuis 20 ans (perso puis pro) et de l'admin (en pro) depuis 10 ans maintenant. Et je dois dire que cela m'aide *beaucoup* dans mon travail : cela me permet d'intervenir sur l'ensemble de la chaine de valeur et de l'optimiser sans cette fameuse barrière dev / admin. D'ailleurs, je retrouve dans vos sujets abordés des fonctionnalités que nous avons mis en place :

- création d'un environnement virtualisé à la demande pour les tests
- le test (quelques que soit la version, stable comme dev) se fait en créant un package binaire identique à celui déployé par un client. Les tests internes reproduisent la chaine complète (et non juste un test sur une machine de développeur).
- l'environnement de buid permet de créer des versions en cours de developpement (version stable + 1 bugfix ou fonctionnalité en cours)
- le système fait du partie de l'ensemble (pas le choix, nous vendons des appliances)
- et plus généralement, il n'y a pas de séparation dev / prod (tous à la R&D, dans la même piece)

Pour en revenir à tes propos. Le rapprochement est encore lointin, car si tu ne veux pas que cela se réduise à des outils, c'est bien ces outils qui sont le point de discordre le plus important. La ou un développeur à besoin d'outil souple pour le développement, l'admin veut des outils en rapport avec sa philosophie.

Un exemple assez criant se trouve sur les outils de gestion de composant. Un développeur travail avec Maven (Java) ou Buildout (Python), la ou l'admin veut du RPM / DEB, qui s'intégre dans son OS, ses outils classiques de gestion de parc, et qu'il maitrise. Et apprendre à un admin les outils de dev, c'est le faire rentrer dans le monde du dev, avec toute sa complexité : outil de gestion de source (Git), outil de composant code (Buildout), fonctionnement des paquets Python (Egg) sont par ex. le minimum vital qui doit être maitrisé ici. Rien de bien méchant pour un dev, mais un pas gigantesque pour un admin qui n'a jamais développé de sa vie (à part modifier quelques scripts Shell ici ou la).

On peut voir cette dychotomie dans la refonte du projet Distutils2, de mon ami Tarek : l'objectif est de revoir le packaging Python (trop longtemps délaissé hélas). De longues discussions ont suivis sur les besoins et exigeances de chacun, et on a pu voir distinctement qu'un admin (admin lambda, responsable de packages Debian...) avait une vision bien différentes des développeurs.

Un autre aspect intéressant est le cloud : la plupart n'offre plus la même liberté d'administration, et c'est bien l'aspect développement qui est mis en avant. J'ai pu tester récemment Heroku, une plateforme d'hébergement d'application Ruby : on gère ses instances avec un outil CLI qu'on télécharge sur sa machine puis on met en prod... avec Git. Le modèle Heroku semble prendre de l'ampleur (naissance de plusieurs plateformes de ce type en cours).

Clairement, cette barrière doit disparaitre mais le changement de culture sera aussi important que de faire disparaitre MOE / MOA je pense.

G a dit…

Bonjour Laurent,

Merci pour ce compte-rendu, je n'ai malheureusement pas été en mesure de venir à ce premier meetup-parisien.

Je m'inscris un peu en faux sur l'impression que me donne ta phrase "Vous aurez compris qu'on est entre techniciens...".

Je conviens que le choix du nom devops est un peu malheureux et de nature à donner l'impression qu'il s'agit là d'un mouvement de techniciens pour les techniciens.

Du chemin a été parcouru depuis le premier Devopsdays à Gand en 2009 où le nom est apparu, et déjà à l'époque le nom était apparu comme trop réducteur car il n'adressait qu'une partie des centres d'intérêts des personnes présentes.

En fait les difficultés entre dév et prod n'étaient que la partie cachée de l'iceberg, et les problèmes abordés étaient aussi bien techniques qu'organisationnels ou humains.

DU fait du rayonnement international de la conférence et parce qu'il remplissait un vide, le terme devops [1] s'est propagé comme une trainée de poudre et s'est imposé.

Si l'on peut regretter que le terme soit trompeur, ce défaut est à mon sens contrebalancé par le fait qu'il existe désormais une étiquette sous laquelle nous sommes nombreux à nous retrouver pour échanger.

Je ne doute pas qu'au vu des profils des gens ayant participé au premier devops meetup parisien la majorité des problématiques abordées aient été plutôt techniques, et il est de fait logique que ce soit ce point qui apparaisse dans ton compte rendu, mais il me semblerait dommageable que cela renforce chez tes lecteurs l'ambiguité déjà imputable au nom.

A mon sens devops est un mouvement qui traite des problèmes liés à l'informatique d'entreprise, ce qui est un vaste sujet! De fait, je partage complètement l'avis de Damon Edwards : devops n'est pas la réponse à un problème technique mais à un problème business [2]. J'invite les lecteurs curieux ou réfractaires à l'anglais à aller lire la rapide présentation que j'ai posté il y a de cela plusieurs mois déjà sur devops.fr [3].

Cordialement,
Gildas Le Nadan
http://blog.endemics.info / @endemics
--
[1] Le plus souvent d'ailleurs sous une forme, "DevOps", différente de celle souhaitée initialement par Patrick Debois pour qui les majuscules rappellent malheureusement la séparation entre dév et prod.
[2] http://dev2ops.org/blog/2010/11/7/devops-is-not-a-technology-problem-devops-is-a-business-prob.html
[3] http://www.devops.fr/ qu'il est plus qu'urgent que je mette à jour

G a dit…

Bonjour Laurent,

Visiblement je ne peux pas poster de commentaire ici, j'ai mis ma réponse sur mon blog [1] en attendant,

Gildas

[1] http://blog.endemics.info/post/2010/12/03/R%C3%A9ponse-au-post-de-l-Institut-Agile-%3A-%22Devops-premi%C3%A8res-rencontres-et-survol%22

Enregistrer un commentaire