Note : 5 ; De bonnes histoires et d’excellents principes mais un manque d’unité.
Le but inavoué de ce livre était d’être la référence sur le devops. J’en veux pour témoin l’impressionnante liste de noms à l’affiche. Les auteurs de « IT Rev » ont développé leur vision du Devops déjà ébauchée dans « The Phoenix Project », il s’agit des « 3 voies » dans la pure lignée de la pensée Lean. Ce livre est consacré au développement de cette idée.
Le livre lui-même est de format un peu plus réduit qu’à l’accoutumé, mais il atteint les 350 pages hors annexes (celles-ci en ajoutent 100 de plus), le volume de matière est donc conséquent. L’ensemble est découpé fin : on compte 23 chapitres rassemblés en 6 parties. La première d’entre-elle est consacré aux 3 voies. 4 chapitres sur 45 pages couvrent le sujet. L’introduction et le premier chapitre donnent les grandes lignes du devops, ce qui pourrait se résumer à la réduction du lead time.
Les 3 chapitres suivants de cette première partie sont chacun consacré à une des voies des fameuses 3 voies. Le second chapitre est ainsi consacré au « flow ». Sans surprise, on retrouve ici les principes du Lean appliqué au Kanban : taille des lots, élimination du gâchis, etc. Toutes choses permettant à la fois de réduire le temps de cycle et de donner de la fluidité au processus. Le second chapitre attaque le principe du feedback. Il est plus vague, évoquant le Andon et le déplacement de la qualité vers le développeur. Enfin le chapitre 4 nous parle d’amélioration continue, évoquant la culture « générative » au sens de Westrum. Les pratiques évoquées tournent autour de l’expérimentation et de la généralisation des découvertes locales.
Note : 4 ; De l’intégration continue à devops ! Des points de vue de grande valeur, mais bien trop verbeux. Jolt Award 2011 !
Ce livre fait en quelque sorte suite au « continuous intégration » publié dans la même série. Ici, l’orientation est résolument « devops », ou comment aller du développement à la mise en production. Aussi le livre ne s’articule pas seulement autour des problématiques techniques, mais aussi de processus et des activités garantissant la mise en production : tests unitaires, tests d’acceptance, gestion des releases, gestion des environnements, etc…
La première partie appelée « fondations » évoque tous les prérequis à la déliverie continue. On y parle de tests, de gestion de versions, etc… Bref de toutes sortes de choses que l’on connaît déjà et déjà détaillées par ailleurs. C’est un peu long et verbeux. On en prend pour 100 pages. Au premier chapitre on s’évertue de mettre en lumière la vue « ancienne » du release management. Pas si ancienne d’ailleurs, avec ses « RC1 », « RC2 », etc. On le fait à l’aide d’antipatterns un peu tarte à la crème, pour au final introduire les qualités attendues d’un bon pipeline d’intégration. Le chapitre 2, « configuration management » traite de deux sujets : la gestion de version, où les auteurs sont opiniated sur le développement en banche principale, et les informations de configuration qui doivent être externalisées. Les deux sujets seront repris plus tard. Ces prises de position, même si elles piquent un peu sont plus que sensées.
Une grosse trentaine de pages est consacrée à l’intégration continue. Pas de révolution ici, on reprend des principes désormais bien connus : un build court, ne jamais laisser un build cassé, raccourcir la boucle de feedback en lançant le build d’intégration au plus tôt. C’est un peu long pour dire des choses que l’on connait déjà et qui ne sont pas le cœur du livre. Je ne m’attendais pas nécessairement à voir évoquer la stratégie de test, mais c’est bien le sujet du chapitre 4 qui clôt la première partie sur une quinzaine de pages. Ce sont des pages bien dépensées cette fois, car les auteurs font le tour du sujet assez efficacement en suivant le framework de Brian Marrick. Cela dit, on est cette fois encore, un poil en marge du sujet.
Je voulais vraiment en savoir plus sur CoreOS. Chemin faisant, je savais que je risquais une lecture qui pouvait s’avérer ennuyeuse pour moi, sinon hermétique. C’est surtout la brièveté de l’ouvrage qui m’aura permis de survivre, le texte n’étant vraiment pas fait pour moi.
Bref, le texte l’est avec seulement 175 pages et 10 chapitres (donc des chapitres assez courts en moyenne). L’ensemble est divisé en 3 parties. La première d’entre-elle « getting to know CoreOS » comprends 3 chapitres. Et on commence bien sûr par une introduction au système, d’une quinzaine de pages. Cette introduction doit nous donner une image de haut niveau de CoreOS, qui un OS « statique », dont les composants majeurs sont fleet et etcd. Mais pour moi, l’angle est déjà bien trop « système ».
Les 18 pages du chapitre 2 sont consacrées à faire fonctionner CoreOS sur une machine de dev, dans un environnement Vagrant, lui-même dans une machine virtuelle VirtualBox. En sachant que ce n’est pas un mais 3 CoreOs que l’on souhaite faire fonctionner, cela donne une idée de la configuration : pas vraiment une partie de plaisir pour moi. Je sombre encore un peu plus au chapitre 3 « expecting failure » qui rentre dans les arcanes d’etcd, le tout pimenté de configuration Ngnix !
Note : 7 ; Une histoire autour des principes Lean et Devops, dans la veine de « The Goal » d’Eli Goldratt.
Un hasard bienheureux m’a fait lire ce livre dans la foulée de « Turn The Ship Around ! ». Ce livre, c’est l’histoire de Bill. Bill hérite d’un poste de manager dont il ne veut pas, celui de VP des opérations. Ce livre est donc un roman, plutôt bien écrit qui plus est. Il amène Bill d’un poste de manager dont il n’a pas voulu à celui de « chief operation officier », conseillé en pointillé par Erik, qui deviendra son mentor.
Le style narratif, les personnages et le fil de l’histoire ne sont pas sans rappeler « The Goal » d’Eli Goldrath. Les auteurs ne s’en cachent guère, et le texte n’est pas un plagiat pour autant, car ce sont d’autres savoirs et d’autres découvertes vers lesquelles veulent nous emporter les auteurs.
Parmi les idées fortes du livre, il y a les « 3 voies » :
Comment créer un flux de travail rapide.
Raccourcir et amplifier la boucle de feedback, pour fixer la qualité à la source.
Créer une culture de l’expérimentation et de l’apprentissage.
Note : 3 ; Un focus quasi-exclusif sur l’aspect « opérations » qui rend la lecture bien ennuyeuse pour moi…
Le volet « opérations » n’est pas ma tasse de Thé. Pourtant les frameworks qui gravitent autour de cette problématique simplifiant le déploiement, le clustering et permettant l’infrastructure as code sont probablement les plus actifs et les plus novateurs des projets open source aujourd’hui. C’est à ce titre que je me suis intéressé à Mesos, non pour être capable de l’opérer, mais pour le comprendre et en saisir les concepts et la manière de l’utiliser.
Hélas pour moi, c’est bien autour de la problématique des opérations que s’articule ce texte. Et même sous cet angle, il ne paraît pas des plus didactiques. Voyons justement comment il se structure. L’ouvrage est long de 235 pages, découpé en 3 parties pour un total de 10 chapitres. La première d’entre-elles, « Hello Mesos » fait une trentaine de pages et compte 2 chapitres. Il s’ouvre sur « Introducing Mesos » qui compte lui-même une quinzaine de pages. Ce chapitre donne une vue de haut niveau sur les fonctionnalités que délivre le framework et sa place dans la stack système. Il s’agit là d’une bonne introduction et l’on comprends ce qu’adresse Mesos, bien que la façon dont il l’adresse reste fort abstraite.
Au chapitre 2, « Managing Datacenters with Mesos », compte également une quinzaine de pages. Il se concentre d’avantage sur l’usage et la dynamique de fonctionnement de Mesos, toujours à haut niveau. Illustré par le déploiement de Spark dans différentes configurations, le chapitre est très bien illustré mais on reste toujours sur sa faim : comment diable Mesos interagit-il avec les applications sus-jacentes ?
Note : 4 ; Assez clair, mais pourrait être plus pédagogique…
Docker est une des technologies qui monte, Manning ne pouvait laisser un vide dans son catalogue à ce sujet. C’est chose faite avec cet ouvrage de 270 pages. L’auteur maîtrise très bien son sujet et nous propose donc ce volume structuré en 12 chapitres regroupés en 3 parties.
La première partie est dédiée à la découverte de la containerisation. C’est la plus importante du livre, elle couvre 125 pages et occupe 6 chapitres. Le premier d’entre-eux est court d’une dizaine de pages. Il a pour but de présenter les principes généraux de Docker, son « pourquoi » ainsi que les principes généraux de la conteneurisation. C’est bien emballé. Le second chapitre nous projette côté utilisation de Docker, afin de faire tourner des softs dans des conteneurs, un peu dans tous les sens. On y utilise beaucoup la ligne de commande et l’on découvre les transitions d’états des conteneurs, le lancement d’un conteneur depuis un conteneur, etc.
Après le run, c’est à l’installation que l’on s’intéresse au chapitre 3. Sur 15 pages, on y découvre l’installation depuis un repository ou depuis un dockerfile et bien sûr les principes de base des layers. Les choses se complexifient au chapitre 4 avec la gestion du stockage (persistant ou non) et l’attachement de volumes dédiés ou partagés. Heureusement le propos est largement illustré.
Bootstraper un déploiement continu sur le cloud avec CloudBees
En 25 minutes, Henrik Kniberg nous fait la démonstration depuis zero de la création d’une petite webapp type « hello world » sous Eclipse, avec son test local avec Jetty et ses tests unitaires, vers la mise sous Git dans CloudBees, l’intégration dans Jenkins et le déploiement dans un sandbox, toujours sur CloudBees. Partant de là, on complexifie l’application en y intégrant une persistance avec MongoDB sur la base des services accessible depuis la plateforme SaaS !
La vidéo montre en totalité le processus de réalisation, étape par étape, y compris la correction d’erreurs, sans rien omettre ! Un véritable guide à suivre pour construire sa première application sur CloudBees !
Cette présentation de Kniberg est plutôt dédiée à ceux qui veulent découvrir l’agilité : développeurs et managers. Elle répond en terme simple au « pourquoi » et présente l’avènement des approches agiles par le manifeste: ses valeurs, ses principes et les approches logicielles sous-jacentes.
L’auteur présente le cycle agile comme hautement itératif et incrémental. Ce qui est vrai mais un peu réducteur.
C’est ensuite aux questions de planning, d’estimation et de vélocité que s’attaque Kniberg, avec des illustrations ma foi fort bien faites ! Cette partie me semble plutôt destinée aux managers. Elle joue en tout cas un rôle efficace d’introduction au « maximize value, not output ». Le point suivant me semble clé : donner à l’équipe un problème à résoudre et non une solution à implémenter … ou comment revenir au « start with why » de Simon Sinek ! Cette résolution de problème s’alimente de feedback, qui lui-même permet de maximiser la valeur et de réduire les risques : la cohérence de ce cycle est bien mis en valeur dans cette présentation !
Une équipe agile c’est une équipe pluridisciplinaire, et Kniberg en profite pour rebondir sur le modèle Spotify et la culture « être agile » d’une organisation.
L’agilité ne se limite pas au développement, il va jusqu’à la mise en production, une occasion de mettre en lumière les principe de déliverie continue. En amont, il implique les vrais utilisateurs au jour le jour.
Au niveau de l’organisation, le présentateur expose le « portfolio level Kanban », qui n’est pas sans rappeler les éléments développés dans Lean From the Trenches.
En conclusion : il y a un prix à payer à la mise en place de l’agilité (organisation, environnement, etc.) et « big is bad », aussi bien pour les projets, les fonctionnalités, les cycles ou les équipes !
Sacha Labourey n’est pas un inconnu pour moi. Pour vous non plus peut-être. Soat nous poposait une rencontre avec cette figure marquante du monde Java à la veille de Devoxx France (je sais, ça fait déjà un bail …), je ne pouvais que sauter sur l’occasion.
Pour ceux qui l’ignoreraient, Sacha Labourey fut le CTO de JBoss après le départ de Marc Fleury, mais c’est en tant que fondateur et CEO de CloudBees qu’il se présentait à nous ce soir-là.
En fait de présentation, j’ai hélas rarement mis de photo aussi médiocre sur mon blog, mais c’est ainsi. La voilà.
CloudBees propose une plateforme pour héberger la totalité du cycle de vie d’une application Java sur le cloud. En l’occurrence, il s’agit du cloud d’Amazon, mais ils travaillent activement à rendre leur plateforme indépendante de l’infrastructure du géant de l’e-commerce afin de donner plus de flexibilité au client.
Hardware as a commodity
A la base, il y a la conviction que l’on se dirige vers une commoditifaction (est-ce vraiment un mot ?) du hardware. Sacha Labourey évoque le parallèle avec l’électricité : si à ses débuts, il fallait posséder son propre générateur et gérer les aléas de la régularité de l’alimentation, aujourd’hui nous nous sommes “débarassés” du problème chez des prestataires. Nous n’avons plus que des prises de courant nous délivrant un courant normalisé, le reste est l’affaire de ce prestataire.
Ce mouvement inéluctable : spécialisation -> standardisation -> régulation, Sacha Labourey le voit s’appliquer aujourd’hui à l’infrastructure.
Doit-on aujourd’hui encore s’occuper des machines, de les configurer, gérer les mises à jours système et même les “piles logicielles” ? Existe-t-il une valeur spécifique à se construire sa pile logicielle spécifique ? Si elle existe, elle doit être marginale (du moins dans la plupart des cas) et ne justifie pas les efforts et le détournement de focus de la problématique métier que l’on souhaite adresser.
C’est là la proposition de valeur de CloudBees : rendre l’infrastructure aussi facile à exploiter qu’une prise électrique !
Cloud vs cloud vs cloud
On peut rappeler rapidement les 3 types de cloud proposés, ils sont déjà très connus:
IaaS : Ce sont les briques de base de l’IT. On pense à Amazon EC2, Rackspace, …
SaaS : Des solutions logicielles standardisées prêtes à l’emploi. Salesforce est probablement le premier nom qui vient à l’esprit.
PaaS : Il s’adresse aux développeurs. L’objectif est de ne plus avoir à gérer les serveurs et les services standard fonctionnant dessus : serveur d’application, load balancing, etc..
Le focus est sur le “S” final : voir les facilités comme des services, disponibles sous forme d’API. Cette dématérialisation offre aussi un avantage fort : la possibilité de faire des essais (donc des erreurs) et de commencer petit. On peut ainsi itérer rapidement sans devoir attendre des mises à disposition de serveurs et des installations logicielles. Elles sont prêtes et peuvent être exploitées tout de suite. Et être abandonnées tout aussi rapidement (le serveur ne finit pas à la cave).
Pour Sacha Labourey, une architecture typique d’entreprise serait la suivante :
Au niveau back-office : les systèmes “legacy”, très stables, intégrant peu d’innovation.
Au niveau front : des applications pour mobile (par exemple) communiquant avec un back-end évoluant très rapidement au rythme des nouvelles fonctionnalités disponibles dans l’appli mobile. Cette partie est peu stable et est le siège de beaucoup d’innovations
Une communication front / back selon les protocoles mis à disposition par le back-office
Aujourd’hui la partie front / produit est subordonnée aux frictions entre développeurs et départements “opérations”. Les personnes en charge des opération privilégient la sureté de fonctionnement et renaclent le plus souvent à déployer des solutions logicielles qui n’ont pas été validées en interne, ou en tout cas ne satisfont pas des critères d’acceptabilité.
PaaS et innovation
Pour améliorer la capacité à mettre en ligne, la tendance actuelle est le “devops”, faire travailler ensemble développement et opération et outiller les opérations de déploiement afin de pouvoir pratiquer très souvent des déploiement automatisés. Je fais là un gros raccourcis et ne rends probablement pas justice à ce qu’il y a derrière devops, mais l’idée est là.
CloudBees revendique du “no ops” ! Plusieurs facteurs sont nécessaire pour permettre cela. On verra aussi que c’est un peu une simplification, l’IT ne disparait pas.
Standardiser les environnements : à l’image de l’électricité délivrée en voltage et fréquence constants, la standardisation des environnements est un facteur clé. Chez CloudBees, ces environnements standards sont les ClickStacks.
Travailler en SLA : pour pouvoir se passer d’ops, il ne faut pas avoir à se soucier de contingences d’infrastructure telles que stockage, clustering, etc… Il faut pouvoir signer un engagement de performance, à charge du prestataire de faire les mises en oeuvre d’infrastructure nécessaires pour garantir cet engagement.
Avec le SLA vient la question du support : une plateforme intégrant des sous-systèmes tiers peut être sujete à des dysfonctionnements (ou des mauvaises utilisation) de n’importe lesquels de ces composants. Il est logique que le support de service intègre complètement le support ou la délégation de support de ces composants.
Bien sûr, cela n’a de sens que si l’on est capable de mettre cela en oeuvre non seulement sur l’environnement de production, mais aussi sur les autres environnements utilisés dans le cycle de développement : environnements de développement, d’intégration, de stagging, etc… Le support du cycle de vie de l’application est donc l’étape suivante logique. L’intégration continue y joue un rôle clé.
Cycle de vie applicatif et gouvernance
C’est Jenkins qui est au centre du cycle de vie applicatif chez CloudBees. Il faut dire que Kohsuke Kawaguchi, la figure emblématique de ce projet open-source est un des leaders techniques de CloudBees !
Aujourd’hui, la partie faible me semble être toute la partie acceptance testing, AB testing etc… Mais c’est déjà le point faible de pas mal de projets. CloudBees propose quand même un environnement de stagging permettant de tester ses applications en conditions réelles : beescloud.com
Dans cette image que Sacha Labourey nous dresse, nous voyons une entreprise avec de nombreux projets, sur chacun d’eux les développeurs font des choix indépendants transformant le système d’information en gigantesque tour de Babel. Justement ce que l’IT cherche à éviter et lui vaut cette image d’épine dans le pied. Quel doit être le travail et la position du département IT, alors ?
C’est ce que Sacha Labourey appelle l’IT pragmatique : laisser faire, mais rester informés. Puis travailler en consolidation des différents projets ensuite (comment ? mystère …). De toute façon, si on bloque les projets trouveront le moyen de passer quand même !
Donc l’IT ne disparait pas, mais elle cesse de s’occuper d’infrastructure pour se concentrer sur les workflow de données, de services, etc… Elle reste le gardien du temple.
Tirer les leçons
Sacha Labourey a une vision très radicale non pas de l’IT de demain, mais de celle d’aujourd’hui :
Passer son IT sur le cloud inquiète toujours. Mais la peur ne peut pas être une stratégie ! Rester organisés à l’ancienne peut nous valoir de voir un département de 20 personnes se faire griller la politesse par “4 punks dans une cave” comme le dit Sacha !
Il faut profiter des gains compétitifs que représentent des services prêts à l’emploi.
Aujourd’hui, les investissements ne prenant pas en compte le cloud sont déjà de la création de dette ! Méditez là-dessus mes amis…
Ce que j’en vois
Sacha Labourey nous a bien secoué sur une vision du développement se passant dans le cloud, en rupture avec nos habitudes actuelles. Et il est très convainquant sur l’aspect des choses que nous n’avons plus à prendre en charge…
Pour aborder cette rupture, il faut permettre la montée en compétence progressive des équipes. Le ClickStart que propose CloudBees s’apparente surtout à des assistants logiciels. Il faut apprendre à travailler avec son usine logicielle dans le cloud. D’après notre orateur de la soirée, cela va vite. Mais quand même…
Accepter la standardisation : c’est une condition sine qua non.
On peut avoir un développement produit dans le cloud. Mais qu’en est-il de la communication front-back, si le back-office est dans les murs de l’entreprise ? C’est très probablement un point faible. A moins que le back-office soit lui-même dans le cloud, ce qui est la solution préconisée par Sacha Labourey. Un tel choix nous amène rapidement à des considération de vulnérabilité de notre entreprise, dont les avoir ont quitté les murs pour être localisés … à des endroits que nous ne savons même plus localiser ! Mais ne sommes-nous pas déjà, voir plus, vulnérables avec l’informatique chez nous ? Il y a eu pas mal d’échange avec Sacha Labourey sur ce sujet et j’avoue que ces arguments ne manquent pas de fondements. Je ne vais cependant pas les développer plus avant, cela m’emmènerai trop loin.
La présentation de ce soir-là avait un ciblage très managérial, j’ai un petit regret là-dessus, surtout que notre orateur est un expert de haut niveau. Mais ce point m’était connu à l’avance, je n’ai donc pas de regrets à avoir.
Si vous avez le courage de voir le contenu complet, la video a été mise en ligne par Soat.
Il vous faudra un peu de la persévérance, car la video dure 2h30 … et contrairement à ce que Sacha annonce au début, il oubliera de répéter les questions !
Il me reste à remercier Soat pour cette opportunité d’en savoir plus sur le développement sur le cloud en général et sur Cloudbees en particulier, avec l’un des grands noms du monde Java.
