Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activités liées au développement d’applications informatiques en entreprise.

Agrégateur de flux

#InsideIppon – Speakers au Devoxx France 2017

Blog d’Ippon Technologies - il y a 21 heures 25 min

Florian Garcia et JĂ©rĂ©mie Monsinjon ont acceptĂ© d’ĂŞtre suivis pendant leur première participation au Devoxx France, en tant que speaker. Ils vous expliquent comment ils ont prĂ©parĂ© ce challenge.

Si vous souhaitez aussi parler de votre expertise dans les plus grandes conférences, nous offrons de nombreuses opportunités et challenges :

Email

Ceci est requis. Ville

Ceci est requis. Envoyer



L’article #InsideIppon – Speakers au Devoxx France 2017 est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Software Testing Trends in France

Le blog de Valiantys - ven, 04/28/2017 - 07:29

Editor’s note: The study “Observations in Software Testing“, originally written in French, was presented at the JFTL 2017 conference, a French event gathering the country’s testing professionals. The study collected responses from more than 600 testing professionals and compared it to their results in 2013.  This is what we found out – and present here to ...

The post Software Testing Trends in France appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

[Session Mensuelle] Innovation Games

Agile Nantes - ven, 04/28/2017 - 07:29
Parce que l’on a pas assez jouĂ© Ă  l’Agile Games Night
Catégories: Association

Rejoignez le 4e meetup « StartMeUp » le 9 Mai

OCTO Technology & le meetup « Start Me Up »

Pour partager sur le dĂ©veloppement de l’innovation au sein des grandes organisations publiques ou privĂ©es, OCTO Technology oragnise un meetup « Start Me Up », c’est par ici : Meetup – Start Me Up

stup1

Ce groupe s’adresse Ă  tous ceux qui sont intĂ©ressĂ©s par le corporate intrapreneuriat et l’innovation. Tous les niveaux de connaissance et d’acculturation sont les bienvenus. Rejoignez-nous pour dĂ©couvrir des pratiques intrapreneuriales, des dĂ©marches de conceptions innovantes et surtout partager des retours d’expĂ©riences, Ă©chec ou succès, issus du monde corporate.

Quatrième session le 9 Mai à 19h

POUR DES RAISONS DE SECURITE PENSEZ BIEN A VOUS INSCRIRE A L’EVENEMENT VIA MEETUP, CAR NOUS DEVONS FOURNIR UNE LISTE DES PERSONNES INSCRITES A L’ACCUEIL.

Nous aurons le plaisir de partager un retour d’expĂ©rience Ismael Hery coach d’intrapreneurs, qui conseille des Ă©quipes multidisciplinaires dans leur construction de produits digitaux. Ce retour d’expĂ©rience sera suivi d’une sĂ©ance de co-dĂ©v entre participants.

Cette session nous permettra ensemble de lancer cette nouvelle formule qui Ă©quilibre retour d’expĂ©rience et partage entre participants.

Tout cela se fera dans une ambiance dĂ©contractĂ©e autout d’un Octo’ApĂ©ro !

!!!! ATTENTION : Nous avons demmĂ©nagĂ©, dĂ©sormais vous pouvez nous retrouver au 34 Avenue de l’OpĂ©ra, 75002 PARIS

 

 

Catégories: Blog Société

Retour sur la conférence NodeConf Barcelone 2017

Le vendredi 7 avril a eu lieu la confĂ©rence NodeConf Ă  Barcelone en prĂ©sence de cinq membres clĂ©s de l’Ă©quipe Node.js (James Snell, William Kapke, Myles Borins, Anna Henningsen et Bryan English). Ont eu lieu le lendemain des workshops portant sur diffĂ©rents sujets tels que la conteneurisation, les ChatBots et l’artisanat logiciel, sujets autour desquels […]
Catégories: Blog Société

Hackathon API Kiabi : 1er et 2 juin 2017

Illustration de TonuNous accompagnons Kiabi dans l’organisation de son premier hackathon autour de ses API. Celles-ci sont mises Ă  disposition pour crĂ©er des applications digitales (tablettes, smartphones…) inspirantes pour contribuer Ă  son ambition de surprendre et d’enchanter ses clients.

Offrir des Open API est le stade ultime de digitalisation de son système d’information.

Comment Kiabi en est-arrivé là ?

Remontons le temps et arrĂŞtons-nous en 2014 :

  • 06/2014 : Petit dĂ©jeuner : Nouvelles sources d’inspiration architecturales Ă  Lille, nous abordons la dĂ©marche API First et les nouvelles architectures Web.
  • 12/2014 : Notre accompagnement de Kiabi sur la dĂ©finition de sa stratĂ©gie API : de l’Ă©vangĂ©lisation des Ă©quipes Kiabi Ă  la pose des premières pratiques architecturales : design d’API et API Management.
  • 11/2015 : Notre accompagnement de Kiabi pour faire un bilan sur sa dĂ©marche d’APIsation de son SI : les premières API REST et la mise en Ĺ“uvre d’une solution d’API Management.
  • 06/2017 : Notre accompagnement de Kiabi pour l’organisation de son premier hackathon de dĂ©veloppement d’applications utilisant ses API.

Kiabi a Ă©tĂ© un de nos clients prĂ©curseurs dans l’appropriation d’une dĂ©marche d’APIsation de son SI. Il est important de trouver le bon Ă©quilibre entre l’enjeu business (des API pour qui ou pour quoi ?) et technologique (des API REST managĂ©es).

Kiabi nous a fait confiance et nous a sollicitĂ© en tant que Ă©vangĂ©lisateur / coach pour faciliter la prise en main et l’autonomisation de ses Ă©quipes autour de ses concepts et technologies d’API.

Nous vous invitons Ă  venir nous rejoindre lors de ce hackathon parce que :

« nous savons que les rĂ©alisation marquantes sont le fruit du partage des savoirs et du plaisir Ă  travailler ensemble. »

Suivez l’Ă©quipe du Hackathon sur le fil Twitter.

Catégories: Blog Société

Revue de Presse Xebia

Revue de presse de Xebia
La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Craftsmanship Contrainte comportementale dans la processus du développement logiciel http://www.gravatar.com/avatar/3116a6125a198354e29f97a027332e41http://blog.xebia.fr/author/ponnebyhttp://twitter.com/poennebyhttp://github.com/poennebyPar Peter Onneby

Lihsuan Lung de 8th light, fait un lien intĂ©ressant avec la contrainte comportementale ou « Forcing Function » et le processus du dĂ©veloppement logiciel dans son article.

Afin d’affronter le risque des erreurs humaines sur la complexitĂ©, diversitĂ© et la multitude de nos systèmes et outils d’aujourd’hui nous pourrions crĂ©er des check-lists.

Comme les chirurgiens ou les pilotes d’avion nous sommes des experts susceptible d’erreurs humaines – le processus du TDD pourrais nous aider de les Ă©viter.

DevOps Les namespaces manquants selon Jessie Frazelle http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Jessie Frazelle vient de publier un article présentant les 2 principaux namespaces manquants sur Linux selon elle.

Actuellement, les namespaces Linux sont au nombre de 7 :

  • MNT : Mount
  • PID : Process ID
  • NET : Network
  • IPC Interprocess Communication
  • UTS : Hostname
  • User : User ID
  • CGroup : Control Groups pour la limitation de ressources

Comme l’Ă©voque Jessie, les Time namespaces seraient les bienvenus notamment pour permettre des « reproducible builds », souvent Ă©voquĂ©s par les mainteneurs de packages de distributions Linux lorsqu’un package embarque avec lui la date et l’heure Ă  laquelle il a Ă©té  construit, le rendant ainsi très difficile Ă  reproduire sans ce Time namespace. Elle exprime Ă©galement son dĂ©sir de voir arriver un namespace pour le kernel keyring, utilisĂ© pour stocker et/ou mettre en cache des Ă©lĂ©ments sensibles, typiquement des clĂ©s de chiffrement ou d’authentification. Comme elle le rappelle très bien, ces Ă©lĂ©ments (time et kerkel keyring) n’Ă©tant pour l’instant pas isolĂ©s, les seccomp Docker de base empĂŞchent toute modification les concernant. Bien qu’elle ne le mentionne pas, un syslog namespace est Ă©galement Ă©voquĂ© depuis plusieurs annĂ©es, mais n’a pour l’instant pas Ă©tĂ© intĂ©grĂ© au kernel Linux officiellement.

DĂ©sormais très connue suite Ă  ses nombreuses contributions au monde des conteneurs en tant qu’employĂ©e de Docker, puis Mesosphere et dĂ©sormais Google, peut-ĂŞtre est-ce Jessie qui finira par implĂ©menter les namespaces en question et les contribuer au kernel Linux ? Après tout, les premiers Ă©lĂ©ments des conteneurs sur Linux ont pour la plupart Ă©tĂ© contribuĂ©s par des employĂ©s de Google pour leurs propres besoins !

Pour rappel, Jessie Frazelle sera présente en tant que speaker au Paris Container Day le 13 juin prochain.

Functions as a Service avec Docker… ou plutĂ´t Moby http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Suite Ă  la DockerCon, de nombreux articles relatant les diffĂ©rentes prĂ©sentations commencent Ă  ĂŞtre publiĂ©s. C’est notamment le cas de l’article « Moby’s Cool Hack sessions » publiĂ© sur le blog de Docker, prĂ©sentant notamment comment Alex Ellis s’est servi de Docker Moby et du mode Swarm pour crĂ©er des « Function as a Service », le terme dĂ©signant dĂ©sormais les exĂ©cutions de fonction Ă  la demande comme par exemple AWS lambda.

Cette prĂ©sentation prĂ©cède de peu celle de Clay Smith (New Relic) Ă  la dotScale 2017 qui y expliquait comment il avait « introspectĂ© » les lambdas d’AWS pour mieux comprendre comment celles-ci Ă©taient  lancĂ©es par Amazon.

Releases : Ansible et Gitlab http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Comme le mois dernier, voici un résumé des principales releases intéressantes ayant eu lieu ce mois-ci :

  • Ansible ont enfin publiĂ© leur version 2.3 : attendue depuis de nombreux mois, cette release inclut de nombreuses corrections de bugs mais Ă©galement de nouveaux modules très orientĂ©s cloud et appels d’APIs plutĂ´t que gestion de configuration pure. On notera Ă©galement un fort accent sur la gestion de systèmes Windows.
  • Gitlab 9.0 puis 9.1 sont sortis : 1 an et demi après la version 8.0 qui ouvrait la page de la gestion de l’intĂ©gralitĂ© du cycle de vie d’un projet par Gitlab, cette nouvelle version majeure sonne le dĂ©but de l’extension vers la gestion du dĂ©ploiement des applications. Au programme : intĂ©gration avec Prometheus pour embarquer le monitoring des applications dĂ©ployĂ©es sur Kubernetes, nouvelle version de l’API, amĂ©liorations de performance et de la navigation, et bien d’autres encore. La version 9.1 emboĂ®te d’ores et dĂ©jĂ  le pas de la 9.0, avec des amĂ©liorations notables sur l’interface de l’intĂ©gration de Prometheus, sur les pipeline de dĂ©ploiement de manière gĂ©nĂ©rale, ainsi que sur bon nombre de petits dĂ©tails pratiques dont pourront profiter les utilisateurs au quotidien.
Catégories: Blog Société

Meetup le 02 Mai : Construire le futur avec Google Cloud Platform

A Duchess Community Blog for France - jeu, 04/27/2017 - 12:55

Vous avez assisté (ou pas !) à nos sessions consacrées au Cloud ? Ne ratez pas notre 3ème meetup de la série qui aura lieu le 2 Mai sur GCP : Google Cloud Platform.

Cette soirĂ©e s’adresse à tous les profils de dĂ©veloppeurs, toutes technos et langages confondus, qu’ils soient dĂ©butants ou familiers avec le dĂ©veloppement Cloud et sera l’occasion de voir, d’entendre et de rencontrer trois personnes de chez Google :

–  CĂ©line Heller – France Google Cloud Partner Manager

–  AurĂ©lie Coelho et Lucie Vannier – Pre-Sales Engineer chez Google Cloud.

–  et Bastien Legras, Head of …

Cet article Meetup le 02 Mai : Construire le futur avec Google Cloud Platform est apparu en premier sur Duchess France.

Catégories: Association

Ippon accueille le Meetup LadiesOfCode – Data et traitement d’images

Blog d’Ippon Technologies - jeu, 04/27/2017 - 10:35
Le 3 mai, à partir de 19h00, Ippon accueille le LadiesOfCode pour une soirée tournée vers la Data et le traitement des images.

DĂ©veloppĂ© par Eventbrite Talk 1 : La programmation rĂ©active est une abstraction qui permet de considĂ©rer un traitement de donnĂ©es comme un flux asynchrone traitĂ© dans un pipeline. C’est un paradigme diffĂ©rent qui peut ĂŞtre appliquĂ© dans plusieurs contextes. Le traitement d’images peut ĂŞtre vu comme un ensemble de transformations appliquĂ©es Ă  une source de donnĂ©es. C’est donc un exemple parfait pour la construction d’un pipeline rĂ©active. Lors de cette talk je vais aborder des concepts basiques sur le traitement d’images numĂ©riques et je vais vous montrer comment intĂ©grer un flux d’images en provenance d’un raspberry pi et une camera local dans un pipeline rĂ©actif en partant d’un exemple rĂ©el d’utilisation. Speaker : Diana Ortega, ingĂ©nieur back chez Xebia France, j’ai un master 2 en Ă©lectronique mention traitement d’images et signaux de l’universitĂ© Claude Bernard lyon. Je suis passionnĂ©e de la jvm, de Go et de Craftmanship. Je m’intĂ©resse aussi Ă  la data et aux problèmes de concurrence. Talk 2 : Ingestion de donnĂ©es dans un datalake avec Sqoop et Oozie (deux outils de l’Ă©cosystème Hadoop) Depuis quelques temps, une nouvelle forme de stockage de donnĂ©es est apparue sous le nom de “DataLake” ou “Lac de donnĂ©es” : Un rĂ©fĂ©rentiel de stockage qui conserve une grande quantitĂ© de donnĂ©es dont on ne connaĂ®t pas a priori les structures analytiques contrairement aux entrepĂ´ts de donnĂ©es. Dans cette prĂ©sentation, je vous propose de dĂ©couvrir comment crĂ©er une chaĂ®ne d’ingestion de donnĂ©es entre une base de donnĂ©es relationnelle et un datalake en utilisant deux outils de l’Ă©cosystème Hadoop Sqoop et Oozie : – Sqoop est un outil conçu pour transfĂ©rer des donnĂ©es entre un cluster Hadoop et une base de donnĂ©es relationnelle.

– Oozie est une solution de workflow (au sens scheduler d’exploitation) utilisĂ©e pour gĂ©rer et coordonner les tâches de traitement de donnĂ©es Ă  destination de Hadoop.

Speaker : Je suis Rim BenKhalifa, ingĂ©nieur Data avec 4 ans d’expĂ©rience diplĂ´mĂ©e de l’universitĂ© Paris Sud. J’ai 4 ans d’expĂ©rience en Data dont un peu moins de 2 ans chez Ippon Technologies. Je travaille sur des missions très variĂ©es et innovantes autour de la Data, allant de l’ingestion de donnĂ©es Ă  l’industrialisation de modèles data science.

Mes sujets prĂ©fĂ©rĂ©s sont : Spark, l’Ă©cosystème Hadoop et les algorithmes de machine learning.

Après les confĂ©rences, direction le Rooftop Work pour Ă©changer avec les speakers autour d’un buffet. SoirĂ©e rĂ©servĂ©e aux Ladies 🙂

L’article Ippon accueille le Meetup LadiesOfCode – Data et traitement d’images est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Enfin une formation dédiée à l’écosystème des conteneurs sur Paris

Xebia Training est fière de prĂ©senter sa nouvelle formation dĂ©diĂ©e Ă  l’Ă©cosystème des Conteneurs et de Docker, initiĂ©e par deux Xebians, Alexis « Horgix » Chotard et Julien Bonachera.

Regardons de plus près cette initiative et ce que cette formation peut vous apporter avec l’un des formateurs.

 

Ă€ l’occasion du Paris Container Day, confĂ©rence dĂ©diĂ©e Ă  l’Ă©cosystème des conteneurs qui aura lieu le 13 prochain, Xebia Training vous fait gagner cette formation. Vous pouvez participer au jeu concours en rĂ©pondant Ă  ce quiz.  Alexis, peux-tu nous en dire un peu plus sur toi ?

Bien sĂ»r ! Je suis ce qu’on pourrait qualifier d’un DevOps.

D’une formation plutĂ´t orientĂ©e dĂ©veloppement et d’expĂ©rience davantage tournĂ©e système et infrastructure, je me plais Ă  travailler sur des sujets variĂ©s tels que l’intĂ©gration continue, le dĂ©ploiement continu ou encore la conception d’architectures dynamiques et l’intĂ©gration des applications dans celles-ci ; sujets sur lesquels les conteneurs peuvent jouer un rĂ´le de premier plan.

Cette bicéphalité développement/opérations implique également des facteurs humains importants :

  • AmĂ©liorer la communication Devs/Ops afin de fluidifier les livraisons,
  • ÉvangĂ©liser les bonnes pratiques auprès des dĂ©veloppeurs,
  • Fournir Ă  ces derniers l’infrastructure et les outils nĂ©cessaires,
  • Etc.

Au final, cette nĂ©cessitĂ© de compĂ©tences vraiment diversifiĂ©es me passionne et ne laisse pas de place au rĂ©pit et Ă  l’ennui.  Meetups, confĂ©rences, discussions informelles, XKE (journĂ©e de partage) chez Xebia, tout est un bon prĂ©texte pour discuter, Ă©changer et partager autour de sujets DevOps.

C’est donc suite Ă  ce constat que l’idĂ©e de crĂ©er une formation conteneurs a Ă©tĂ© initiĂ©e.

Comment avez-vous eu l’idĂ©e de crĂ©er une formation sur les conteneurs ?

C’est simple : tout le monde en parle, mais très peu en font vraiment !

Les conteneurs répondent au final aux mêmes problématiques que les machines virtuelles (excepté peut-être le multi-OS) mais en étant plus rapides à démarrer tout en étant plus légers ; ces avantages supplémentaires leurs confèrent une place de premier choix dans des infrastructures qui tendent à être toujours plus dynamiques et hétérogènes.

Une « formation Docker« , « formation LXC » ou encore « formation rkt » ne couvrirait que la partie emergĂ©e de l’iceberg : comprendre ce que sont vraiment les conteneurs sur Linux permet d’avoir une vision plus Ă©clairĂ©e de l’Ă©cosystème et surtout de ne pas se retrouver dĂ©semparĂ© le jour oĂą le gestionnaire de conteneurs « Ă  la mode » changera.

Au final, les conteneurs offrent des conceptions d’architecture vraiment très intĂ©ressantes et des rĂ©ponses Ă  des problĂ©matiques rĂ©elles en permettant de simplifier d’avantage les Ă©tapes Ă  faible valeur ajoutĂ©e, ce qui en fait un sujet sur lequel il devient de plus en plus pertinent d’ĂŞtre formĂ© !

Plus concrètement, quels seront les sujets abordés durant la formation conteneurs et Docker ?

Cette formation de 4 jours commence par une partie de théorie sur les conteneurs : que sont-ils vraiment ? Pourquoi ont-ils été créés ? Quels en sont les usages ?

Suite Ă  cette partie globale sur les conteneurs, Docker sera abordĂ©, tout d’abord d’un point de vue basique (comment crĂ©er un conteneur Docker et le gĂ©rer), puis d’un point de vue plus avancĂ© et rĂ©ellement concret (applications multi-conteneurs, gestion du rĂ©seau, du placement des donnĂ©es, etc.). Pour finir, la formation couvrira les nouvelles problĂ©matiques mises sur le devant de la scène avec les conteneurs et les environnements dynamiques, temporaires et hautement distribuĂ©s : orchestration, microservices, etc. Bien Ă©videmment, tous ces sujets ne sont pas uniquement traitĂ©s de manière thĂ©orique : chaque demi-journĂ©e a son lot de « hands-on » avec des mises en pratique concrètes : rien ne vaut l’expĂ©rimentation par soi-mĂŞme ! Ces travaux pratiques seront encadrĂ©s afin que chacun puisse trouver les rĂ©ponses Ă  ses questions. Pour plus de dĂ©tails, je vous invite Ă  regarder le plan de la formation qui est expliquĂ© point par point sur le site de Xebia Training : http://training.xebia.fr/formation/formation-conteneurs-docker/ Y a-t-il des prĂ©requis pour s’inscrire ?

Les conteneurs sur Linux reposant sur les cgroups et les namespaces, au coeur du kernel Linux, il est nĂ©cessaire d’avoir de bonnes bases sur Linux afin de comprendre ces notions.
La quasi totalité des parties pratiques (50% de la formation environ) se déroulant en ligne de commande, il est donc là encore vivement conseillé de travailler régulièrement sur des environnements Linux afin de ne pas être ralenti.

Cette formation s’adressant Ă  la fois aux Administrateurs Système et aux DĂ©veloppeurs, chacun y trouvera son compte avec ses connaissances, mais certains points parleront forcĂ©ment plus aux concernĂ©s : construction d’images applicatives pour les dĂ©veloppeurs, partie rĂ©seau pour les administrateurs système, etc.

Pour rappel ou information, voici le public visé par cette formation :

  • DĂ©veloppeurs s’intĂ©ressant Ă  la livraison de leurs applications,
  • IngĂ©nieurs système, ingĂ©nieurs de production et administrateurs souhaitant moderniser leur infrastructure,
  • Toutes les personnes s’intĂ©ressant aux problĂ©matiques de DĂ©ploiement Continu (Continuous Delivery) et aux bĂ©nĂ©fices que les conteneurs peuvent y apporter et souhaitant mettre en pratique le cĂ´tĂ© technique.

jeu concours formation conteneurs et docker

Catégories: Blog Société

Agile smells – Backlog et user stories

agile_smells

Suite de la sĂ©rie d’articles consacrĂ©e aux Agile smells, je vous propose, au travers de situations rĂ©ellement vĂ©cues, de faire un tour d’horizon des dĂ©rives, des fausses bonnes idĂ©es ou simplement des phrases prononcĂ©es qui peuvent vous amener Ă  vous dire que quelque chose sent mauvais. Aujourd’hui, parlons du backlog et des user stories…

Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :

Les éléments du backlog sont des user stories priorisées, détaillées et estimées pour les 12 prochaines itérations La situation

Les users stories dĂ©finies dans le backlog de l’Ă©quipe ont toutes Ă©tĂ© revues lors de rĂ©unions d’affinage. Elles ont des critères d’acceptation, des exemples associĂ©s, une première analyse technique et des estimations, ce qui signifie qu’en l’Ă©tat, elles pourraient ĂŞtre dĂ©veloppĂ©es Ă  n’importe quel moment.

Au total, en comptant des itĂ©rations d’une durĂ©e de deux semaines, le backlog est donc entièrement dĂ©taillĂ© pour les six prochains mois.

Pourquoi ça sent mauvais ?

La vie d’un produit est souvent faite de remous, et le contexte (besoins utilisateur, budget, etc.) qui avait permis l’Ă©mergence des premières idĂ©es peut ĂŞtre amenĂ© Ă  changer de manière plus ou moins radicale. Deux cas de figure se prĂ©sentent alors :

  • Le suivi du plan initial

Le risque principal est un rĂ©flexe naturel consistant à s’accrocher contre vents et marĂ©es au planning initialement dĂ©fini. En effet, une feuille de route ayant Ă©tĂ© Ă©tablie via un Ă©norme travail, les personnes concernĂ©es auront tendance Ă  suivre aveuglement ce plan pour justifier le temps passĂ© dessus, plutĂ´t que de profiter des opportunitĂ©s de changement. Le produit s’Ă©loigne alors des rĂ©els besoins des utilisateurs, rĂ©duisant ainsi son intĂ©rĂŞt.

  • Le pivot

Un choix plus raisonnable est de pivoter Ă  un moment donnĂ© afin de prendre une direction plus en adĂ©quation avec les nouveaux besoins qui ont Ă©mergĂ©. La consĂ©quence directe est alors de devoir dĂ©prioriser une bonne partie des user stories, et donc perdre de nombreuses heures de travail passĂ©es sur de l’analyse et de l’Ă©criture.

Dans tous les cas, du temps, et donc de l’argent, ont Ă©tĂ© passĂ©s sur des hypothèses n’aboutissant finalement Ă  rien, plutĂ´t que sur des dĂ©veloppements de fonctionnalitĂ©s immĂ©diatement livrĂ©es.

Enfin, au-delĂ  du travail centrĂ© sur les besoins utilisateur et les possibles pivots, un backlog composĂ© d’Ă©lĂ©ments dĂ©taillĂ©s sur une si grande pĂ©riode de temps, se construit au travers d’un gros effort d’affinage, et donc d’analyse technique. Or, de la mĂŞme manière qu’un besoin utilisateur peut Ă©voluer, une architecture technique qui Ă©tait justifiĂ©e Ă  un instant t peut se rĂ©vĂ©ler ĂŞtre obsolète quelques mois plus tard. En effet, l’architecture d’un projet agile est en perpĂ©tuelle Ă©volution par le fait qu’elle Ă©merge Ă  chaque itĂ©ration. Les nombreuses heures de travail passĂ©es sur de l’analyse technique seront donc elles aussi perdues.

Concrètement on fait quoi ?

Une mĂ©thode simple et efficace pour la tenue d’un Product Backlog est reprĂ©sentĂ©e par le schĂ©ma suivant :

backlog iceberg

Cette pyramide, également appelée Product Backlog Iceberg, se découpe en trois parties :

  • L’essentiel des grandes fonctionnalitĂ©s qui servent Ă  construire la roadmap du produit sont reprĂ©sentĂ©es par des Epics. GĂ©nĂ©ralement elles sont issues des premières discussions avec les utilisateurs finaux et ne sont pas forcĂ©ment encore validĂ©es ni analysĂ©es.
  • Lorsqu’une ou plusieurs Epics sont priorisĂ©es pour ĂŞtre dans la prochaine release, elles vont ĂŞtre affinĂ©es avec l’aide des utilisateurs pour le dĂ©coupage en Features, qui vont faire l’objet d’une première analyse technique. L’idĂ©e de cette analyse est surtout de voir rapidement la faisabilitĂ© technique, et dans des cas plus rares, de rĂ©aliser des prototypes.
  • Les Features les plus prioritaires de la release seront de nouveau dĂ©coupĂ©es en user stories respectant le principe INVEST pour les deux ou trois prochaines itĂ©rations. L’idĂ©e ici Ă©tant d’avoir un stock de user stories prĂŞtes Ă  ĂŞtre intĂ©grĂ©es Ă  n’importe quel moment.

Autrement dit, plus on s’Ă©loigne dans le temps, moins le niveau de dĂ©tails est important. On pourrait faire un parallèle avec un mantra issu de l’Extreme Programming : YAGNI (You Aren’t Gonna Need It), qui se rĂ©sume Ă  ne pas faire quelque chose qui ne serait utile que dans un hypothĂ©tique futur.

« Alors aujourd’hui j’ai seulement deux stories Ă  vous prĂ©senter » La situation

Une Ă©quipe de trois dĂ©veloppeurs s’engagent sur le pĂ©rimètre d’une itĂ©ration ne comportant que deux user stories.

Pourquoi ça sent mauvais ?

Chaque itĂ©ration comporte son lot de surprises : un bug de production urgent Ă  corriger, un impact non anticipĂ© ou encore une absence non prĂ©vue, qui sont autant de chances de ne pas rĂ©ussir Ă  terminer une user story avant la fin de l’itĂ©ration. Le problème en ne s’engageant que sur deux grosses user stories, est que si une story n’est pas terminĂ©e, c’est la moitiĂ© de l’itĂ©ration qui n’est pas terminĂ©e.

Les conséquences sont diverses :

  • La vĂ©locitĂ© de l’Ă©quipe est complexe Ă  estimer : des user stories Ă©tant rĂ©gulièrement reportĂ©es d’une itĂ©ration Ă  l’autre, l’Ă©quipe a une vĂ©locitĂ© en dents de scie, ce qui rend difficile d’Ă©tablir une quelconque prĂ©vision pour un plan de release par exemple.
  • L’Ă©quipe essuie rĂ©gulièrement des Ă©checs : ne pas rĂ©ussir Ă  tenir ses engagements de manière rĂ©gulière peut s’avĂ©rer ĂŞtre une source de dĂ©motivation pour les membres de l’Ă©quipe.

Cette situation est parfois jumelĂ©e Ă  une autre situation qui aurait pu faire l’objet d’un smell Ă  part entière : lorsqu’en Sprint Planning, quelqu’un rĂ©pond Ă  une remarque sur la taille de la story de la manière suivante : « Ce n’est pas grave si on ne la termine pas lĂ , elle sera finie l’itĂ©ration prochaine. L’important c’est juste qu’elle soit finie au bout du compte. ».

Concrètement on fait quoi ?

Tout simplement, lisez l’article Ă©crit par Meriem El Aaboudi et FrĂ©dĂ©ric Courdier. Si vous manquez de courage pour cliquer sur le lien, voici un très court rĂ©sumĂ© des avantages de dĂ©couper en petites user stories :

  • RĂ©duire le temps de cycle : une story plus petite sera sujette Ă  un feedback plus rapidement car elle sera terminĂ©e plus tĂ´t.
  • Faciliter l’adaptation au changement : si un moindre imprĂ©vu survient, plus la story sera petite, moins l’impact sera important.
  • RĂ©duire l’incertitude et le risque : estimer la complexitĂ© d’un petit pĂ©rimètre (par exemple la crĂ©ation d’un formulaire d’identification) est toujours plus simple que d’estimer la complexitĂ© d’une grosse fonctionnalitĂ© (comme la mise en place de toute la partie sĂ©curitĂ© d’un site).
  • Satisfaire l’Ă©quipe rĂ©gulièrement : chaque user story terminĂ©e est une petite victoire, et chaque victoire apporte une dose de satisfaction personnelle. Neuf victoires sur dix, valent donc mieux qu’une sur deux.

L’article termine par un extrait de la règle six de la Scrum Master Academy qu’il est important d’avoir en tĂŞte : « Il faut pouvoir prendre plus de 4 user stories par sprint ». IdĂ©alement, il faudrait mĂŞme « qu’un dĂ©veloppeur puisse travailler sur plus d’une story pendant le sprint » pour limiter le risque de report Ă  l’itĂ©ration suivante.

Enfin, l’article met Ă  disposition des liens très utiles vers des techniques de dĂ©coupage de user story (oui vous allez finalement ĂŞtre obligĂ© de cliquer sur le lien).

« T’as lu les critères d’acceptation ? » – « Euh pas vraiment… Ils sont oĂą dĂ©jĂ  ? » La situation

Un dĂ©veloppeur appelle le Product Owner pour valider une user story qu’il considère implĂ©mentĂ©e. Le Product Owner s’aperçoit rapidement que certaines fonctionnalitĂ©s ne rĂ©pondent pas aux besoins qu’il avait exprimĂ©. En rĂ©alitĂ©, les critères d’acceptation n’ont pas Ă©tĂ© entièrement respectĂ©s et aucun test associĂ© n’a Ă©tĂ© rĂ©alisĂ©.

Pourquoi ça sent mauvais ?

Cette situation est symptomatique d’un fonctionnement d’Ă©quipe qui n’est pas clairement dĂ©fini : chaque membre de l’Ă©quipe va avoir sa vision de la manière dont doit se dĂ©rouler le dĂ©veloppement d’une user story, ainsi que ce qui va dĂ©finir que celle-ci est prĂŞte Ă  ĂŞtre envoyĂ©e en production.

dod

Lorsqu’un dĂ©veloppeur, pensant de manière sincère avoir terminĂ© ses dĂ©veloppements, prĂ©sente le fruit de son travail Ă  un Product Owner qui s’attend Ă  un autre rĂ©sultat, cela va engendrer une dĂ©ception plus ou moins importante. Si l’on ajoute Ă  cela, les quelques allers-retours qu’il y aura avant que la fonctionnalitĂ© ne soit considĂ©rĂ©e comme bonne, la vision du Product Owner sur l’Ă©quipe de dĂ©veloppement va se retrouver Ă©cornĂ©e et une perte de confiance va progressivement s’installer.

Ă€ partir du moment oĂą le Product Owner perd confiance dans la qualitĂ© du travail fourni par l’Ă©quipe, il va devenir mĂ©fiant et cela se fera ressentir fortement par l’Ă©quipe avec un Product Owner qui aura tendance Ă  surveiller d’un peu trop près le dĂ©roulement des dĂ©veloppements.

L’exemple entre un Product Owner et un dĂ©veloppeur peut s’appliquer de la mĂŞme manière directement entre dĂ©veloppeurs sur divers sujets, que ce soit sur les tests ou sur la qualitĂ© du code. Dans tous les cas, perte de confiance et mĂ©fiance s’installeront au quotidien, crĂ©ant ainsi une ambiance peu propice au travail d’Ă©quipe et Ă  l’entraide.

Concrètement on fait quoi ?

Pour aligner tous les membres de l’Ă©quipe sur un niveau d’exigence minimum requis afin d’amener une user story en production et Ă©viter ainsi des dĂ©ceptions inutiles, il suffit de rĂ©unir toute l’Ă©quipe et de la faire arriver Ă  un consensus sur une liste de critères qui devront ĂŞtre respectĂ©s avant de considĂ©rer une user story terminĂ©e.

Généralement appelée Definition of Done, cette liste permet de faire des vérifications sur plusieurs aspects :

  • QualitĂ© : le code a Ă©tĂ© vu par plusieurs dĂ©veloppeurs, il respecte des standards dĂ©finis par l’Ă©quipe, etc.
  • Test : un seuil minimum de couverture de code est dĂ©fini, les tests de non rĂ©gression sont ok, les tests d’acceptation associĂ©s ont Ă©tĂ© automatisĂ©s, il existe si besoin un test de performance, etc.
  • DĂ©ploiement : la fonctionnalitĂ© a Ă©tĂ© dĂ©ployĂ©e sur un environnement, etc.

Bien Ă©videmment, la validation par le Product Owner vient s’ajouter Ă  cette liste, mais si tous les critères ont Ă©tĂ© respectĂ©s, cette validation se passe gĂ©nĂ©ralement sans trop de problème.

Enfin, faire une liste est un bon dĂ©but, l’afficher publiquement de manière Ă  ce que tout le monde puisse la voir et s’y rĂ©fĂ©rer rĂ©gulièrement lorsqu’une user story est annoncĂ©e comme terminĂ©e, est Ă©galement le meilleur moyen de ne pas l’oublier.

« Mais ça sort d’oĂą ça ? » – « Ah oui j’ai dĂ» oublier de vous le dire… Mais c’est super important, je ne peux pas valider sans l’avoir » La situation

Le Product Owner a prĂ©sentĂ©, lors du Sprint Planning, une user story qui n’Ă©tait pas très claire. Durant l’itĂ©ration, les dĂ©veloppeurs responsables de cette user story vont rĂ©gulièrement poser des questions au Product Owner pour avoir des Ă©claircissements. Pensant avoir enfin terminĂ© la user story, ils la passent en revue avec le Product Owner afin de la faire valider dĂ©finitivement. Seul problème, le Product Owner Ă©met des remarques bloquantes qu’il avait omis de prĂ©senter auparavant.

sorry cat

Pourquoi ça sent mauvais ?

Dissipons en premier lieu tout doute qui pourrait apparaĂ®tre : non, ne pas avoir fait de spĂ©cification dĂ©taillĂ©e n’est pas le problème dans cette situation. Une user story avec un niveau de dĂ©tail trop Ă©levĂ© nĂ©cessitera un travail plus important en amont de l’itĂ©ration ce qui engendrera un temps de cycle, entre le moment oĂą la user story est crĂ©Ă©e et le moment oĂą elle est terminĂ©e, trop long. Cela rĂ©duira Ă©galement les dĂ©veloppeur Ă  un rĂ´le de simple exĂ©cutant, tout ayant dĂ©jĂ  Ă©tĂ© dĂ©fini.

Au contraire, une user story sans assez de dĂ©tail, comme dans la situation prĂ©sente, impliquera des phases de dĂ©couvertes importantes durant l’itĂ©ration. Le risque Ă©tant de se retrouver dans la situation d’un arbre cachant la forĂŞt et donc des user stories impossibles Ă  terminer durant l’itĂ©ration. On se retrouve alors dans les mĂŞmes dangers que pour le deuxième smell de cet article : une vĂ©locitĂ© impossible Ă  prĂ©dire et une succession d’Ă©checs ressentis par l’Ă©quipe, ce qui influencera nĂ©gativement la motivation ainsi que la confiance accordĂ©e au Product Owner.

Un des premiers rĂ©flexes sera alors de surestimer la complexitĂ© de toutes les user stories afin de compenser d’Ă©ventuels imprĂ©vus. Au final, un remède contre les symptĂ´mes mais pas contre l’origine du problème.

Concrètement on fait quoi ?

Pour dĂ©finir correctement le pĂ©rimètre d’une user story sans pour autant tomber dans la rĂ©daction d’un document d’une dizaine de pages, il est nĂ©cessaire de dĂ©finir des critères d’acceptation. En d’autres termes, dĂ©finir un ensemble de conditions qui doivent ĂŞtre satisfaites pour considĂ©rer que la user story a bien atteint son objectif. Ces critères prennent gĂ©nĂ©ralement la forme d’exemples de comportement (obtenus par exemple en pratiquant le BDD) et sont souvent associĂ©s au langage Gherkin :

  • Given : l’Ă©tat du produit avant exĂ©cution de la user story
  • When : l’action de dĂ©clenchement de l’exĂ©cution
  • Then : l’Ă©tat du produit attendu après l’exĂ©cution de la user story

Une simple sĂ©rie de critères d’acceptation univoques va suffire Ă  cadrer le pĂ©rimètre d’une user story et sera en plus un Ă©lĂ©ment fondamental pour la mise en place de l’automatisation des tests d’acceptation.

Nous avons vu ici une manière de dĂ©finir les comportements attendus d’une user story, mais d’autres Ă©lĂ©ments peuvent entrer en compte. C’est pourquoi, de la mĂŞme manière qu’une Ă©quipe Ă  besoin de dĂ©finir une Definition of Done, elle va avoir besoin de dĂ©finir une Definition of Ready, Ă  savoir, un niveau d’exigence minimum requis afin d’intĂ©grer une user story dans une itĂ©ration. Et la recette est la mĂŞme : l’Ă©quipe se rĂ©unit et arrive Ă  un consensus sur une liste de critères qui devront ĂŞtre respectĂ©s avant de considĂ©rer une user story comme prĂŞte Ă  ĂŞtre dĂ©veloppĂ©e. Cela permettra d’effectuer des vĂ©rifications sur plusieurs aspects :

  • Formalisme commun : la user story suit le formalisme « En tant que… Je veux… Afin de… », etc.
  • DĂ©finition : des critères d’acceptation existent, des critères de performance, si nĂ©cessaire, ont Ă©tĂ© dĂ©finis, l’Ă©quipe sait comment dĂ©montrer la user story, etc.
  • Gestion des prĂ©-requis : les dĂ©pendances, si existantes, ont Ă©tĂ© livrĂ©es et testĂ©es, les jeux de donnĂ©es sont disponibles, etc.
  • Analyse technique : l’Ă©quipe a dĂ©jĂ  fait une première analyse aboutissant Ă  une estimation de la complexitĂ©, etc.

Bien Ă©videmment cette liste va servir de base de rĂ©flexion lors du Sprint Planning pour savoir si l’Ă©quipe a suffisamment d’Ă©lĂ©ments pour s’engager sur la rĂ©alisation. Le refus d’une user story doit forcĂ©ment ĂŞtre accompagnĂ© d’un plan d’action en Ă©quipe pour faire en sorte d’ĂŞtre capable de prendre cette user story lors d’une prochaine itĂ©ration, sinon, sur le long terme, le Product Owner risque d’avoir du mal Ă  accepter ce genre de situation.

Enfin, il est nécessaire de prendre du recul régulièrement en équipe afin de valider que le niveau de détail des user stories des itérations précédentes doit être reconduit ou modifié dans le futur.

Conclusion

Au travers de quatre situations, nous avons dĂ©couvert comment le backlog et les user stories pouvaient rĂ©vĂ©ler des pratiques contre-productives, mais Ă©galement, comment ils pouvaient ĂŞtre une aide d’une grande efficacitĂ© pour amĂ©liorer de nombreux aspects de la vie d’une Ă©quipe. Pour ceux qui le souhaitent, vous pouvez retrouver plusieurs articles dĂ©taillĂ©s sur ces sujets dans la Product Academy. Ne jetez pas votre dĂ©sodorisant tout de suite, nous revenons bientĂ´t avec de nouveaux agile smells dĂ©diĂ©s cette fois-ci aux pratiques de dĂ©veloppement et de test.

Catégories: Blog Société

Intégrer HashiCorp Vault aux services AWS

Après avoir jetĂ© la PKI Vault sur le grill, nous regardons ici comment Vault peut s’intĂ©grer dans l’environnement AWS.

Notre cas d’usage d’origine Ă©tait basĂ© sur Puppet et sur le dĂ©ploiement des certificats par ses agents. J’ai choisi ici de refaire la dĂ©mo de zĂ©ro en utilisant Terraform et Ansible pour des raisons pratiques. Ă€ cette diffĂ©rence près, il s’agit de la suite directe du premier article et je vous invite Ă  le lire pour suivre celui-ci.

L’intĂ©gration de Vault aux services d’AWS peut se faire Ă  trois endroits :

  • par le backend de stockage, sur S3 et/ou DynamoDB
  • par le backend d’authentification, en sĂ©grĂ©gant l’accès aux API Vault qu’Ă  certaines instances EC2.
  • par le secret backend, permettant Ă  Vault de gĂ©nĂ©rer des credentials AWS Ă  la demande (sous la forme de couples access_key et secret_key).

N’ayant pas eu l’usage du secret backend AWS, je n’aborde que les deux autres intĂ©grations dans les lignes qui suivent.

Les services AWS pour le stockage des données Vault Autoriser Vault à écrire dans un bucket S3

La consommation des services AWS suppose gĂ©nĂ©ralement l’utilisation d’un couple de clĂ©s (access_key et secret_key), qu’il est possible de renseigner en paramètres dans la configuration de Vault. Dans ce cas, ces secrets resteraient sur le disque et ce n’est pas la manière la plus sĂ©curisĂ©e de faire. D’autre part, le renouvellement de ces clĂ©s serait Ă  notre charge et Ă  effectuer rĂ©gulièrement.

Vault permet de s’appuyer sur le système d’Instance Profile fourni par AWS, Ă  savoir utiliser des credentials temporaires et gĂ©nĂ©rĂ©s pour une instance EC2 donnĂ©e. Ces credentials sont disponibles dans les mĂ©tadonnĂ©es de l’instance. AWS gère la rotation de ces secrets, ainsi que leur expiration si les droits viennent Ă  ĂŞtre mis Ă  jour ou rĂ©voquĂ©s.

Application d'une instance EC2 qui accède à une ressource AWS

Délégation de droits à une instance EC2

Les credentials sont gĂ©nĂ©rĂ©s spĂ©cifiquement pour l’instance EC2 courante, et sont limitĂ©s aux droits que vous aurez donnĂ© Ă  cette instance. AWS ne gĂ©nèrera d’ailleurs les paires de clĂ©s que si un Instance Profile est attribuĂ© Ă  l’instance EC2 en question.

Sans rentrer rĂ©ellement dans les dĂ©tails du modèle IAM d’Amazon, voici un exemple des ressources AWS et de leurs associations pour autoriser l’accès Ă  un bucket S3 (Ă©crit ici pour Terraform) :

Instance EC2, associée à son Instance Profile.

 

Instance Profile.

 

Le role, autorisant l’accès au service STS et donc Ă  la gĂ©nĂ©ration de credentials pour les instances EC2.

 

Role policy, ajoutant les droits d’accès RW sur le bucket S3 ‘sbo-vault’.

 

Une fois ces ressources AWS allouĂ©es, nous sommes capables d’instancier une VM EC2 et de lui donner les droits en Ă©criture sur le bucket S3 de notre choix (Ă  crĂ©er par ailleurs).

Si vous voulez approfondir les arcanes de l’IAM AWS, voici quelques pointeurs dans la documentation :

S3 comme backend de stockage

Une fois la partie IAM préparée, la configuration de Vault est simplissime et se limite à définir la région AWS et le nom du bucket S3 :

1
2
3
4
5
6
7
8
backend "s3" {
  bucket = "sbo-vault"
  region = "eu-west-1"
}
listener "tcp" {
  address     = "127.0.0.1:8200"
  tls_disable = 1
}

Au dĂ©marrage Vault accède directement au bucket et y Ă©crit ses donnĂ©es. Après l’initialisation de Vault le contenu du bucket ressemble Ă  ceci :

Si vous souhaitez multiplier les instances de Vault, un bucket S3 est nĂ©cessaire pour chaque instance dĂ©ployĂ©e. La concurrence en Ă©criture n’est en effet pas gĂ©rĂ©e et vous risqueriez de corrompre des secrets.

Par ailleurs, S3 n’est pas Ă©ligible comme backend de HA : Vault s’appuie sur  son backend de stockage pour Ă©lire le nĹ“ud maĂ®tre lorsque dĂ©ployĂ© en cluster, et S3 ne permet pas cette Ă©lection.

DynamoDB pour ajouter la Haute Dispo … ou pas

Pour DynamoDB, le fonctionnement est identique Ă  S3 : une fois les bons droits accordĂ©s Ă  l’instance, Vault est capable de rĂ©cupĂ©rer les credentials AWS et de se connecter Ă  DynamoDB. Il y a quelques paramètres supplĂ©mentaires comparativement Ă  S3 (disponibles ici [EN]), notamment liĂ©s au fonctionnement de la Haute DisponibilitĂ©.

Bien que rĂ©fĂ©rencĂ© comme backend Ă©ligible Ă  la HA, DynamoDB souffre d’une limitation nĂ©cessitant une intervention manuelle pour gĂ©rer la reprise sur erreur.

Si la haute disponibilitĂ© n’est pas critique pour votre cas d’usage (typiquement si Vault est utilisĂ© comme PKI et ne fourni qu’un certificat de temps en temps), l’utilisation d’une instance seule « backĂ©e«  S3 est largement suffisante. Par ailleurs, l’utilisation d’un Autoscaling Group avec un min/max Ă  1 permet de maintenir cette unique instance up and running en permanence.

En revanche, si la haute disponibilité est essentielle, je vous invite à regarder Consul, etcd voir ZooKeeper comme backends de HA, tout en gardant S3 comme backend principal. En résumé, pour ce qui est de la HA :

Utiliser les services AWS pour s’authentifier sur Vault

Maintenant que nos secrets sont stockĂ©s dans S3, intĂ©ressons-nous Ă  la façon de requĂŞter ces secrets depuis l’environnement AWS. Comme dĂ©crit dans l’article prĂ©cĂ©dent, Vault possède plusieurs secret backends. Et sur chacun de ces backends les ressources exposĂ©es peuvent ĂŞtre associĂ©es Ă  un ensemble de  politiques de sĂ©curitĂ© (policies).

Ces policies sont associĂ©es Ă  des utilisateurs ou Ă  des groupes d’utilisateurs, et permettent de dĂ©finir leurs droits sur les ressources.

Petite subtilité : dans notre exemple du backend PKI, les roles représentent les ressources exposées par le backend PKI. Il ne faut donc pas confondre avec la notion commune du rôle au sens RBAC.

CrĂ©ation d’une policy Vault pour notre PKI

Afin de protĂ©ger l’Ă©mission de certificats, revenons sur ce que nous avions dĂ©jĂ  fait :

$ vault list interca/roles/

Keys
----
aws-dot-octo

Voici le role que nous avions créé la dernière fois (Cf la PKI Vault sur le grill). Et pour mémoire, il suffit de requêter ce role pour obtenir un nouveau certificat :

$ vault write interca/issue/aws-dot-octo common_name=vault.aws.octo

Key                 Value
---                 -----
lease_id            interca/issue/aws-dot-octo/0d7a8b4f-7f36-c6e1-0ebb-f2f9b0dca194
lease_duration      71h59m59s
lease_renewable     false
ca_chain            [...]
certificate         [...]
issuing_ca          [...]
private_key         [...]
private_key_type    rsa
serial_number       6c:98:f6:9b:80:bc:89:32:02:e2:47:34:dc:a9:8c:30:94:00:be:9f

Nous pouvons gĂ©nĂ©rer ce certificat car nous utilisons actuellement le token gĂ©nĂ©rĂ© Ă  l’initialisation de l’instance Vault. Autrement dit, nous sommes par dĂ©faut authentifiĂ©s comme root auprès de Vault et avons les droits correspondants.

$ env

[...]
VAULT_ADDR=http://127.0.0.1:8200
VAULT_TOKEN=281963cf-88ae-1027-0dcb-ae0a1f0cf3e9

Dans un environnement de production, la crĂ©ation d’utilisateurs aux droits limitĂ©s et dĂ©diĂ©s Ă  certains usages est indispensable, et c’est ce que la crĂ©ation d’une policy va nous permettre de faire.

Par dĂ©faut, un client authentifiĂ© (autre que root) n’a aucun droit. Il suffit donc de lui associer la policy suivante pour ne l’autoriser qu’Ă  Ă©crire sur notre role :

1
2
3
path "interca/issue/aws-dot-octo" {
  policy = "write"
}

Si vous ĂŞtes familier des règles de contrĂ´le d’accès sur les ressources web, vous ĂŞtes en terrain connu : on associe un chemin de l’URL avec un droit d’accès. Et il n’y a pas de limite dans le nombre de règles dans une mĂŞme policy. Vous trouverez dans la doc [EN] les diffĂ©rents verbes et capabilities applicables sur les ressources.

Il faut ensuite passer par un fichier pour enregistrer cette policy , que je nomme policy_aws-dot-octo :

$ vault policy-write policy_aws-dot-octo /tmp/pki-policy.hcl

Policy 'policy_aws-dot-octo' written.

Et voici comment la tester:

$ vault token-create -policy=policy_aws-dot-octo

Key                Value
---                -----
token              06c97184-3b53-8ddd-f927-7f1a358e8269
token_accessor     cc5063ff-2dde-2089-48b7-0f2a753ad985
token_duration     768h0m0s
token_renewable    true
token_policies     [default policy_aws-dot-octo]
$ export VAULT_TOKEN=06c97184-3b53-8ddd-f927-7f1a358e8269

$ vault write interca/issue/aws-dot-octo common_name=test-policy.aws.octo

Key                 Value
---                 -----
lease_id            interca/issue/aws-dot-octo/86eb0d30-8d59-27f1-4d04-e1a11a1ed40c
lease_duration      71h59m59s
lease_renewable     false
ca_chain            [...]
certificate         [...]
issuing_ca          [...]
private_key         [...]
private_key_type    rsa
serial_number       7e:9e:eb:2f:a7:ff:c7:4b:62:e6:f5:30:49:43:a7:21:2d:46:aa:c3
$ vault mounts

Error reading mounts: Error making API request.

URL: GET http://127.0.0.1:8200/v1/sys/mounts
Code: 403. Errors:

Ce qui s’est passĂ© :

  • Nous avons profitĂ© des droits root pour gĂ©nĂ©rer un token associĂ© Ă  la policy policy_aws-dot-octo.
  • Nous avons utilisĂ© ce token pour gĂ©nĂ©rer un certificat tel qu’autorisĂ© par la policy
  • Une autre commande habituellement possible avec le token root (ici le listing des secrets backends configurĂ©s) nous est refusĂ© avec une erreur 403 : Forbidden.

Tadaaa !

Tokens Vault et authentification

Nous venons d’utiliser les privilèges accordĂ©s Ă  root pour gĂ©nĂ©rer le token d’un utilisateur. TransposĂ© dans le monde rĂ©el cela revient Ă  passer par un administrateur pour demander la crĂ©ation de credentials de manière unitaire, et c’est Ă©loignĂ© de ce que l’on veut faire : automatisation / rĂ©pudiation & expiration des credentials / passage Ă  l’Ă©chelle etc.

Vault nous propose des backends d’authentification pour nous appuyer sur des solutions existantes. Au delĂ  de la gestion de l’authentification par tokens (intĂ©grĂ©e dans le cĹ“ur de Vault), vous pouvez utiliser les traditionnels login + mot de passe, un annuaire LDAP, les certificats x509 ou mĂŞme GitHub. Dans le cas de GitHub, il est par exemple possible d’accorder des droits d’accès en fonction de l’organisation GitHub Ă  laquelle est rattachĂ© l’utilisateur.

Afin de revenir Ă  un fonctionnement unique, tous les backends d’authentification permettent in fine d’obtenir un token Vault. Et comme dans notre exemple, le token obtenu est scopĂ© sur une policy Ă  sa crĂ©ation. La fin de la sĂ©quence est donc identique quelque soit le moyen d’authentification : requĂŞte sur l’API Vault avec le token en paramètre.

Le backend auth-ec2 Principes de fonctionnement

Vault nous propose de nous appuyer sur l’infrastructure d’Amazon pour rĂ©aliser l’authentification des machines EC2 clientes auprès de Vault.

Toute machine virtuelle du service EC2 peut requĂŞter l’URL http://169.254.169.254/latest/dynamic/instance-identity/document :

$ curl http://169.254.169.254/latest/dynamic/instance-identity/document

{
  "devpayProductCodes" : null,
  "availabilityZone" : "eu-west-1c",
  "privateIp" : "192.168.1.134",
  "version" : "2010-08-31",
  "region" : "eu-west-1",
  "instanceId" : "i-045d4683886353b08",
  "billingProducts" : null,
  "instanceType" : "t2.small",
  "accountId" : "218232161888",
  "architecture" : "x86_64",
  "kernelId" : null,
  "ramdiskId" : null,
  "imageId" : "ami-6f587e1c",
  "pendingTime" : "2017-03-24T15:13:59Z"
}

Elle obtient ainsi quelques informations la concernant, comme son adresse IP, son ID et quelques autres mĂ©tadonnĂ©es. De la mĂŞme manière, avec l’URL http://169.254.169.254/latest/dynamic/instance-identity/pkcs7, les instances obtiennent la signature de cette mĂŞme carte d’identitĂ©, au format PKCS7 et fournie par Amazon :

$ curl http://169.254.169.254/latest/dynamic/instance-identity/pkcs7

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggGwewog
ICJkZXZwYXlQcm9kdWN0Q29kZXMiIDogbnVsbCwKICAiYXZhaWxhYmlsaXR5Wm9uZSIgOiAiZXUt
d2VzdC0xYyIsCiAgInByaXZhdGVJcCIgOiAiMTkyLjE2OC4xLjEzNCIsCiAgInZlcnNpb24iIDog
IjIwMTAtMDgtMzEiLAogICJyZWdpb24iIDogImV1LXdlc3QtMSIsCiAgImluc3RhbmNlSWQiIDog
ImktMDQ1ZDQ2ODM4ODYzNTNiMDgiLAogICJiaWxsaW5nUHJvZHVjdHMiIDogbnVsbCwKICAiaW5z
dGFuY2VUeXBlIiA6ICJ0Mi5zbWFsbCIsCiAgImFjY291bnRJZCIgOiAiMjE4MjMyMTYxODg4IiwK
ICAiYXJjaGl0ZWN0dXJlIiA6ICJ4ODZfNjQiLAogICJrZXJuZWxJZCIgOiBudWxsLAogICJyYW1k
aXNrSWQiIDogbnVsbCwKICAiaW1hZ2VJZCIgOiAiYW1pLTZmNTg3ZTFjIiwKICAicGVuZGluZ1Rp
bWUiIDogIjIwMTctMDMtMjRUMTU6MTM6NTlaIgp9AAAAAAAAMYIBGDCCARQCAQEwaTBcMQswCQYD
VQQGEwJVUzEZMBcGA1UECBMQV2FzaGluZ3RvbiBTdGF0ZTEQMA4GA1UEBxMHU2VhdHRsZTEgMB4G
A1UEChMXQW1hem9uIFdlYiBTZXJ2aWNlcyBMTEMCCQCWukjZ5V4aZzAJBgUrDgMCGgUAoF0wGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzI0MTUxNDAwWjAjBgkq
hkiG9w0BCQQxFgQU+O2Cc6Uk3aEX7F4DLqAM84G9duAwCQYHKoZIzjgEAwQvMC0CFFgm3Pe+OEVq
phaXs78dKkYNIfeyAhUArmf9jgRJLfubT7g/WhWqyx4+kKUAAAAAAAA=

AWS nous donne les moyens de vérifier la signature [EN] avec la clé publique correspondante, et Vault se base sur ces éléments pour authentifier une instance. La séquence :

  1. Vault reçoit une requĂŞte d’authentification avec la signature PKCS7 d’une instance EC2
  2. Vault vĂ©rifie la validitĂ© de la fiche et de sa signature Ă  l’aide des clĂ©s publiques AWS (une par rĂ©gion)
  3. Vault confirme ensuite Ă  partir des mĂ©tadonnĂ©es de la fiche que l’instance existe et qu’elle est en cours d’exĂ©cution.
  4. Vault répond avec un token

La principale faiblesse de ce moyen d’authentification est le non renouvellement des fiches d’identitĂ© des instances EC2. Elles restent identiques jusqu’Ă  la destruction des instances. Afin de prĂ©venir le vol et le rejeu d’une fiche d’identitĂ© pendant la vie de l’instance, Vault ajoute la possibilitĂ© de crĂ©er un nonce [FR] Ă  la première authentification. Une fois le nonce configurĂ©, l’instance en question ne pourras plus s’authentifier auprès de Vault, sans fournir sa fiche d’identitĂ© et son nonce simultanĂ©ment.

Au delĂ  de la phase d’authentification, Vault permet d’ajouter une Ă©tape d’autorisation avant de fournir le token. La crĂ©ation d’un role (/!\ cette fois au sens RBAC) dans le backend d’autorisation aws-ec2 , permet de sĂ©grĂ©ger les instances EC2 Ă  partir des Ă©lĂ©ments suivants :

  • bound_ami_id, n’autorise que les instances crĂ©Ă©es Ă  partir d’une AMI donnĂ©e
  • bound_account_id, n’autorise que les instances d’un certain compte AWS (il est en effet possible d’utiliser le service STS d’Amazon pour fournir des credentials aux instances d’un autre compte)
  • bound_region, n’autorise que les instances d’une rĂ©gion AWS prĂ©cise
  • bound_vpc_id, n’autorise que les instances d’un VPC
  • bound_subnet_id, n’autorise que les instances d’un subnet
  • bound_iam_role_arn & bound_iam_instance_profile_arn, n’autorise que les instances possĂ©dant un rĂ´le AWS ou un Instance Profile donnĂ©.

Cette liste s’allonge et se complète rĂ©gulièrement avec les nouvelles versions de Vault.

D’autres Ă©lĂ©ments sont configurables au niveau du role, comme le TTL des tokens gĂ©nĂ©rĂ©s pour ce role, ou la policy Ă  associer au role. Vous trouverez le dĂ©tails des paramètres dans la documentation de l’API du backend auth-ec2 [EN].

En pratique : l’authentification par le backend auth-ec2

La première Ă©tape consiste Ă  Ă©tendre les droits AWS accordĂ©s Ă  l’instance EC2 qui hĂ©berge notre Vault. Sans ça, Vault ne sera pas en mesure de vĂ©rifier l’Ă©tat des instances EC2 du tenant. La policy AWS suivante vient donc complĂ©ter celle dĂ©jĂ  crĂ©Ă©e pour permettre l’accès au bucket S3 :

1
2
3
4
5
6
7
8
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "ec2:DescribeInstances",
    "Resource": "*"
  }]
}

Ă€ cette Ă©tape, si nous essayons de nous authentifier Ă  partir de l’instance cliente cela ne fonctionnera pas. Vault impose de crĂ©er au moins un role afin de spĂ©cifier la politique d’Ă©mission du token. Nous allons donc crĂ©er un role sur aws-ec2 pour nos instances clientes, et les autoriser selon l’AMI utilisĂ©e :

$ vault write auth/aws-ec2/role/vault-client bound_ami_id=ami-6f587e1c policies=policy_aws-dot-octo

Success! Data written to: auth/aws-ec2/role/vault-client

Maintenant, testons depuis l’instance cliente. D’abord la rĂ©cupĂ©ration de la fiche d’identitĂ© au format PKCS7 (en enlevant les sauts de ligne) :

$ curl -s http://169.254.169.254/latest/dynamic/instance-identity/pkcs7 | tr -d

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggGvewogICJkZXZwYXlQcm9kdWN0Q29kZXMiIDogbnVsbCwKICAiYXZhaWxhYmlsaXR5Wm9uZSIgOiAiZXUtd2VzdC0xYyIsCiAgInByaXZhdGVJcCIgOiAiMTkyLjE2OC4xLjg1IiwKICAidmVyc2lvbiIgOiAiMjAxMC0wOC0zMSIsCiAgInJlZ2lvbiIgOiAiZXUtd2VzdC0xIiwKICAiaW5zdGFuY2VJZCIgOiAiaS0wZTBjOWZlYmVjY2YzYTIwYiIsCiAgImJpbGxpbmdQcm9kdWN0cyIgOiBudWxsLAogICJpbnN0YW5jZVR5cGUiIDogInQyLnNtYWxsIiwKICAiYWNjb3VudElkIiA6ICIyMTgyMzIxNjE4ODgiLAogICJhcmNoaXRlY3R1cmUiIDogIng4Nl82NCIsCiAgImtlcm5lbElkIiA6IG51bGwsCiAgInJhbWRpc2tJZCIgOiBudWxsLAogICJpbWFnZUlkIiA6ICJhbWktNmY1ODdlMWMiLAogICJwZW5kaW5nVGltZSIgOiAiMjAxNy0wMy0yNFQxNToxMzo1OVoiCn0AAAAAAAAxggEXMIIBEwIBATBpMFwxCzAJBgNVBAYTAlVTMRkwFwYDVQQIExBXYXNoaW5ndG9uIFN0YXRlMRAwDgYDVQQHEwdTZWF0dGxlMSAwHgYDVQQKExdBbWF6b24gV2ViIFNlcnZpY2VzIExMQwIJAJa6SNnlXhpnMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjQxNTE0MDBaMCMGCSqGSIb3DQEJBDEWBBRhci4q0Js+77sS6PD2hE62+4kPOjAJBgcqhkjOOAQDBC4wLAIUFWPouht+AvoDDZNESGfiTyj5kfQCFFvNVOqgjJU+REbegK/sCYTUNv9RAAAAAAAA

Puis, toujours depuis l’instance cliente, authentification auprès de l’API Vault :

$ curl -X POST "https://vault.aws.octo/v1/auth/aws-ec2/login" -d '{
"role":"vault-client",
"pkcs7":"MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIICJkZXZwYXlQcm9kdWN0Q29kZXMiIDogbnVsbCwKICAiYXZhaWxhYmlsaXR5Wm9uZSIgOiAiZXUtd2VzdC0xYyIsCiAgInByaXZhdGVJcCIgOiAiMTkyLjE2OC4xLjg1IiwKICAidmVyc2lvbiIgOiAiMjAxMC0wOC0zMSIsCiAgInJlZ2lvbiIgOiAiZXUtd2VzdC0xIiwKICAiaW5zdGFuY2VJZCIgOiAiaS0wZTBjOWZlYmVjY2YzYTIwYiIsCiAgImJpbGxpbmdQcm9kdWN0cyIgOiBudWxsLAogICJpbnN0YW5jZVR5cGUiIDogInQyLnNtYWxsIiwKICAiYWNjb3VudElkIiA6ICIyMTgyMzIxNjE4ODgiLAogICJhcmNoaXRlY3R1cmUiIDogIng4Nl82NCIsCiAgImtlcm5lbElkIiA6IG51bGwsCiAgInJhbWRpc2tJZCIgOiBudWxsLAogICJpbWFnZUlkIiA6ICJhbWktNmY1ODdlMWMiLAogICJwZW5kaW5nVGltZSIgOiAiMjAxNy0wMy0yNFQxNToxMzo1OVoiCn0AAAAAAAAxggEXMIIBEwIBATBpMFwxCzAJBgNVBAYTAlVTMRkwFwYDVQQIExBXYXNoaW5ndG9uIFN0YXRlMRAwDgYDVQQHEwdTZWF0dGxlMSAwHgYDVQQKExdBbWF6b24gV2ViIFNlcnZpY2VzIExMQwIJAJa6SNnlXhpnMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjQxNTE0MDBaMCMGCSqGSIb3DQEJBDEWBBRhci4q0Js+77sS6PD2hE62+4kPOjAJBgcqhkjOOAQDBC4wLAIUFWPouht+AvoDDZNESGfiTyj5kfQCFFvNVOqgjJU+REbegK/sCYTUNv9RAAAAAAAA", 
"nonce":"vault-client-nonce"}'

{
  "request_id":"60567c2f-8e27-89e8-b4b9-90acfd4360d7",
  "lease_id":"",
  "renewable":false,
  "lease_duration":0,
  "data":null,
  "wrap_info":null,
  "warnings":null,
  "auth":{
    "client_token":"2c23cd00-05b0-4227-5197-904918db742b",
    "accessor":"a683bd5e-0c0b-0604-fbd9-f944f5366d4c",
    "policies":["default","policy_aws-dot-octo"],
    "metadata":{
      "account_id":"218232161888",
      "ami_id":"ami-6f587e1c",
      "instance_id":"i-0e0c9febeccf3a20b",
      "nonce":"vault-client-nonce",
      "region":"eu-west-1",
      "role":"vault-client",
      "role_tag_max_ttl":"0s"
    },
    "lease_duration":2764800,
    "renewable":true
  }
}

 

En version plus condensée et sans faire de copier coller :

$ curl -X POST "https://vault.aws.octo/v1/auth/aws-ec2/login" -d "{
  \"role\":\"vault-client\",
  \"pkcs7\":\"$(curl -s http://169.254.169.254/latest/dynamic/instance-identity/pkcs7 | tr -d '\n')\",
  \"nonce\":\"vault-client-nonce\"}"

{
  "request_id":"db499fab-f0c8-0a5a-e964-eca68d16b30b",
  "lease_id":"",
  "renewable":false,
  "lease_duration":0,
  "data":null,
  "wrap_info":null,
  "warnings":null,
  "auth":{
    "client_token":"8846033c-3f05-3e7a-52ce-1de876efd2ff",
    "accessor":"3dfa5e3f-fe2c-dfc1-cd04-8554e894368b",
    "policies":["default","policy_aws-dot-octo"],
    "metadata":{
      "account_id":"218232161888",
      "ami_id":"ami-6f587e1c",
      "instance_id":"i-0e0c9febeccf3a20b",
      "nonce":"vault-client-nonce",
      "region":"eu-west-1",
      "role":"vault-client",
      "role_tag_max_ttl":"0s"
    },
    "lease_duration":2764800,
    "renewable":true
  }
}

 

Dernière Ă©tape : gĂ©nĂ©rer un certificat en appelant l’API Ă  l’aide du token obtenu :

$ curl -X POST "https://vault.aws.octo/v1/interca/issue/aws-dot-octo"
  -H "X-Vault-Token:8846033c-3f05-3e7a-52ce-1de876efd2ff"
  -d '{"common_name":"test.aws.octo","format":"pem"}'

{"request_id":"5df91a88-f1fd-c291-8b0f-06c78b8f3121",
"lease_id":"interca/issue/aws-dot-octo/5ec630f0-b7ea-d606-488d-0058dc975ffc",
"renewable":false,
"lease_duration":259199,
"data":{
"ca_chain":
  ["-----BEGIN CERTIFICATE-----\n
  [...]\n
  -----END CERTIFICATE-----"],
"certificate":
  "-----BEGIN CERTIFICATE-----\n
  [...]\n
  -----END CERTIFICATE-----",
"issuing_ca":
  "-----BEGIN CERTIFICATE-----\n
  [...]\n
  -----END CERTIFICATE-----",
"private_key":
  "-----BEGIN RSA PRIVATE KEY-----\n
  [...]\n
  -----END RSA PRIVATE KEY-----",
"private_key_type":"rsa",
"serial_number":"6a:5a:04:81:97:e8:6e:b3:80:e8:bb:f0:2b:e0:87:24:2a:7b:2e:fd"},
"wrap_info":null,
"warnings":null,"auth":null}
Takeaways

Le duo Ansible / Terraform fonctionne bien, et permet de prototyper plus rapidement qu’avec Puppet / Terraform. DĂ©nominateur commun, Terraform reste dans tous les cas incontournable. Nous le prĂ©conisons d’ailleurs quasi-systĂ©matiquement sur nos missions AWS, malgrĂ© le langage HCL parfois bancal ou une gestion des state un peu fragile notamment.

En termes de maĂ®trise, difficile de se sentir expert Vault après ce POC tant les concepts changent en fonction des backends utilisĂ©s. Le produit Ă©volue rapidement : aujourd’hui testĂ© en 0.6.5, une part des fonctionnalitĂ©s prĂ©sentĂ©es ont dĂ©jĂ  Ă©tĂ© complĂ©tĂ©es en 0.7.0 puis 0.7.1. (Un coup d’Ĺ“il sur le changelog et vous verrez que le backend auth-ec2 Ă©tend dĂ©jĂ  l’authentification aux personnes, aux lambdas, aux instances ECS etc. et non plus aux simples instances EC2).

Quant Ă  l’intĂ©gration Ă  AWS, il semble indispensable d’en comprendre les concepts de leur modèle de droits et d’identitĂ©s (IAM) avant de se lancer en production. Cela rend la courbe d’apprentissage certes plus pentue, mais devrait Ă©viter la fuite de secrets de votre coffre fort.

En bref, Vault rĂ©pond Ă  mes attentes en termes d’automatisation, d’intĂ©gration, de scalabilitĂ© et de fonctionnalitĂ©s. Je m’attends Ă  le re-croiser rĂ©gulièrement dans de futures missions

 

Articles suggested :

  1. Panorama des différentes offres de cloud computing : Amazon Web Services
  2. La PKI Vault sur le grill
  3. DĂ©ploiement d’une application sur l’infrastructure AMAZON (3/3)

Catégories: Blog Société

DevoxxFR 2017 – Jour 2

Trois semaines plus tard, je reviens sur mon jour 2 passé à DevoxxFR 2017.
Au menu des Keynotes plutĂ´t sympas, un zoom sur Infinispan et les bases in-memory et un petit update sur HTTP2.

De la responsabilitĂ© des ingĂ©nieurs, Keynote d’Éric Sadin

Dans cette Keynote, Éric Sadin nous parle de la place de l’ingĂ©nieur dans la sociĂ©tĂ© Ă  l’âge du numĂ©rique. Selon lui, le dĂ©but d’Internet peut ĂŞtre qualifiĂ© d’”âge de l’accès” (Ă  l’information). Si on est toujours dans cet “âge de l’accès”, on rentre aussi dans “l’âge de la mesure de la vie”, qui se rapproche du mouvement “quantify self”. C’est-Ă -dire qu’on effectue de plus en plus de mesures (capteurs partout via l’Internet of Things), ce qui donne de plus en plus de donnĂ©es. Ces donnĂ©es sont Ă  leur tour de plus en plus traitĂ©es, interprĂ©tĂ©es par des systèmes d’Intelligence Artificielle (IA) qui sont de plus en plus sophistiquĂ©s. Ces systèmes servent les besoins des grandes entreprises. Au final, « on marchandise la vie”.

Pour Éric Sadin, les ingénieurs (développeurs) sont au centre de tout ça, sans se rendre compte de leur impact. Alors qu’au XVIIIème siècle, l’ingénieur maîtrisait l’ensemble des processus. Ensuite, l’apparition des brevets entraîne l’achat des savoirs et des innovations par les entreprises. L’ingénieur est lui aussi “racheté” par l’entreprise. Conséquence : une parcellisation des tâches qui amène une moindre visibilité sur les finalités des recherches et une dissolution des responsabilités. L’autre impact est que l’ingénieur est désormais assujetti aux besoins industriels et économiques, donc aux tendances du marché décrites par les cabinets de marketing. Pour lui, l’ingénieur d’aujourd’hui est irresponsable car il ne réfléchit pas aux conséquences de ses travaux.

Ensuite, il enchaĂ®ne sur la question de l’enseignement. Sans le nommer, il parle du financement des grandes Ă©coles par les entreprises et du problème que cela pose : Comment les Ă©coles, sponsorisĂ©es par les grandes entreprises, peuvent-elles enseigner l’esprit critique vis-Ă -vis de ces dernières ? Petit tacle au passage Ă  Xavier Niel qui se vante de ne pas avoir de bibliothèque, alors que pour Eric Sadin, la bibliothèque est le symbole d’une prise de recul et d’un esprit critique.

Au final, Éric Sadin pousse pour prendre du recul et faire des projets « obliques », c’est-Ă -dire qui ne sont pas dictĂ©s uniquement par les intĂ©rĂŞts Ă©conomiques des entreprises.

Ce que j’en retiens
  • Nous, ingĂ©nieurs, dĂ©veloppeurs, devons prendre conscience de l’importance de nos travaux et de leurs impacts
  • Prendre le temps de prendre du recul

 

Video games: The quest for smart dumbness, Keynote de Laurent Victorino

Très bonne Keynote, intéressante et amusante (même si je n’en tire pas grand chose applicable dans mon quotidien), avec quelques trolls (faciles mais drôles) sur Java.

Laurent Victorino nous explique pourquoi l’Intelligence Artificielle des jeux vidĂ©os semble souvent assez stupide, alors que l’IA a fait des progrès Ă©normes dans tous les autres domaines. La rĂ©ponse rapide, c’est qu’une IA trop forte dans les jeux vidĂ©os, ça gagne Ă  tous les coups et ça frustre très rapidement les joueurs qui ne peuvent plus gagner. Et un joueur frustrĂ©, ça n’achète pas les jeux. Donc, ici, c’est le parfait exemple de l’expression “c’est pas un bug, c’est une feature ». Ce que je ne savais pas, c’est qu’on ne fabrique pas une IA idiote si facilement. Pour arriver Ă  une IA assez stupide pour se faire battre par un humain, les dĂ©veloppeurs fabrique la meilleure qu’ils peuvent, bien souvent très très forte, puis ils passent un certain temps Ă  introduire des “bugs”.

Ce que j’en retiens
  • Les dĂ©veloppeurs d’IA de jeux vidĂ©os ne sont pas incompĂ©tents, ils cassent juste leur travail pour s’adapter au niveau des joueurs
  • Tester Gladiabots, un jeu oĂą on configure une IA qui va combattre celle des autres joueurs
Architecture par la pratique : patterns d’utilisation de systèmes in-memory – WD-40 entre vos donnĂ©es et vos applis – Emmanuel Bernard / Galder Zamarreno

Une session plus technique pour continuer qui parle des systèmes in-memory en général et d’Infinispan en particulier (les speakers sont de Red Hat qui fournit la version payante d’Infinispan).
Un concept à retenir, c’est que nous ne sommes plus dans des systèmes où la donnée est statique dans une base de données, mais où la donnée bouge, se copie, se transforme, évolue. On parle de rivières de données, de flux.

Petit zoom sur Infinispan. C’est une grille de données in-memory, de forme key-value, distribuée, élastique, avec un schéma optionnel. Je passe le détail de ce que tous ces mots veulent dire, je considère que vous les connaissez déjà.

La présentation fait ensuite le tour de quelques cas d’utilisation.
Le premier, et le plus évident, est le cache (à l’instar d’un redis par exemple). Dans ce cas, le in-memory fait tout son sens, puisqu’on ne va pas perdre de temps à sauver la donnée sur disque. Comme la plupart des caches, on peut l’utiliser embedded dans une application (meilleures performances), soit dans un cluster (pour avoir un cache partagé entre serveurs).
Le cas suivant est d’utiliser votre système in-memory comme primary store, on peut configurer Infinispan pour qu’il sauvegarde ses données sur disque, donc pas que in-memory. À noter qu’Infinispan supporte les transactions XA et qu’on peut utiliser des ORMs comme JPA ou Spring data (Emmanuel Bernard était développeur sur Hibernate).
Cas intéressant d’utilisation est celui du “Data Virtualization Duck Taping” où on va utiliser notre système in-memory comme base de données virtuelle, accessible par notre super hype nouveau microservice, au-dessus de notre vieille base de données qui est toujours accédée par notre ancien système qu’on aimerait bien décommissionner un jour. J’avoue qu’à ce moment là j’avais plein de questions pratiques dans ma tête sur ce cas d’usage : comment la synchronisation à la base sous-jacente est-elle réalisée ? quel overhead ? Quelles limites d’avoir des schémas trop éloignés ? etc. mais la présentation ne s’y est pas arrêtée.
On reste dans l’idée de migration vers des microservices avec le pattern “Change Data Capture” et l’outil Debezium, développé aussi par Red Hat. Cet outil va écouter tous les changements de votre base de données existante pour les transformer en événements. Ces événements sont injectés dans un Kafka afin que d’autres applications puissent les consommer.

Ce que j’en retiens
  • La tendance c’est d’aller vers des architectures de flux, des “rivières de donnĂ©es”
  • Autre tendance qui persiste depuis quelques annĂ©es : migration vers des architectures microservices.
  • Les patterns “Data Virtualization Duck Taping” et “Change Data Capture” peuvent ĂŞtre d’autres solutions lorsqu’on veut migrer un système existant vers une architecture microservices.

 

HTTP2 du point de vue développeur, Sébastien Augereau

Quickie (session de 15 minutes) sur l’évolution du protocole HTTP.
Les principaux points : on passe à un protocole binaire, plus compact, ce qui a pour effet d’être plus rapide, mais moins lisible pour le développeur. On utilise du multiplexing, une connexion HTTP est utilisée pour télécharger plusieurs ressources. Au final, ça va plus vite. On parle de d’un réduction de 25 à 50 % du temps de chargement des pages.
Facile à mettre en place, dans leur exemple en Java ça fait 5 lignes de code. Les CDNs comme CloudFront l’ont déjà mis en place, sans action requise de votre part.

Ce que j’en retiens
  • HTTP2 ce n’est plus uniquement “pour plus tard” mais Ă  intĂ©grer dès aujourd’hui sur nos projets, ça coĂ»te pas cher.
Catégories: Blog Société

Spreadsheets 2.3: Smart tables that blend into Confluence

Le blog de Valiantys - mar, 04/25/2017 - 14:00

Sometimes the native table feature within Confluence isn’t enough when you need to perform calculations, and that’s where our add-on Spreadsheets comes into play. With its rich formulas and advanced formatting options, it allows users to create smart tables within Confluence for several use cases: budget tracking, project management, creating expense report, etc. Yet there was one little thing ...

The post Spreadsheets 2.3: Smart tables that blend into Confluence appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

Docker on steroid avec xhyve et NFS

L'actualité de Synbioz - lun, 04/24/2017 - 23:00

Je dois avouer que je suis vraiment fan des solutions de conteneurisation. Le fait de pouvoir packager ses applications est un vrai gage de sérénité.

Dans un contexte SI où vous avez 10+ applications avec des technologies différentes, simplifier et harmoniser votre processus d’onboarding et homogénéiser votre processus de déploiement est également un réel gain de productivité.

Lire la suite...

Catégories: Blog Société

Hackergarten d’avril

Paris Hackergarten logo

Pour terminer ce beau mois d’avril, quoi de mieux qu’un peu d’open source ? Si vous souhaitez contribuer sur un projet, le meetup Hackergarten revient pour vous permettre de vous lancer dans cette belle aventure. Que vous soyez novice ou non dans le domaine, vous ĂŞtes le bienvenu.

Le rendez-vous est prévu pour le mardi 25 avril 2017, 19h30, 156 boulevard Haussmann Paris, 7e étage.

Le meetup Hackergarten a pour but d’organiser des rencontres physiques entre contributeurs majeurs voire crĂ©ateurs de projets open source et de futurs contributeurs. L’ambiance est vraiment conviviale alors ne soyez pas timides. Venez simplement avec votre machine et votre envie de coder, on s’occupe du reste.

Seront présents :

L’inscription est toujours gratuite et un buffet est offert pour compenser la dĂ©pense d’Ă©nergie. De l’open source, des codeurs et un buffet… Tout pour ĂŞtre heureux !

Catégories: Blog Société

Apache Kafka – Genèse, Concepts et Fonctionnement du message-broker du big-data

Kafka est un système de messagerie distribuĂ© open-source dont le dĂ©veloppement a dĂ©butĂ© chez LinkedIn en 2009, et est maintenu depuis 2012 par la fondation Apache. TolĂ©rant aux pannes, performant, hautement distribuable et adaptĂ© aux traitements batchs comme streams, Kafka a su mettre les arguments pour devenir un standard incontournable dans les pipelines de traitements […]
Catégories: Blog Société

#PortraitDeCDO – François-Régis Martin – BNP Paribas Leasing Solutions

#PortraitDeCDO – François-RĂ©gis Martin – BNP Paribas Leasing Solutions

DĂ©couvrez pour le douzième #PortraitDeCDO, avec le portrait de François-RĂ©gis Martin Chief Digital Officer de BNP Paribas Leasing Solutions. Vous allez pouvoir dĂ©couvrir les enjeux du numĂ©rique pour son entreprise, ses contraintes au quotidien ou encore son rĂ´le au sein de sa sociĂ©tĂ© pour faire bouger les lignes du digital. Des insights prĂ©cieux que vous pourrez comparer au fur et Ă  mesure que les portraits s’Ă©graineront dans les semaines Ă  venir.

 

bnp paribas leasing solutions

En une phrase, comment définiriez-vous la notion de transformation digitale ?
Réfléchir différemment ou disparaitre. Nous sommes face à un obligatoire changement de mindset. Jusque-là, les contraintes de mise en œuvre de solutions technologiques conféraient aux entreprises une certaine tranquillité voire une quasi exclusivité.  Aujourd’hui, ces mêmes entreprises ont perdu cet avantage, l’usage des technologies s’étant fortement banalisé. Les clients sont ainsi beaucoup plus difficiles à impressionner et donc plus exigeants. Séduire un prospect voire même garder ses clients devient un challenge.

Une transformation efficace doit donc être globale : tous les collaborateurs doivent être embarqués, chaque maillon de la chaine de valeur doit être revu.

Comment décririez-vous votre rôle de CDO ?
Mon rôle consiste à piloter ce processus de transformation et de veiller à ce que chaque action / projet / programme soit conforme à la vision que nous avons dessinée et validée collectivement en amont.

Je le fais à la manière d’un chef d’orchestre car nous avons fait le choix de loger les ressources allouées à notre transformation digitale dans les directions contributrices plutôt que de créer une direction ad hoc. Cela s’avère plus efficace car toute action est, par nature, immédiatement transversale ! Autre particularité chez nous, celle d’impliquer systématiquement notre « Change Manager (RH) » et notre « Communication Manager » : Car toute action doit être accompagnée et mise en avant.

Quelles difficultés rencontrez-vous au quotidien ?
Si chaque fonction (IT, Sécurité, Juridique, Conformité…) ne se comporte qu’en « gardien du temple » aucun projet réellement transformant n’est possible. Si par contre les équipes collaborent pour trouver des solutions équilibrées, c’est-à-dire tout à la fois transformantes mais dans une maitrise des risques satisfaisante, alors tout devient possible. Au quotidien, il est parfois plus simple et plus rapide de dire « Non » plutôt que de s’engager dans une réflexion collective. Ce sont ces réflexes que nous devons combattre inlassablement.

Pensez-vous qu’il faille être technophile pour exercer le métier de CDO ?
Disons que ça aide forcément ! Ne serait-ce que pour pouvoir discuter d’égal à égal avec vos départements techniques et challenger des positions parfois très protectrices et/ou pas suffisamment innovantes. Mais n’oublions pas que nous parlons de transformation : L’élément clé, c’est d’abord l’humain !

Pensez-vous que CDO est un métier d’avenir ?
Normalement non. Et paradoxalement, plus le CDO sera efficace, plus son poste sera éphémère… Lorsque toutes les composantes de l’entreprise auront intégré ce nouveau mindset (cf Q1), la transformation sera auto portée. Le CDO devra alors se trouver un nouveau challenge mais, s’il a réussi, il n’y a pas lieu d’être inquiet pour lui !

Quelle est pour vous la prochaine innovation qui risque de chambouler votre secteur d’activité ?
BNP Paribas Leasing Solutions finance les matériels des professionnels. Il est donc assez naturel de répondre « objets connectés ». Mais, dans un métier de service, si nous souhaitons continuer de nous développer avec efficience, l’apport de l’Intelligence Artificielle et des chatbots doit nous aider à concentrer au maximum nos ressources sur les opérations à valeur ajoutée.

Quels sont les enjeux de digitalisation de votre entreprise à l’heure actuelle ?
Pour éviter tout risque de désintermédiation, BNP Paribas Leasing Solutions a fait le choix d’être la « benchmark company » de son secteur : Le digital doit clairement nous aider à renforcer notre position de leader. Et si un modèle de type « Uber » peut exister pour le leasing… c’est à nous de l’inventer !

Citez-moi une marque/entreprise qui, pour vous, a clairement réussi à adresser les enjeux du digital ?
J’en ai plusieurs en tĂŞte mais je citerai spontanĂ©ment le groupe La Poste car, objectivement et compte tenu de son ADN, sa situation n’apparaissait pas très enviable Ă  l’heure du digital. Et mĂŞme s’il a Ă©tĂ© aidĂ© par un vrai booster de la transformation digitale – un risque rĂ©el de disparition – il n’en demeure pas moins que leur prise en compte des enjeux du digital, notamment Ă  travers Facteo, reste remarquable Ă  mes yeux.

Sans contrainte, vous avez la possibilité de commencer 3 projets de transformation dans votre entreprise : quels seraient-ils ?
Avec contraintes, nous venons de boucler quelques projets ou programmes structurants pour notre processus de Transformation comme le Reverse Mentoring, la mise en place du Home Office, de Flex Office ou encore l’équipement en devices tels ultra books, iPhones ou iPads.

Nous travaillons actuellement 3 sujets sous forme de proof of concept, mais la disparition de toute contrainte nous permettrait d’accélérer :

  • Sans contraintes de sĂ©curitĂ©, je mettrai en place un projet de datalake, localisĂ© sur un cloud, de manière Ă  ouvrir le champ des possibles en matière de dĂ©veloppement d’applications mobiles,
  • Sans contrainte lĂ©gales, je transformerai immĂ©diatement nos projets pilotes sur la signature Ă©lectronique en solution industrielle,
  • Sans contraintes culturelles, j’introduirai de la gamification jusque dans nos process mĂ©tier.

Quel projet de transformation vous semble le plus risqué et pourquoi ? Celui qui apporterait le plus de valeur et pourquoi ?
Tous les projets de transformation sont par essence risqués. Le risque auquel je suis personnellement le plus sensible est celui de l’évolution extrêmement rapide des emplois dans tous les métiers, de services ou d’industrie. La plupart des emplois de demain n’existe pas encore aujourd’hui. Et dans ce contexte, l’accompagnement des collaborateurs vers de nouveaux métiers, de nouvelles compétences sera à la fois un défi et un facteur clé de réussite. Mais pour BNP Paribas Leasing Solutions, je suis optimiste : l’automatisation de tâches répétitives et monotones que nos collaborateurs n’apprécient pas particulièrement leur permettra d’aborder des activités à plus forte valeur ajoutée, plus épanouissantes.

Quel est l’impact de la transformation sur la culture et l’organisation de votre entreprise ?
Pour ce qui nous concerne, c’est très clairement une évolution très positive du mindset : Un passage de la crainte à une « envie d’en être ».

Même si cela demande confirmation et amplification, nous constatons clairement une diminution du fonctionnement en silo, maladie historique des grandes entreprises. Notre fonctionnement est de plus en plus transversal. Non seulement les « bonnes idées » viennent désormais de partout mais elles sont aussi poussées dans un but de partage et non pour affirmer la supériorité de tel ou tel direction/département. C’est ce qui me fait dire que nous avons « passé le point de bascule » et que, désormais, les forces vives de l’entreprise poussent pour accélérer le processus.

Demain, qu’est-ce qui vous fera dire que votre entreprise a réussi sa transformation ?
Réussir sa transformation digitale est, pour beaucoup, une question de survie : Donc, si demain nous sommes toujours leader européen, c’est que nous l’aurons réussie.

Quel livre vous a récemment le plus influencé ?
« L’innovation Jugaad » de Navi Radjou (Jugaad pour débrouillardise). Très bonne illustration de la position pionnière qu’occupent les pays émergents en matière d’innovation frugale : « comment faire plus avec moins » ou encore « Moins de ressources + davantage de liberté = Créativité ».

LinkedIn : http://www.linkedin.com/in/françois-régis-martin-26090222
Site Internet : https://leasingsolutions.bnpparibas.fr

#PortraitDeCDO – François-RĂ©gis Martin – BNP Paribas Leasing Solutions from OCTO Technology

Retrouvez les derniers #PortraitDeCDO

#PortraitDeCDO – Laurent Assouad – AĂ©roport de Lyon from OCTO Technology

PortraitDeCDO – BĂ©nĂ©dicte AndrĂ©-Bazzana – Le Conservateur from OCTO Technology

#PortraitDeCDO – Christian Buchel – Enedis from OCTO Technology

PortraitDeCDO – Juliette Bron – Macif from OCTO Technology

Catégories: Blog Société

DockerCon 2017 : retour sur les annonces

“Everything’s bigger in Texas”

Cette année, c’est à Austin, la capitale du Texas et le pays du BBQ, que se tenait du 17 au 20 avril la grand-messe de la marque à la baleine : la DockerCon. Et comme tout est plus grand au Texas, Docker avait concocté un ambitieux programme réunissant quelques 5500 participants autour de 125 sessions.

 

Au menu de cette édition 2017, Docker a levé le voile sur les annonces suivantes :

Jour 1 : tourné vers les produits communautaires

●      “Multi-stage builds” : avec comme objectif d’avoir des images plus petites

●      LinuxKit : un système d’exploitation minimaliste pour héberger des containers

●      Hyper-V pour linux : l’hyperviseur de Microsoft supporte désormais de l’isolation pour des containers Linux

●      Moby Project : possibilité donnée aux développeurs de créer leur propre plateforme de containers (cette annonce est détaillée dans la suite de l’article)

Jour 2  : tourné vers les produits entreprise

●      Partenariat avec Oracle : Oracle est dorénavant disponible dans le Docker Store !

●      Modernize Traditional Applications (MTA) Program : pour permettre aux entreprises de porter leurs applications traditionnelles vers des containers

 

DĂ©cryptage des grandes tendances de cette Ă©dition Le projet Moby

Avec l’annonce du projet Moby, Docker offre un framework pour construire et assembler sa propre plateforme de container : moteur de conteneurisation, système de logging, networking, orchestration. Il devient ainsi possible de remplacer chacun des composants de l’architecture de référence par celui de son choix :

Source : containerd.io

Docker CE sera désormais un assemblage de référence basé sur une version de Moby. Le Github historique du projet Docker (github.com/docker/docker) redirige dorénavant ses utilisateurs vers celui du projet Moby (github.com/moby/moby).

Depuis sa version 1.12, Docker intégrait Swarm directement dans le moteur. Cela avait été décrié par la communauté et perçu comme une volonté de Docker d’imposer son orchestrateur. Avec Moby, Docker vient donc donner la possibilité de construire sa propre distribution avec d’autre composants. Pour illustrer cela lors de sa Keynote, Docker a fait une démonstration de Moby utilisant Kubernetes comme moteur d’orchestration !

Docker à l’assaut des applications Legacy

C’est un mouvement de fond qu’opère Docker avec la volonté de se tourner vers les applications traditionnelles, et ceci avec plusieurs annonces. Cette tendance est expliquée par Ben GOLUB, CEO de Docker, pour qui le bi-modal IT est un non-sens : toutes les applications doivent avoir des cycles de vie courts.

 

Docker travaille donc avec les éditeurs historiques pour porter les applications traditionnelles dans des containers de façon sécurisées et rapides. Le Modernize Traditional Applications (MTA) Program s’inscrit dans cette optique. Ce programme ancre des partenariats avec Microsoft, Cisco, Avanade et HP.

Dans cette mouvance :

  • Oracle a annoncĂ© la mise Ă  disposition de ses produits dans le Docker Store.
  • Microsoft supporte maintenant l’isolation de container Linux sur Hyper-V.
  • IBM offre dorĂ©navant la capacitĂ© de faire tourner des containers dans Docker Enterprise Edition sous IBM z Systems, LinuxONE and Power Systems.
  • Et enfin, il est possible de convertir une image de machine virtuelle VMWare du format VMDK vers une image Docker (Dockerfile).

En synthèse, Docker souhaite donner la capacité d’accueillir les applications traditionnelles sur sa plateforme, tout en conservant les promesses de cette dernière.

Docker rassure sur la sécurité

Autre grande tendance de fond de cette édition : l’importance accordée aux sujets de sécurité. Pas moins de 18 sessions ont abordé ce thème. On retiendra en particulier les 3 suivantes :

  • Securing Containers, One Patch at a Time. Michael Crosby, ingĂ©nieur chez Docker, a expliquĂ© le processus appliquĂ© par l’entreprise en rĂ©action aux vulnĂ©rabilitĂ©s. Il a illustrĂ© ce dernier par l’étude de cas d’une vulnĂ©rabilitĂ© critique permettant de prendre la main en root sur l’host depuis un container (CVE-2016-9962).
  • Securing the Software Supply Chain with TUF and Docker. Justin Cappos et Santiago Torres-Arias sont chercheurs Ă  l’universitĂ© de New York. Ils ont prĂ©sentĂ© leur travail sur le protocole The Update Framework (TUF) permettant de sĂ©curiser encore d’avantage l’intĂ©gritĂ© de la distribution de packages logiciels. Ce protocole est utilisĂ© pour signer les images Docker avec Notary.
  • What Have Namespaces Done For You Lately? Liz Rice est ingĂ©nieur en sĂ©curitĂ© pour Aqua Security. En Ă  peine 40 minutes, cette dernière a dĂ©veloppĂ© en Go un moteur de conteneurisation basĂ© sur les mĂ©canismes d’isolation natifs au kernel : les Namespaces et les Cgroups.

Docker a donc cherché lors de cette conférence à rassurer sur la sécurité, comme pour répondre à une préoccupation du marché ?

Du côté de l’écosystème  

La DockerCon est aussi l’occasion d’avoir un bon aperçu de l’écosystème gravitant autour des containers dans un hall d’exposition regroupant plusieurs dizaines de sociétés (startups, cloud providers et éditeurs).

Beaucoup de startups proposant des offres autour du monitoring étaient présentes. Cette tendance du marché répond à un besoin croissant d’avoir de la visibilité sur son cluster (là où la version communautaire de Docker ne répond pas au besoin). Cette prolifération des acteurs laisse présager d’une future consolidation du marché du monitoring de container.

Les éditeurs historiques étaient aussi largement représentés : IBM, VMware, Oracle, Citrix, Microsoft … Cette présence illustre la volonté de ces entreprises de se positionner sur le marché de la conteneurisation en accompagnant le client dans la migration de leurs applications traditionnelles.

 

En conclusion, cette conférence a été l’occasion pour Docker de faire des annonces structurantes sur son futur. Le projet Moby repositionne Docker comme un assembleur de composants permettant de construire une plateforme de containers.

Docker a aussi cherché à étendre son influence dans les grandes entreprises grâce à des partenariats avec les éditeurs traditionnels. Le message est limpide : Docker ne se limite plus aux applications micro-services !

Articles suggested :

  1. AWS re:Invent 2015 : retour sur les annonces et compte-rendus
  2. Petit-dĂ©jeuner : ITaaS ou l’infrastructure au service de ses projets – le mardi 8 dĂ©cembre
  3. Stratégie de placement de conteneurs Docker (partie 2)

Catégories: Blog Société

Introduction Ă  DevOps

Devops brain

Dans cet article d’introduction à DevOps je vous propose de revenir aux bases du mouvement DevOps : ses origines, motivations et principaux enjeux. J’aborderai les pratiques C.A.L.M.S. (Culture Automation Lean Measurement Sharing) bien connues par tous les “pratiquants” de ce mouvement.

Cet article est destiné tout d’abord à tous ceux qui veulent découvrir les pratiques DevOps et comprendre pourquoi DevOps est devenu quasiment indispensable pour tout nouveau projet agile. Les gourous de DevOps pourront également trouver quelques informations intéressantes pour rafraîchir leur mémoire.

Introduction DĂ©finition

Il n’existe pas de définition de DevOps unique et acceptée par tout le monde. Par conséquent, il y a des dizaines de définitions différentes visant à expliquer ce mouvement.

Voici la définition fournie par Wikipedia :

« Le DevOps est un mouvement visant Ă  l’alignement de l’ensemble des Ă©quipes du système d’information sur un objectif commun, Ă  commencer par les Ă©quipes de Dev chargĂ©es de faire Ă©voluer le système d’information et les Ops responsables des infrastructures. » (Wikipedia)

Cette définition, certes très brève, donne un bon aperçu permettant de comprendre de quoi il s’agit : une collaboration étroite entre les équipes des Devs et des Ops. Voici une autre définition que je trouve intéressante :

« DevOps est la pratique oĂą les ingĂ©nieurs de dĂ©veloppement (Dev) et d’exploitation (Ops) participent ensemble Ă  l’intĂ©gralitĂ© du cycle de vie de services : de la conception au support de production en passant par le dĂ©veloppement. »

Origines

L’histoire de DevOps commence en Belgique où Patrick Debois, ingénieur de développement, exerce depuis 15 ans les différents rôles suivants au sein de grandes entreprises : développeur, ingénieur réseaux, administrateur système et chef de projet. En 2007, il travaille en tant que testeur pour un grand projet de migration de datacenter. Il est amené à collaborer à la fois avec les équipes de développement et les équipes opérationnelles. Patrick est particulièrement frustré par le contraste entre les façons dont les Devs et les Ops travaillent et le conflit perpétuel entre ces deux mondes. Il est persuadé qu’il existe un moyen d’améliorer cette collaboration et de mieux s’aligner.

En 2009 Patrick assiste Ă  la prĂ©sentation « 10+ Deploys per Day: Dev and Ops Cooperation at Flickr » donnĂ©e par deux employĂ©s de Flickr – John Allspaw et Paul Hammond, lors de la confĂ©rence O’Reilly. Patrick est tellement inspirĂ© par cette prĂ©sentation qu’il dĂ©cide d’organiser sa propre confĂ©rence appelĂ©e Devopsdays Ă  Gand en Belgique en octobre 2009.

Depuis 2010 le Twitter hashtag #DevOps est la source essentielle d’information liée au mouvement.

Les RĂ´les

Avant de commencer notre “deep-dive” dans le monde de DevOps, rappelons-nous le rôle de chaque participant pour lever toute ambiguïté possible :

RĂ´le des Devs : Quand on parle des Devs, on parle de toute personne impliquĂ©e dans la fabrication du logiciel avant qu’il n’atteigne la production : les dĂ©veloppeurs, les gestionnaires de produits, les testeurs, les Product Owners et les QAs.

Rôle opérationnel : Il s’agit de tout le monde impliqué dans l’exploitation et la maintenance de la production: les ingénieurs systèmes, les DBAs, les ingénieurs réseaux, le personnel de sécurité, etc.

Les DĂ©veloppeurs (Dev) sont chargĂ©s de produire de l’innovation et dĂ©livrer les nouvelles fonctionnalitĂ©s aux utilisateurs dès que possible. Les IngĂ©nieurs d’opĂ©rations (Ops) sont chargĂ©s de s’assurer que les utilisateurs ont accès Ă  un système stable, rapide et rĂ©actif :

  • Les Dev recherchent des changements ;
  • Les Ops recherchent la stabilitĂ© organisationnelle.

Bien que le but ultime de Dev et Ops soit de rendre l’utilisateur satisfait (et potentiellement heureux, client payant) des systèmes qu’ils fournissent, leurs visions sur la façon de le faire restent diamĂ©tralement opposĂ©es.

Mur de confusion

Dev vs Ops Dev vs Ops

Quand les Dev et Ops vivaient dans leurs mondes isolés, cette opposition ne posait pas de problème. Les deux travaillaient « on a schedule » en collaborant seulement pendant les rares phases des releases. Les Devs savaient qu’ils devaient délivrer toutes les fonctionnalités désirées pour le jour « J », sinon il leur fallait attendre le prochain créneau. Et les Ops avaient suffisamment de temps pour tester les nouvelles fonctionnalités avant de les envoyer en production. Ils pouvaient ensuite prendre des jours, voire des nuits, pour déployer ces releases aux utilisateurs.

Maintenant les choses ont changé, radicalement !
Les contraintes business ont Ă©voluĂ© d’une telle manière que les utilisateurs veulent les nouvelles fonctionnalitĂ©s très rapidement. Avec l’intĂ©gration et la livraison continue les dĂ©veloppeurs font de nouvelles releases chaque jour. Il n’y a plus de jour « J » pour dĂ©livrer le produit comme auparavant.

Les Ops ne peuvent plus prendre des jours pour déployer des fonctionnalités une fois qu’elles ont été testées, néanmoins ils doivent maintenir la stabilité.

Dev AND Ops

DevOps et ses pratiques visent Ă  mettre fin Ă  cette bataille entre DĂ©v et Ops – pour parvenir Ă  l’Ă©quilibre entre l’innovation et la stabilitĂ©. Dev et Ops doivent comprendre les bĂ©nĂ©fices des paradigmes DevOps. Ils ont besoin de changer juste assez pour commencer Ă  travailler ensemble et Ă  trouver le bon alignement entre Dev et Ops dont leur organisation a besoin, et de s’amĂ©liorer Ă  partir de lĂ .

Ce que DevOps n’est pas

Nous avons beaucoup d’outils pour le dĂ©ploiement, le monitoring, etc., mais DevOps ne se limite pas Ă  leur utilisation. Il s’agit des changements organisationnels profonds qui peuvent ĂŞtre appuyĂ©s par ces outils.

Le cycle de vie d’un logiciel Le cycle de vie traditionnel

Le besoin en DevOps est nĂ© de la popularitĂ© croissante du dĂ©veloppement en mode agile qui conduit Ă  un nombre accru de versions. L’un des objectifs de DevOps est d’Ă©tablir un environnement qui favorise les release fiables, dĂ©livrĂ©es plus frĂ©quemment et plus rapidement. Essentiellement, les mĂ©thodes agiles ont Ă©tĂ© utilisĂ©es uniquement pour la partie de dĂ©veloppement de logiciel. Les Ops n’étaient pas habituellement inclus dans ce processus.

Par la suite, le code a Ă©tĂ© donnĂ© aux Ops – ou plutĂ´t jetĂ© par-dessus le Mur de la Confusion.

Mur passage de code

Cycle de vie DevOps

Alors vous pouvez demander « en quoi le cycle de vie de DevOps est-il différent ? »

Keep calms

Il peut ĂŞtre rĂ©sumĂ© avec l’acronyme C.A.L.M.S. :

  • Culture
  • Automation
  • Lean
  • Measurement
  • Sharing
Culture

DevOps est plus qu’un simple outil ou un changement de processus. Il exige le changement de la culture organisationnelle. Ce changement culturel est particulièrement difficile Ă  cause des rĂ´les conflictuels des dĂ©partements. Les Ops recherchent la stabilitĂ© organisationnelle ; les dĂ©veloppeurs cherchent les changements ; et les testeurs cherchent Ă  rĂ©duire les risques. Faire travailler ces groupes de manière cohĂ©rente est un dĂ©fi crucial de l’adoption de DevOps dans l’entreprise.

Une grande source d’inspiration pour DevOps est l’Agile, et l’un des points-clĂ©s agiles dit :

« Les individus et les interactions plutôt que les processus et les outils »

Automation

Les machines sont vraiment bonnes à faire la même tâche encore et encore.
Automatiser autant que possible ! C’est quelque chose que les Ops ont fait pour rendre leur travail plus facile, mais qui n’a pas Ă©tĂ© reconnu comme une fonction vitale de l’organisation. Aujourd’hui l’organisation peut avoir des milliers de serveurs. Ă€ cette Ă©chelle cela n’est plus gĂ©rable Ă  la main. Nous avons besoin d’automatisation pour faire le travail.

Lean

« Lean » est Ă©galement la source d’inspiration pour la culture DevOps. Lean est centrĂ© sur la rationalisation des opĂ©rations, en rĂ©duisant les dĂ©chets et maximisant la valeur du client.
Lean dit qu’il est indispensable d’amĂ©liorer l’ensemble du flux et non seulement certains points dans le pipeline de production.

Les équipes Devs et les équipes Ops doivent trouver des moyens pour réduire les déchets et rationaliser les processus en entier.

Measurement

Si vous voulez amĂ©liorer quelque chose, vous devez ĂŞtre capable de le mesurer. Supposons qu’une nouvelle version du logiciel devrait rendre l’application plus rapide. Comment savez-vous qu’elle est plus rapide ? Le seul moyen est de le mesurer.

Dans les organisations informatiques traditionnelles, la surveillance des infrastructures Ă©tait la responsabilitĂ© des Ops. Cette approche est quand-mĂŞme rĂ©ductrice, car le service ne se limite pas Ă  un ensemble de serveurs. Avec la participation de l’Ă©quipe de dĂ©veloppement nous pouvons fortement amĂ©liorer le monitoring. Les dĂ©veloppeurs peuvent s’assurer que l’application exporte des donnĂ©es utiles.

Sharing

Il est très important d’aligner toutes les parties prenantes sur les mĂŞmes objectifs – les pratiques et les flux. Tous les intervenants devraient participer et travailler ensemble pour formuler les objectifs finaux, car cela crĂ©e le sens de la propriĂ©tĂ©. Les gens sont prĂŞts Ă  travailler ensemble quand leurs pensĂ©es et leurs opinions sont entendues.

  • Il est important d’Ă©liminer les goulets d’Ă©tranglement Ă  l’intĂ©rieur des dĂ©partements ou entre eux ;
  • Il est Ă©galement important de partager les avantages entre les Ă©quipes.
Conclusion

Le Cycle Devops

L’automatisation des tests unitaires et des tests d’integration est l’IntĂ©gration Continue ! Cela aide au dĂ©veloppement itĂ©ratif et assure que les changements des nouvelles fonctionnalitĂ©s ne cassent pas d’autres fonctionnalitĂ©s. L’automatisation de tout le processus jusqu’Ă  la “release” est couverte par la Livraison Continue. Pour s’assurer que tout fonctionne bien et amĂ©liorer l’ensemble des processus au fil du temps, il est nĂ©cessaire de tout Mesurer (Monitoring). Pour que cette mesure soit possible il est nĂ©cessaire d’avoir une bonne Communication dans la Culture du Partage et de la Collaboration, quand toute l’Ă©quipe est impliquĂ©e.
Avoir de l’automatisation c’est bien, mais ce n’est qu’en la combinant avec la culture de la communication et la collaboration entre les Ă©quipes qu’on obtient l’Approche DevOps pour le cycle de vie du logiciel.

Dans notre prochaine article nous allons continuer le deep dive dans le monde DevOps avec l’infrastructure-as-code.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux