Retour des DevOpsDays 2010 à Hambourg

le 28/10/2010 par Rudy Krol

Le 15 et 16 Octobre ont eu lieu les DevOpsDays 2010 à Hamburg. Cette conférence est l’occasion de réunir les DevOps désireux d’apprendre des retours d’expérience et surtout d’échanger via des Open Spaces. Si le terme DevOps est nouveau pour vous, je vous conseille de lire cet article d’introduction.

Un an après la première édition en Belgique, et un passage aux quatre coins du globe (US, Australie et Brésil), on peut dire que le mouvement prend de l’ampleur : le retour en Europe fût un réel succès ! Je vous propose ici un résumé de ces deux jours passionnants autour de 4 axes : des outils, des processus et méthodologies, de l’architecture, et enfin la culture et le facteur humain.

Des outils pour automatiser, tester et superviser l'infrastructure

Spike Morelli nous a présenté les concepts de déploiement d’infrastructure mis en œuvre sur Second Life (une dizaine de milliers de machines à exploiter). Il s’est amusé à comparer les fermes de serveurs à des fermes agricoles. Les agriculteurs ont deux problèmes majeurs : les insectes et les mauvaises herbes. Côté IT, les insectes (enfin... les bogues) sont traités à coup de tests et d’intégration continue. Les mauvaises herbes sont tous ces changements qui modifient l’état du système au cours du temps... difficiles à maitriser. Le problème de fond soulevé par Spike est qu’il n’existe aucune couche d’abstraction pour les changements niveau système, ils dépendent directement du système d’exploitation. Pour y remédier, la solution mise en œuvre sur Second Life est de déployer une infrastructure basée sur des images et d’interdire tout changement sur ces images. Ces images sont construites et packagées avec KVM sur la plateforme d’intégration continue à chaque modification de code de l’application. Elles contiennent alors l’application dès sa construction. C’est bien la même image qui est déployée sur les différents environnements : dev, recette, pré-prod et prod. Pour cela, il faut que l’image soit entièrement stateless, la configuration doit donc être stockée en base de données. Plusieurs avantages à cette approche dont une meilleure répétabilité et un renforcement de la collaboration entre études et prod. Quelques difficultés à souligner : beaucoup d’efforts pour rendre les services adaptés à ce type d’infrastructure, plus gros artifacts à télécharger (ce qui pousse à passer à une solution type BitTorrent comme Murder utilisé par Twitter). Par contre, je me demande bien combien de temps prend leur build et combien de téraoctets fait leur référentiel d'artifacts...

Un des sujets souvent abordés lors de la conférence, que ce soit au travers des Talks ou des Open Spaces, est la gestion de la configuration. Une des questions soulevées à plusieurs reprises est : doit-on tout packager (au sens package RPM ou Debian) ? La réponse : ben... ça dépend ! Les Ops y sont évidemment plutôt favorables... De mon point de vue, dans les cas fréquents d'application simple, la valeur ajoutée peut paraître faible comparée à un zip. OK, ça permet d'économiser l'écriture d'un script qui décompresse le zip au bon endroit, change des droits sur des fichiers et exécute d'autres scripts avant et après l'installation. Mais, à l'exception des projets sous Maven qui peuvent automatiser la génération des packages avec rpm-maven-plugin et deb-maven-plugin, il faut bien avouer que l'automatisation du packaging est une tâche complexe pour les Devs. Par contre, si le nombre de composants installés et la compatibilité entre eux deviennent trop complexes, les packages restent la meilleure solution (standard et outillée) pour gérer les dépendances et versionning de packages.

Pour les rares participants comme moi qui ne connaissaient Puppet et Chef que de nom, nous avons eu le plaisir d’assister à quelques démos très intéressantes. Beaucoup de retours d’expérience positifs même si quelques problèmes restent à résoudre, en particulier la testabilité du code utilisant ces technologies. Comment faire pour bouchonner des services externes ? Comment simuler une panne ou une dégradation des temps de latence ? Il n’existe pour le moment rien de très outillé pour répondre à ces problématiques... Sur le même thème, Nikolay Sturm nous a présenté cucumber-puppet ; un outil permettant de tester les spécifications d'un catalogue Puppet en language naturel. C'est encore en alpha mais l'idée d'uniformiser l'outillage de test (tests fonctionnels et non-fonctionnels en Cucumber) me paraît intéressante et une nouvelle opportunité de favoriser les échanges entre études et production.

Beaucoup d’autres outils ont été mentionnés lors de la conférence, difficile de tous les présenter sur ce post : Vagrant pour créer et gérer des environnements virtuels, AppDynamics pour superviser des applications JEE, Grinder pour tester en charge, etc.

Des processus et méthodologies pour fluidifier les interactions autour du produit

Le Talk d’ouverture proposée par Stephen Nelson-Smith (à l’origine du post What is Devops thing, anyway?) était l’occasion d’apprendre d’un retour d’expérience où Stephen a dirigé l’équipe de production sur le site du gouvernement anglais. Le principal message qui est ressortit de cette présentation est que l’utilisation d’outils comme Puppet renforce l’idée que l’infrastructure est du code. Et pour garantir la stabilité et la fiabilité des plateformes, ce code doit être traité de la même manière que le code de l’application qui y sera déployé, suivant les méthodologies agiles : test driven development, intégration continue, refactoring, pair programming, code review, etc. L’infrastructure doit également se construire de manière incrémentale, en corrélation avec la roadmap du produit en priorisant sur les MMF déclinés sur des besoins d’infrastructure et mettre en place des rituels comme les standup meeting et démonstrations. Bref, autant de bonnes pratiques issues du Dev et sur lesquelles les équipes de production sont encore en phase d'appropriation.

Une autre présentation orienté processus, plus transverse cette fois-ci, était présentée par Jezz Humble (consultant ThoughtWorks). Celle-ci était consacrée au « Continuous Delivery », un processus qui repose essentiellement sur la mise en place d’un « pipeline » de livraison continue d'applications prêtes pour la production. Livrer fréquemment permet d’avoir du feedback rapide, de réduire les risques de déploiement (car plus petits changements) et de voir l’application évoluer progressivement. Jezz a beaucoup insisté sur les pré-requis : intégration continue, check-in sur une branche principale, tout stocker dans le gestionnaire de source, stratégie de tests (Agile Testing Quadrant), automatiser presque tout, etc. En gros, le principe est que chaque build de l'application est une « release candidate » qui traverse les différents sas du « pipeline » (de manière automatisée ou manuelle si une validation est nécessaire pour passer à l’étape suivante à travers de simples « push-button »). Par exemple :

construction de l'application (compilation, exécution des tests unitaires, packaging, etc.)
déploiement automatique en environnement de développement
exécution des tests fonctionnels automatisée
déploiement automatique en environnement de recette
exécution des tests manuels (exploratoires, usabilité, etc.)
déploiement en pré-prod sur « push-button »
tests de besoins non-fonctionnels (performance, sécurité, etc.)
déploiement en prod sur « push-button »

Le pipeline est l’épine dorsale du processus permettant de réunir les différentes équipes autour du produit et de modéliser un flux de la construction de l’application jusqu’à sa mise en production. Chaque story est alors considérée comme « DONE » lorsqu’elle est « released ». Les différentes opérations du pipeline doivent être répétables et fiables, donc automatisées (« automation over documentation »). L’objectif ultime de ce processus est de donner plus de contrôle aux testeurs et au marketing afin qu’ils puissent déployer eux-mêmes à tout moment une version sur un environnement ! Si vous êtes intéressé par le sujet je vous recommande son livre, très complet, avec des bonnes pratiques à tous les niveaux (gestion de configuration, intégration continue, stratégie de tests, packaging, déploiement, gestion des dépendances, infrastructure, base de données, etc.).

Pour finir autour du thème processus et méthodologies, David Anderson a répondu à quelques questions autour d’un « Fishbowl » sur la mise en place de Kanban dans les équipes de production. Contrairement aux études, une des difficultés majeures rencontrée par les équipe de production est d’être souvent dépendants d’acteurs externes : équipe de développement, fournisseurs de service, fournisseur de hardware, etc. Pour cela, David Anderson propose de stocker toutes stories en attente de l’extérieure dans une boite et d’estimer un SLA pour chacune de ces stories, c'est à dire un engagement que peut prendre l'équipe sur la « livraison » de cette story. Celles-ci doivent être revues chaque jour en standup meeting pour suivre leur avancement et lever des alertes en cas de dépassement de SLA. Une autre difficulté rencontrée par la production est de devoir gérer des types de tâches très hétérogènes, plus ou moins longues et plus ou moins critiques. David est revenu sur le principe de classes de services pour améliorer la priorisation des tâches. Plus tard durant la conférence, nous avons également discuté de la solution optée chez Spotify : le « goalie ». Le principe est simple, chaque semaine un des membres de l’équipe de production est responsable d’intercepter toutes les demandes entrantes et de traiter directement celles qui sont rapides et/ou urgentes pendant que les autres peuvent travailler sur des tâches de plus longue haleine sans interruptions.

De l’architecture pour fédérer les équipes et supporter les livraisons fréquentes

Chris Read et Sam Newman (respectivement de DWR et ThoughtWorks) nous ont fait part de leur retour d’expérience sur un moteur de recherche anglais où ils ont apporté cette culture DevOps pour palier aux problématiques de silotage des équipes projets. L’architecture du site était, comme d’habitude, à l’image de l’organisation, composée de 15 applications ! La conséquence de ces silos : peu de réutilisation de code, peu de cache, déploiements compliqués, peu de monitoring, etc. Les problèmes de performance ont nécessité la refonte du cache web (passage à Squid) ce qui a été l’occasion de réunir tout le monde (dev et ops de chaque projet) autour du produit. C’était le point de départ d’une étroite collaboration entre les équipes, ce qui leur a permis par la suite de fusionner les équipes (et donc les applications) pour ensuite attaquer d’autres problèmes dont la réutilisation de code. La présentation était très axée sur les problèmes de performances causées par le manque de cache. Pour la petite histoire, l’architecture finale du cache est composée de deux machines exécutant deux instances Squid, ce qui leur permet aujourd’hui de tenir 2,8 millions de requêtes par heure en pic, 3000 hits/sec et 1400 misses/sec. J’ai beaucoup aimé le sujet car je suis convaincu que la mise en place de composants d'architecture tels que le cache web nécessite une forte collaboration entre les deux mondes (étude et production). Cette collaboration doit être initiée le plus tôt possible ! Souvent elle intervient en phase d'optimisation, juste avant la mise en production, ce qui est déjà trop tard...

La présentation de Jezz Humble sur « Continuous Delivery » a également été l’occasion d’aborder les quelques concepts d’architecture essentiels pour soutenir un rythme de livraisons élevé. En effet, il est souvent difficile de concilier « check-in fréquent » avec le fait de construire continuellement une application prête pour la production. Le développement d’une fonctionnalité nécessite parfois plusieurs jours de travail, alors comment faire pour que ces développement ne soient pas visibles de l’utilisateur s’il elles ne sont pas « DONE » ? L’utilisation de « feature branch » ou « feature team » implique l’utilisation de branches sur le référentiel de sources, ce qui est contradictoire avec la pratique d’intégration continue. La technique de plus en plus utilisée est de brancher dans le code via l’utilisation de ce qu’on appelle des « feature bits » (ou « feature flags » selon Flickr). Ces « flags » permettent d’activer ou désactiver une fonctionnalité via une configuration stockée en base de données, modifiable au runtime. En gros, il s’agit d’un simple « if » conditionnant l’affichage d’un bouton, d’un menu, d’une partie d’un écran ou d’autres couches techniques s’il s’agit d’un traitement non visible de l’utilisateur mais qu’on ne souhaite pas activer (par exemple : service REST, batch, etc.). La technique de « branch by abstraction » est également intéressante pour effectuer de gros refactoring sur l’application sans pour autant impacter son bon fonctionnement.

Une culture et des Hommes avant tout

Vous l’aurez remarqué, jusqu’ici rien de révolutionnaire : quelques nouveautés technologiques pour automatiser toujours plus et donc améliorer la réactivité face aux nouveaux besoins, un élargissement des principes Agiles au delà des frontière des équipes de développement, des concepts d’architecture pour garantir que l’application est toujours « production ready », etc. Mais dans le fond ces principes sont connus depuis un certain temps maintenant. DevOps est avant tout une culture ! John Willis (évangéliste Chef chez OpsCode, et co-animateur du podcast DevOps Cafe avec Damon Edwards) a d’ailleurs fait une remarquable présentation à ce sujet. Les divers retours d’expérience ont mis en évidence la difficulté de changement culturel, la nécessité de provoquer les rencontres entre études et production, de consacrer plus temps au « team building ». Comme l’a démontré le Talk de Chris Read et Sam Newman, il est fondamental de trouver un point de départ à cette dynamique et obtenir des résultats concrets pour que les équipes prennent conscience des enjeux de la démarche.

Pour introduire cette culture dans les entreprises, il faut aussi et surtout des hommes passionnés désireux de monter en compétence autant sur le plan technique que méthodologique. Pour résumer, un DevOps doit être capable de comprendre les enjeux du produit, faire abstraction des frontières organisationnelles, proposer des solutions transverses aux problèmes de silos, communiquer et être ouvert à la collaboration et la coopération. C’est donc aussi et surtout quelqu’un ayant suffisamment de leadership pour souder les équipes entre elles et forcer les rencontres à travers des points d’avancement réguliers.

Conclusion

Au cours de cette conférence, un constat est apparu comme une évidence pour tous : il est encore difficile de répondre à la question « C’est quoi DevOps ? ». Chacun a sa propre définition et beaucoup d’idées fusent dans tous les sens, ce qui est plutôt positif mais à tendance à brouiller le message originel. De ce constat est né l’idée de rédiger un Manifesto. Jezz Humble a initié un Open Space à ce sujet, le draft est disponible ici. Certains pensent que cette initiative peut créer de la confusion et voient plutôt DevOps comme une évolution du Manifesto Agile. Affaire à suivre… Pour ma part, peu importe la forme que cela doit prendre, l’essentiel est d’éclaircir le message pour diminuer le FUD et faire comprendre que DevOps est tout sauf une mode ou un mouvement de geeks pour les geeks. Tout l’enjeu est bien d’améliorer les performances des entreprises. Comme le dit Damon Edwards dans le dernier podcast DevOps Cafe : « DevOps is a business problem. ». Aujourd’hui, les quelques entreprises qui l’ont compris prennent de l’avance concurrentielle. Je pense par exemple à Google et Amazon qui sont capables de livrer une nouvelle fonctionnalité en production en quelques semaines seulement. Moi ça me fait rêver… et vous ?