Accueil > J'y étais ! > DevopsDays Paris 2013

DevopsDays Paris 2013

Les DevopsDays Paris ont eu lieu ces jeudi 18 et vendredi 19 avril 2013. Nous y étions, et voici ce que nous en retiendrons : [SPOILER] Du positif ! [/SPOILER]

devops2013_logo

“Devops”, c’est quoi ? Tout le monde (ou presque) a du entendre ce buzz-word au moins une fois. Né de la concaténation de Developper et Ops (abréviation de operations), le devops n’est ni une méthode, ni un poste (même si certaines sociétés embauchent des devops). Devops, c’est avant tout une culture, une mentalité, une way of life. C’est aussi beaucoup de bon sens.

Tout part d’un constat simple : le but d’un développeur est de livrer des nouvelles fonctionnalités. Le but d’un opérationnel est d’avoir une plateforme stable. Une livraison implique toujours un risque d’instabilité, mais sans livraison, pas de nouvelles fonctionnalités. Devops, c’est une culture qui va amener les gens à prendre conscience de ce que fait l’équipe d’à coté, et essayer de prendre en compte les contraintes de chacun dans le but d’améliorer la qualité du produit/projet.

L’amélioration continue avec la boucle “Build, Measure, Learn” est un excellent point de départ pour amener la culture devops au sein d’une entreprise. C’est d’ailleurs sous cet angle que nous avons choisi de vous présenter les différentes conférences qui nous ont le plus marqués.

Conférences

Build

Comment l’ops a amélioré mon dev

“I don’t want to be called at night, so I call myself a developer”

Florian Gilcher nous explique pourquoi connaitre le point de vue d’un op permet d’améliorer la qualité d’un développement et de mieux gérer la complexité “accidentelle”. Prenons l’exemple d’un développeur qui ne s’occupe pas des problématiques ops. Il va écrire un programme qui va :

  • lire des données (depuis différents formats)
  • traiter les données
  • écrire les résultats (dans différents formats)

un seul livrable mais une classe par action, tout est bon. Simple pour le dev, mais compliqué pour les ops : il faut tout redéployer (donc interrompre) à chaque changement, il peut y avoir des problèmes de scalabilité, etc.

En prenant en compte le point de vue des ops, le dev écrira plutôt un exécutable par tâche : pas besoin d’arrêter la lecture pour corriger le traitement, si une tâche est beaucoup plus gourmande en ressources, le monitoring permettra de le détecter et l’op d’ajouter plus de processus.

On arrive donc à un exemple peut-être légèrement moins simple pour le dev mais beaucoup plus facile à gérer pour les ops. Desormais, Florian se concentre plus sur la qualité “externe” de son appli (sa configuration, sa CLI, etc) que sur la qualité du code “interne”.
Florian nous explique également les problèmes d’une séparation stricte entre dev et ops. Cela devient difficile voire impossible de refactorer la plateforme : les choses vont devenir politiques très vite ! Et sans pratique, les compétences pour ce genre de refactoring risquent de disparaître.
Certaines parties du code risquent également de ne pas pouvoir bénéficier de revue de code, faute de gens pouvant le faire.

La culture devops permet de diminuer les frictions entre les dev et les ops, de partager la connaissance et de réfléchir à l’application dans sa globalité.

Success story @ GOV.UK

Kushal Pisavadia nous présente l’origine de gov.uk et comment les choses se sont déroulées jusqu’à aujourd’hui.

Le point de départ est un rapport de 2010 intitulé Directgov 2010 and beyond: revolution not evolution. Ce rapport constate que le site web du gouvernement britannique d’alors, DirectGov, n’est clairement pas adapté et préconise de ne pas le faire évoluer mais de le réinventer. Pour cela, le rapport propose :

  • un centre d’excellence dans le gouvernement
  • corriger la publication (il y avait des centaines de sites web indépendants)
  • corriger les services proposés (trop complexes)
  • devenir fournisseur de services pour d’autres sites (en proposant des API publiques)

Pour cela, gov.uk s’est donné comme objectif de se concentrer sur les besoins de l’utilisateur, de livrer rapidement et de tout mesurer. En été 2011 sort le site http://alpha.gov.uk/ s’appuyant sur ces principes. Le projet a joué la carte du libre en utilisant des logiciels libres mais aussi en libérant leur code source sur Github. Gov.uk utilise des outils comme capistrano, jenkins ou puppet pour accélérer les déploiements.

Cette vitesse est un vrai atout : 4h pour qu’un développement arrive en production, jusqu’à 20 déploiements par jour, … Ou encore, le dernier patch critique de ruby a été déployé seulement 1h30 après sa sortie !

Ce projet est clairement dans l’esprit devops, allant jusqu’à avoir une page à part entière dessus ! La page décrivant les bonnes pratiques pour développer un service en général est également très instructive.

Measure

Le territoire et la carte, une histoire de visibilité

Au cours de sa présentation, Pierre-Yves Ritschard fait une analogie : la plateforme est le territoire, le monitoring est sa carte. Or notre métier étant très abstrait, nous n’avons pas accès au territoire, seulement à la carte. C’est pourquoi nous devons absolument avoir une carte la plus précise possible (même si cette carte n’est pas le territoire).

Pierre-Yves prend l’exemple des serveurs dans les années 2000 et ceux de 2013. D’un côté, un LAMP (Linux, Apache, MySQL, PHP) et de l’autre HA_PROXY, un cluster de Nginx, Reddis, mysql, cassandra, PHP. Le nombre de serveur a explosé en 13 ans. En revanche, la plupart des outils de monitoring sont identiques : CPU, mémoire.

L’explosion du nombre de serveurs est en partie due à la complexité toujours plus grande des sites. Désormais, la page d’accueil d’un journal agrège des tweets, d’autres journaux, des tendances, des commentaires. C’est pourquoi il faut inventer de nouvelle manière de monitorer sa plateforme : “Extracting meaningful state data from heterogeneous event sources over time”. Il devient nécessaire de mettre en face des métriques traditionnelles d’autres événements : CPU et chiffre d’affaire en fonction du temps.

L’approche Event-Stream

Une des méthodes proposée par Pierre-Yves est l’approche Event Stream. Une grande quantité de petits producteurs vont générer des données pour quelques gros consommateurs.

Les producteurs de données devront normaliser et streamer les évènements. Les consommateurs vont consommer ces évènements en les agrégeant (ratios, sommes, …), les corrélant (mettre en rapport un opération de maintenance et le temps de réponse.) et décider (surveiller, alerter, ignorer, scaler).

Comment améliorer la visibilité dans tout ça ? Il faut trouver les bonnes métriques en partant du business(ex. la home du journal). Ensuite, descendre vers les métriques traditionnelles. Là encore, il conviendra de choisir les bons outils, impliquer tout le monde et challenger les gens. Une des conséquences sera l’amélioration de la qualité et la baisse du taux d’erreurs.

Learn

Produit vs Projet

Pourquoi internet regorge-t’il de produits qui fonctionnent et les DSI de projets qui échouent ? Rémy-Christophe Schermesser commence par nous rappeler ce qu’est un projet :

On appelle projet un ensemble finalisé d’activités et d’actions entreprises dans le but de répondre à un besoin défini dans des délais fixés et dans la limite d’une enveloppe budgétaire allouée.
wikipedia.fr

En revanche le produit c’est tout ce qui peut satisfaire un besoin. C’est donc beaucoup plus facile de rater un projet qu’un produit ! Il faut donc redéfinir la notion de succès pour un projet. Est-ce vraiment du temps, un budget, et un besoin ? Pour un produit, on prend en compte uniquement l’amélioration du travail des utilisateurs !

Dans la démarche produit, toute idée est bonne à prendre. L’appliquer à un projet est certainement une excellente idée. Mais comment réussir ? Build, measure, learn, là encore !

Une fonctionnalité n’a de la valeur que si elle est utilisée. Le but est de créer le Minimum Viable Product, puis de l’améliorer en allant à la rencontre des utilisateurs.

Un autre problème régulièrement rencontré dans les projets est la conduite du changement. Pourquoi Gmail peut changer la vue de création de messages, et pourquoi ne peut-on pas changer de place un bouton dans notre back-office ? Il est important de comprendre que l’utilisateur ne peut pas être laissé seul face à ce changement. L’apparition la première fois d’une aide comme gmail l’a fait pour la vue “nouveau mail” est une excellente idée (les devs pourront aller voir du coté de Chardin.js)

Ensuite, pour mesurer la satisfaction utilisateur, il faut savoir que les utilisateurs mentent aux questionnaires (voir l’exemple de la sauce tomate dans les années 50 aux USA). Ce n’est donc pas la bonne solution. Remy-Christophe propose plutôt de s’intéresser à la seule métrique impartiale et utile : le temps passé pour une tâche.

Enfin, apprendre ! Et apprendre à échouer ! Et échouer pour apprendre.

Conclusion : Think Product, Do project. La collaboration entre équipes est le secret.

L’apprentissage de la culture devops chez un dev

Fabrice Bernhard nous propose une conférence intitulée “Transforming Devs into Devops”. Le constat est que le business a besoin de rapidité. Dans la nature, ce n’est pas la grosse bête qui mange la petite, c’est la rapide qui mange la lente. C’est pourquoi il est important de limiter un maximum le gaspillage de temps : les méthodes agiles ont amélioré la communication MOA-MOE, le devops améliore la communication Dev-Ops.

Fabrice présente ensuite sa méthode en tant que directeur technique Theodo pour transformer un dev en devops. Prenez un développeur junior sorti d’école. La caricature veut qu’il utilise Filezilla pour modifier son portail étudiant, et le CPOLD+mail comme gestionnaire de sources. Saupoudrez ce dev junior avec du git, du SCRUM, du TDD et laissez mariner 2 mois à température sur une banquise GNU/Linux. Le dev junior va devenir un dev devops-friendly. Il faut ensuite l’amener à déployer sur une plateforme ayant suffisamment d’importance pour le responsabiliser. Fabric semble être le bon outil pour l’automatisation.

Attention cependant, un dev et de (bons) outils n’est pas devops. Il y a encore du chemin à parcourir. Fabrice parle de Pair Devopsing, de sensibilisation aux performances (en incluant dans la définition d’une tache terminée des temps de réponse, en affichant dans la salle des rapport de tests de performances), et surtout en partageant la responsabilité d’une plateforme stable.

Openspaces

devops2013_openspace

devops2013_openspace2

Pour nous, c’était un mystère. C’est semble-t-il suffisamment intéressant pour y consacrer autant d’importance que les conférences. Et l’expérience nous montre que c’est effectivement très intéressant ! Le déroulement est simple : On commence par ouvrir les openspaces en prenant 1h30 pour construire un tableau avec des post-it contenant des thèmes de discussion proposés par l’assemblée. Chacun est libre de proposer un sujet (question, retour d’expérience, recette de piña colada), qui sera ensuite soumis à un vote, fusionné avec des sujets identiques.

Comme l’a dit un des organisateurs, ce n’est pas un concours de popularité, un sujet peut ne pas être choisi, voire l’auteur de la proposition peut se retrouver seul dans la salle. “Depuis quand n’avez vous pas pris 45 minutes pour vous introspecter ?”

Les discussions durent environ 45 minutes, les horaires de démarrage et de fin sont donnés à titre indicatif (dans la mesure du raisonnable, “show must go on”). Les organisateurs nous ont fortement incités à papillonner entre les différentes salles. Les règles qui sont en vigueur sont les suivantes :

  • Whoever comes is the right people
  • Whatever happens is the only thing that could have
  • Whenever it starts is the right time
  • When it’s over, it’s over

Et une règle d’or, celle des deux pieds : Si vous avez l’impression de ne rien apprendre, prenez vos deux pieds et allez ailleurs.

Il est très difficile de faire un résumé des différentes sessions, l’ambiance ressemblant beaucoup à une discussion dans un openspace (tiens donc !) où le sujet final est souvent loin de celui annoncé. Pour se faire une idée des thèmes abordés, voici les discussions auxquelles nous avons assisté.

Refactoring infrastructures

Une discussion sur la problématique d’un participant : un écosystème d’applications (discutant en HTTP) à repenser entièrement. Les conseils ont été de versionner les API et de refactorer morceau par morceau. On a également parlé d’améliorer les remontées de métriques vers les devs et évoquer la possibilité d’un tableau de bord centralisant monitoring, données métier, etc

Diffusion de la culture Devops dans l’entreprise

La question initiale venait d’un des participants qui voudrait mettre en avant la culture devops dans son entreprise, celle-ci n’étant “que” agile. La discussion a assez vite dérivé vers la problématique de conserver cette culture devops lors de la “deuxième génération” d’embauche : Il est facile de déplacer la responsabilité sur les devs de certaines choses (ce qui s’est passé pour un des participants). Ainsi, la culture s’entretient, et nécessite une surveillance de tous les instants (measure), et prendre des actions correctives en cas de soucis. C’est finalement un combat de tous les jours.

Comment être un meilleur dev java pour ses ops ?

En utilisant la règle des deux pieds, on se retrouve parfois à prendre une discussion en plein milieu. Ce qui donne (à la traduction en français près) : “… sécurité entre les ops qui partent du principe que tout est fermé et les devs pour qui tout est ouvert.”.

Les ops présents ont également exprimé leur besoin d’avoir accès (en ligne de commande) à l’état de santé de l’application (un health-check : en état de marche ou HS) pour le load-balancer. Il faut aussi pouvoir interagir avec l’application: changer le niveau de log sans avoir à la redémarrer ; si elle possède un cache en écriture, flusher ce cache pour pouvoir faire un backup (consistent).

Enfin, communiquer sur les problématiques de mémoire ! Xmx, Xms, … Les besoins en mémoire d’une application (sans parler du tuning de jvm) ne s’inventent pas.

retours d’expérience de devs et ops ayant vécu le passage devops

La principale chose à retenir est : communiquez ! Impliquez les ops tôt dans le projet !

Mini-jeu de Patrick Debois

Il s’agissait plus d’une expérience que d’un openspace proprement dit. Le but du jeu était d’analyser une infrastructure dans son ensemble pour ensuite dégager des indicateurs et des métriques à monitorer. Le jeu se déroule en groupe de 4-5. Une des personnes du groupe parle de son architecture, et les autres participants la questionnent pour identifier les métriques.

Notre groupe a plutôt ressemblé à un cours sur le monitoring, puisque l’infrastructure choisie était celle de @hgomez, dont on ne peut que vous recommander la présentation sur le monitoring qui a eu lieu à la DevoxxFr 2013 (les slides, en attendant la rediffusion sur parleys.)

Conclusion

Deux jours, c’est presque trop court ! Nous revenons avec des idées plein la tête, une vision transformée, et une féroce envie d’aller aux Paris devops !

Annexes

Les slides des ignites talks dont nous n’avons pas parlé, mais dont le format est parfait !

Pour le moment, peu de ressources sont disponibles, nous essayerons de maintenir la liste à jour !

Share
Categories: J'y étais ! Tags: ,
  1. Pas encore de commentaire
  1. 28/04/2014 à 17:44 | #1
  2. 13/03/2015 à 09:20 | #2