Devopsdays Paris, Jour 1

Zenika était présent (et partenaire) les 14 et 15 avril aux DevopsDays (twitter) à Paris au MAS.
Côté organisation, une salle de présentation pour accueillir les différentes keynotes. Il y avait également un village partenaire avec notamment : Normation (Rudder), Puppet Labs, OpsCode (Chef), IBM, Microsoft, Xebia Labs… Le matin des conférences entrecoupées de petits pitchs de 90 secondes des partenaires de l’événement. L’après midi commence avec des « Ignites », ce sont des talks de 5 minutes avec défilement automatique des slides. Puis viennent les « open space« , lieux de discussion et de partage permettant d’avoir plus de participation. Pour ces « open space », toute personne dans l’assemblée peut proposer un sujet via un post-it sur un tableau blanc. Chacun vient ensuite voter pour les sujets qui l’intéresse. Les sujets ayant reçu le plus de votes sont répartis pour discussion dans différentes salles.
Cet article tente de retracer au travers de flashbacks le déroulé de cette première journée de conférence. Toutefois il est possible que certains messages ne soient pas retranscrits fidèlement et pour cela nous nous excusons auprès des speakers, des poneys et des chats.

Keynotes

John Willis – Guns, Germs and Microservices

john-willis.png John Willis ouvre ces DevopsDays Paris avec un talk intitulé « Guns, Germs and Microservices ». Le titre est inspiré du livre « Guns, Germs and Steel« .
John a intégré récemment Docker Inc. suite au rachat par ce dernier de la société SocketPlane.
John commence par une analogie entre le secteur des technologies informatiques et la bataille de Cajamarca où les Conquistadors ont vaincu les Incas avec l’aide de quelques fusils, tuant plusieurs milliers de personnes. Il se demande pourquoi les Incas étaient si peu préparés à l’arrivée des Espagnols, et pourquoi les Espagnols étaient si bien préparés ? La réponse pour lui est simple : à cause de la « feedback loop » !!! Les Inca n’avaient pas de feedback loop assez courte sur la géographie, l’agriculture, la civilisation, les outils, ni entre chacun de ces aspects. John nous propose d’êtres les nouveaux conquistadors, sans le côté armes et génocide. Pour revenir à notre sujet, John nous explique que nous avons besoin d’aller vite et de pivoter rapidement et pour cela nous avons besoin d’avoir les bons outils et d’avoir un cycle de feedback court pour corriger le tir et s’aligner plus rapidement.
John revient ensuite sur le concept de Data Gravity exposé par Dave McCrory en 2010. Voici globalement ce que décrit le concept de Data Gravity : nous constatons que plus les données grossissent, plus elles attirent les applications autour d’elles leur offrant accélération (rapidité d’accès aux données, réduction d’utilisation de bande passante). Ces données que nous triturons via nos applications, nous les exposons en partie via des services. Cette exposition va, elle, réduire la vitesse de la donnée.
data-gravity.png
Avec l’IoT, la production de données s’accélère très très très rapidement, les données deviennent ainsi trop lourdes à déplacer. Il faut donc changer notre vision d’un monde où la donnée va au programme vers un monde où le programme va à la donnée.

« Moving from a world of Data to compute to moving compute to data ».

Tout comme James Bond pour qui le monde ne suffit pas, la donnée à elle seule ne suffit pas. En ajoutant un contexte et de la sémantique à la donnée nous obtenons de l’information. Grâce à nos précédentes boucle de feedback – à notre connaissance historique de l’information – l’information devient de la connaissance et à partir de cette connaissance nous sommes capable de prendre des actions. Ces actions vont apporter des informations en retour et ainsi nous amener à adapter notre position vis à vis de notre connaissance et donc de nos informations. Ainsi nous avons une boucle de feedback de la data représentée par le schéma ci-dessous.
data-feedback-loop.png
Ces boucles de feedback visent bien sûr à réduire le temps entre la production de données et les actions que nous allons prendre. John enchaîne avec Docker qui naturellement devient le conteneur des applications gravitant autour des données. John décrit les trois grands apports de Docker :

  • Un développement plus efficient : le développeur travaille désormais dans un environnement de production et voit son environnement démarrer dans la seconde.
  • Une intégration continue et un déploiement ou delivery continue facilités grâce notamment au layering avec le copy on write de Docker.
  • La traçabilité grâce au layering.

Pour terminer son talk John aborde rapidement les principes des microservices (il faut se concentrer sur le bounded context) et nous parle d’architecture immutable et pour ce dernier point il insiste vraiment – mais vraiment – pour que nous regardions la vidéo de Michael Bryzeck à la Docker Con de 2014.
Pour John Willis, le concept de Data gravity, Docker et les architectures Microservices sont le nouveau monde. Les nouveaux conquistadors seront ceux qui non seulement maîtriseront ces principes et outils mais vont accélérer leur convergence.
data-gravity-docker-microservice.png
C’est ici pour la vidéo du talk.

Steve Pereira – What happens without traction

steve-pereira.png
Dans le deuxième talk Steve Pereira nous questionne sur ce qu’est le Devops et quelle attitude adopter vis à vis de cette culture et nous donne quelques trucs et astuces pour la mettre en place, même sans le support du « board« . A travers ses expériences Steve nous parle de changement en opposition à la stabilité, de partage, de mesure et de ses « victoires faciles ».
Steve aborde d’abord ses premiers challenges chez Fed Ex où pour délivrer une modification en production il fallait une semaine qu’il a su réduire à deux jours. Sur un autre projet, il avait une fenêtre de 2 jours pour réaliser les merges et cela amenait évidemment son lot de problèmes. Dans un autre exemple Steve nous parle d’un build qui prenait deux jours (sic) qu’il a su réduire à 10 minutes. Une volonté d’industrialisation. Steve nous raconte qu’il a toujours essayé d’optimiser son travail et un jour il a levé la tête et a regardé autour de lui et n’a pas trouvé cela bien. Son cerveau industriel y a vu l’opportunité d’optimiser les organisations. Et c’est tout naturellement qu’il s’est tourné vers la culture Devops.
Pour Steve, il y a un changement de paradigm : «avant» – ou encore aujourd’hui – il fallait gravir les échelons pour avoir une meilleure vision du fonctionnement d’une organisation, aujourd’hui les outils changent la donne. Steve nous explique qu’il est difficile de démontrer qu’un changement marche, cela implique beaucoup de discussions et d’énergie. Pour nous aider à convaincre du bien fondé d’une transformation, il est bien sûr nécessaire de comprendre son environnement, le “Why” de l’organisation. Cela nous aide à savoir si l’organisation est prête pour ce changement.
Mais ce n’est pas parce que l’organisation souhaite changer qu’elle va y arriver; l’inertie, notamment dans les grandes organisations, est un des facteurs d’échecs. Pour cela Steve préconise d’identifier les leaders, les suiveurs et les sceptiques. Et quand nous arrivons à nous mettre en marche allons-nous dans la bonne direction? Il faut se coller à l’objectif de l’organisation et mettre en place les bonnes métriques pour mesurer notre avancement. La mise en place d’une culture Devops n’est pas une fin en soi et l’objectif de la mise en place d’une culture Devops doit entrer en résonance avec les objectifs de l’organisation.
Steve conclut sur le fait qu’il est important de se connaître avant d’essayer de convaincre les autres.

In DevOps nothing happens without sharing. — Steve Pereira

Vous pouvez retrouver les ressources du talk de Steve ici.

Boris Feld – The importance of Why in DevOps

boris-feld.png
Dans beaucoup de présentations, trop de monde se concentre sur le «How to do DevOps ?». Suis-je bien Devops? Mais peu mettent en avant une question plus importante : « Pourquoi faire du Devops ? ». Ne pas se poser la question du « Why ? » peut amener à du « Bad devops ».
Boris Feld a travaillé dans deux startups Parisiennes. Dans la première startup, ils ont mis en place une démarche Devops avec des résultats assez positifs. Pour Boris le Devops n’est pas obligatoire mais se demande tout de même pourquoi alors souhaiter faire du CAMS (Culture, Automatisation, Mesure and Sharing). Pour lui la réponse est simple ; parce que nous sommes des humains pardi ! Et qu’en tant qu’être humain nous adorons faire des erreurs. Mais qui, dans une entreprise saine d’esprit (oui, c’est vrai que l’entreprise est un peu un monde de fous), voudrait que des humains mettent leurs sales pattes sur les éléments les plus critiques ? En plus de vouloir sécuriser leurs éléments critiques, les entreprises saines d’esprit veulent aller vite et cela sans erreur. La réponse est simple : l’Automatisation. Voilà pour le A de cAms.
Vient alors la question de « Pourquoi automatiser ? ». Il y a plusieurs réponses : réduire le stress, passer moins de temps à faire des choses ennuyeuses et se concentrer sur ce qui nous fait vibrer..
Boris nous demande pourquoi nous souhaitons mesurer ? Et bien parce que l’on souhaite écouter, apprendre: avoir du feedback. Nous souhaitons passer moins de temps à chercher nos données et l’origine de nos problèmes. On veut que les données et les applications nous parlent.
Et puis on veut partager aussi, parce que quand nous aimons quelque chose nous aimons bien le partager (attention ! j’ai dit « quelque chose »). Il insiste également sur l’importance du partage en prenant exemple sur le problème de largeur des nouveaux train de la SNCF en 2014. Et le partage apporte aussi du feedback. Alors partageons tout, partageons nos outils, nos victoires et nos échecs pour construire notre Culture.
Pour ce talk je retiendrai beaucoup de choses notamment cette citation

Company culture is what happens when the boss is not around.

La conclusion de cette keynote complète sa premiere phrase : « Devops is not mandatory, but will be ».

Sabine Bernecker-Bendixen – Bizdevops

sabine-bernecker-bendixen.png
Sabine Bernecker-Bendixen est venue nous parler de respect, de diversité et de tolérance. Dans le Devops on parle souvent des deux tribus que sont les Dev et les Ops, c’est normal Devops est la contraction de ces deux termes. Mais nous oublions peut-être que le Devops implique beaucoup plus de populations d’individus. Sabine, elle, parle de “Bizdevops” où le Biz ce sont les utilisateurs, les clients, ceux qui paient les factures.
Il est important de savoir qu’il y a des différences entres ces populations ; elles ne parlent pas le même langage, elles n’ont pas le même point de vue, elles ne travaillent pas de la même façon, elles ne mangent peu être pas les mêmes choses. La communication est donc un axe important pour faire se rapprocher et se comprendre ces populations. Il faut traduire avec empathie, sans condescendance. Il faut surtout communiquer à un même niveau ; si je communique mes sentiments et qu’en face on me communique de la technologie, l’échange ne sera pas efficient.
Le milieu de l’entreprise nécessite d’adopter une communication adaptée et dans le contexte de transformation d’entreprise ou de culture d’entreprise de type Devops, où l’on sort de notre de zone de confort, il devient nécessaire d’avoir la bonne attitude ainsi que les bonnes personnes aux bons endroits.

BlaBlaCar REX avec Nicolas Blanc & Muriel Lusseau

muriel-lusseau.png
Chez blablacar, les devs sont des chats et les ops sont des poneys, j’imagine que ça ne doit pas sentir bon tous les jours chez eux… Une chose particulière chez Blablacar, c’est que les développeurs ont une très bonne connaissance du hardware et du système. Donc naturellement les devs sont des ops. Grace à cela ils sont capables de faire 10 déploiements par jour et par 10 personnes différentes et cela dans 10 positions différentes.
nicolas-blanc.png
Contrairement aux organisations régies par le « touche pas à ça ptit con », chez Blablacar, les devs ont le droit de faire les mises en production puisqu’ils savent faire des installations, faire des rollbacks ou patcher une installation. Ils ont aussi montré leur maîtrise des tests (3600 tests après un commit pour la principale application) et par contagion positive cela a donné des idées aux Ops qui testent leur infrastructure. Les devs et les ops ont maintenant un outil commun qui est Opscode Chef. L’organisation du delivery a changé au gré des besoins et du contexte. Au départ l’équipe, petite, était managée par une seule personne et utilisait Scrum. Mais avec l’agrandissement des équipes, les dailys meeting devenait trop longs. L’équipe a donc été coupée en deux. Il était cependant difficile d’avoir les experts de la donnée, du métier, des ops et des devs en même temps. Une équipe s’est donc réorganisée en Product team (la Team Pink). Scrum ne leur permettait pas d’avoir le niveau de partage suffisant de l’avancement de chacun. La Team Pink a donc mis en place Kanban.
Aujourd’hui les feature team utilisent Kanban et les équipes plus « pérennes » utilisent Scrum.
Chez Blabalcar la communication, le partage et la culture sont importants et à ce titre ils organisent

  • des événements de Team building
  • des apéros une fois par semaine pour toute l’entreprise
  • des Weekly free speech ; lieu de partage sur les technologies

Les next steps chez Blablacar seraient d’avoir

  • un Ops dans chaque équipe
  • plus de feature teams

Ignites

Pour reprendre en douceur l’après midi, après un superbe buffet, on nous propose des Ignites. Ce sont ces petites sessions de 5 minutes environ où vos slides défilent tout seuls. Et pour les speaker il faut tenir le rythme. Ces ignites sont ouverts à tous.
Parmis les Ignites j’ai retenus Nicolas Charles (Twitter) de Normation qui édite Rudder. Nicolas nous a fait une superbe analogie entre la dance et le monde de la production logicielle. Andy Burgin (https://twitter.com/andyburgin) est revenu sur les différentes étapes pour créer une communauté et a insisté sur la facilité à invité des rockstars de l’informatique. Andy a lancé le Leeds DevOps.

Open Spaces

Les sessions des Open Space étaient répaties dans 4 salles. Chaque sujet pouvait être discuté pendant 30 minutes dans ces salles. Voici les sujets
De 16h10 à 16h40

  • Devops in
    large organisations
  • Monitoring as Code
  • Docker 101
  • How to explain to management and customers why Devops is awesome

De 16h40 à 17h10

  • Why Ansible or Chef or Puppet…
  • Code Review
  • Leaders expected attitude in a devops journey
  • How to make test automation reliable, reusable, robust and costless

De 17h10 à 17h40

  • Micro services a support nightmare
  • Immutable Infrastructure
  • How to set up an automated deployment pipeline on a legacy process
  • Value stream mapping, how ?

Organisateurs & Sponsors

Merci aux organisateurs et aux sponsors : http://www.devopsdays.org/events/2015-paris/

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

%d blogueurs aiment cette page :