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.
J’attends incontestablement de la « signature series » d’Addison Wesley qu’elle ne comprenne que des ouvrages de référence. Ce n’est pas le cas ici. Certes, le livre effectue un bon travail pour introduire et convaincre les nouveaux venus des vertus de l’intégration continue, en édictant les principes de base (que j’estime pour ma part connus) et en hésitant pas à les répéter (ce qui est parfois nécessaire).
Cet aspect introductif est en fait l’objet de la première partie, longue de 100 pages. Bien qu’à mon avis la cible de ce type d’ouvrage ne soit pas d’introduire le sujet, mais une expertise sur la mise en pratique, je n’ai rien contre une petite introduction. Mais 20 pages auraient suffi, surtout si l’on considère la teneur. En fait, on y trouve un peu trop de propos de haut niveau, qui me rappellent certains des moins bons volumes de « l’Object Technology series » du même éditeur. Bref, j’arrive à la fin de cette partie, non seulement sans avoir rien appris, mais avec l’impression que j’en sais plus que les auteurs.
La seconde partie est dédiée au traitement en profondeur de l’intégration continue. Le découpage en chapitres est plutôt pertinent : intégration continue des bases de données, tests, inspection, déploiement et feedback. Hélas le traitement des différentes parties manque carrément de profondeur. Les auteurs abordent bien le « ce qu’il faut faire » mais assez peu le « comment faire », hormis quelques exemples de scriptes Ant. À noter, en passant, que la quasi-totalité de l’ouvrage est basée sur le postulat de l’utilisation de Ant et Cruise Control (et de leur équivalent .NET), je suis donc frustré (avec bien d’autres, certainement), moi qui utilise Maven et Hudson (ce dernier outil n’est même pas évoqué dans la liste des outils en annexe, peut-être parce qu’il aspire trop d’utilisateurs de Cruise Control ?).
Bref, on est non seulement déçu par l’absence de recettes concrètes, mais aussi par l’étroitesse des typologies de projets abordés. Je suis déçu également par le discours : n’y a-t-il donc qu’une seule façon d’appréhender l’intégration continue ? Les auteurs posent pourtant de nombreuses questions pertinentes qui sont autant d’obstacles à la mise en œuvre de l’IC, mais leur seule façon d’y répondre est l’objection. L’expérience nous montre pourtant que l’IC est quelque chose de facile à casser, jamais ce point n’est abordé. Les vraies questions sur la complexité de mise en œuvre de l’IC ne sont jamais évoquées : Commit en deux temps pour les IC cassant trop souvent, cadre technologiques ancien ou hétérogène, équipes nombreuse, build long ou tests volumineux.
Les auteurs se réfèrent souvent à deux textes : le livre de Brad Appleton sur les patterns de gestion de configuration et l’article de Martin Fowler sur l’IC. J’aurais aimé que ce texte ait la profondeur et la pertinence du « Patterns on Configuration Management ». Pour ce qui est de se référer à l’article de Martin Fowler, j’attends simplement mieux d’un livre de 220 pages que de se comparer à un article qui en compte une dizaine.
Donc, grosse déception. Passez votre chemin.
Référence complète : Continuous Integration, Improving software quality and reducing risk – Paul M. Duvall, with Steve Matyas & Andrew Glover – Addison Wesley / Signature series 2007 – ISBN : 0-321-336338-0 ; EAN : 978 0 321 33638 5
Note : 9 ; Comprendre enfin les impératifs de production sur l’architecture. Book of the year 2007 !
Pour être tout à fait honnête, je dois avouer que j’ai d’abord acheté ce livre d’avantage par confiance envers l’éditeur (Pragmatic Programmers) que pour le titre, qui ne me disait pas grand-chose. Bien m’en a pris, le livre s’est avéré une mine de connaissances.
Ce livre traite de l’architecture des applications d’entreprise. Mais plutôt que de se focaliser sur les qualités classiquement attendues de telles applications, l’auteur s’intéresse aux comportements de applications d’entreprise en production. Et il connaît particulièrement bien son sujet, ayant participé aux mises en production de très gros sites de e-commerce. De fait, le texte regorge « d’histoires horrifiques » arrivés en production.
J’ai conscience que mon appréhension des besoins des équipes de productions par rapport aux systèmes que je développe est superficielle. Nous sommes dans deux mondes séparés. Cet ouvrage vient confirmer ce pressentiment. Jusqu’à présent, je pensais que la meilleure chose que j’avais à faire par rapport à la production était de produire un système solide et stable (de bonnes considérations), et que la seconde meilleure chose à faire était de produire un système très, très solide (ce qui commence à devenir stupide). L’auteur nous assène une vérité : tous les systèmes, d’une manière ou d’une autre peuvent et vont finir par faillir. Le design des applications doit êtres orientés par rapport à cette vérité, en termes de stabilité et en termes de capacité et surtout en terme de reprise sur crash !
Les 334 pages du livre sont découpées en 4 parties formant 18 chapitres. Il regorge littéralement de conseils d’architecture et de design formulés sous forme de patterns et d’antipatterns. Une vraie mine d’or !
Je recommande cet ouvrage sans aucune réserve. L’auteur prend des positions importantes et intéressantes, éclairées par une d’incontestables compétence et connaissances. Il nous fait découvrir un nouveau point de vue et de nouvelles idées à intégrer dans nos designs et nos architectures.
Référence complète : Release It ! Design and deploy production-ready software – Michael T. Nygard – Pragmatic Bookshelf 2007 – ISBN : 0-9787392-1-3 ; EAN : 978 0 9787392 1 8
