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.

Soat a également mis en ligne sur son blog une présentation plus technique de CloudBees en détaillant les étapes de mise en oeuvre.