J’ai profité d’un passage en Suisse Romande pour assister à la réunion du 12 mai 2011 au JUG de Lausanne. Le sujet de la soirée était le plate-forme CloudBees, présentée par son fondateur, Sacha Labourey. Et bien que j’aie raté le début de la présentation, je dois dire que j’ai été convaincu par la pertinence de l’offre et par la vision de Sacha sur les services dans le nuage à apporter aux développeurs. J’ai donc fait un essai pour mieux comprendre le contenu de l’offre.

Ce billet retranscrit mon ressenti suite à la présentation et à mes premiers essais. Pour une vision plus large des solutions de développement dans le nuage, je vous renverrais vers le très bon article de Kalistic sur le sujet.

CloudBees : la société et l’offre

Pour ceux qui n’ont pas suivi l’épopée de JBoss, Sacha en était le CTO et responsable Europe. Il est resté CTO de JBoss après le rachat par RedHat, puis, en 2009, a quitté pour créer CloudBees un an après.

La société CloudBees est composée d’une vingtaine de personnes, avec un recrutement haut de gamme, avec pas mal d’anciens de JBoss et de Sun, dont Kohsuke Kawaguchi, le créateur de Hudson / Jenkins.

L’offre de CloudBees est constituée de deux parties :

  • pour les développeurs, DEV@cloud fournit <strike>Hudson</strike> Jenkins dans le cloud, avec des repositories Maven et de code source, git ou svn ;

  • pour le déploiement, RUN@cloud fournit un tomcat dans le cloud, avec une base de données MySQL.

DEV@cloud

La première offre mise en ligne par CloudBees était DEV@cloud. L’idée derrière cette offre est de fournir un service de build et d’intégration en ligne, autour de Jenkins.

Une fois enregistré, CloudBees nous fournit un accès à un Jenkins dans lequel on configure nos projets de façon standard. La seule différence, c’est que les builds sont envoyés sur des machines virtuelles instanciées dans le nuage, plus précisément sur Amazon AWS. Le repository du projet peut être hébergé sur Cloudbees, avec Subversion ou Git, ou à distance, sur GitHub par exemple. Les artefacts peuvent aussi être installés dans un repositoy Maven sur Cloudbees.

Tout ça est disponible par quelques clics, sans aucun effort d’installation. Il suffit de quelques minutes lancer un projet.

DEV@cloud s’intègre aussi sur le poste de travail du développeur, avec un plugin pour Eclipse qui permet de suivre et piloter les builds directement son IDE. Aucune intégration n’est proposée pour Netbeans ou IntelliJ, mais comme le kit utilisé est open source, la porte reste ouverte aux amateurs.

Build du tutoriel

Pour tester le service, j’ai réutilisé le projet que j’avais réalisé pour le tutoriel JSF - Spring - Hibernate, pour lequel j’avais déjà mis à disposition une version mavenisée, sur GitHub.

J’ai donc créé un nouveau projet dans Jenkins, déclaré mon référentiel de code GitHub et configuré la version de Maven. Le premier build a été un échec…​ Cet échec n’est pas dû à CloudBees, mais à une mauvaise conception de mes tests qui ne sont pas vraiment unitaires et qui requièrent un connexion à une base de données. Pour faire passer mon build, je désactive mes tests. Je sais que ce n’est pas bien, mais si les tests sont pourris…​

mvn clean install -Dmaven.test.skip=true

Première victoire : mon build passe. Je peux même déployer mon artefact sur mon référentiel privé fourni par Cloudbees.

Après cette réussite trop facile, je vais revoir mes ambitions à la hausse et m’attaquer à RUN@cloud.

RUN@cloud

Cette partie de l’offre de CloudBees permet de déployer une application sur un serveur Tomcat 6, avec une base de données MySQL 5. Là encore, il n’y a aucun effort d’installation à fournir. En contrepartie, la configuration est figée.

L’accès à la base de données depuis l’application est géré par une datasource dont la configuration est faite dans un fichier spécifique à CloudBees (WEB-INF/cloudbees-web.xml). Pour l’administration de la base, il n’y a pas grand chose en ligne ; par contre, cette base est accessible à distance ce qui permet d’utiliser les outils classiques depuis le poste de travail. Il est aussi possible de brancher une application sur une base de données distante.

Pour le déploiement, on peut le commander depuis DEV@cloud, avec maven. On peut aussi le commander à distance, avec Maven ou le SDK.

Déploiement du tutoriel

Pour le déploiement de mon application, j’ai donc modifié la commande du build.

mvn bees:deploy -Dmaven.test.skip=true -Dbees.apikey=...
                -Dbees.secret=...
                -Dbees.appid=sewatech/tutjsh

J’ai aussi ajouté le fichier WEB-INF/cloudbees-web.xml :

<cloudbees-web-app xmlns="http://www.cloudbees.com/xml/webapp/1">
    <appid>sewatech/tutjsh</appid>
    <resource auth="Container"
              name="jdbc/sw-uni"
              type="javax.sql.DataSource">
        <param name="username" value="sewatech" />
        <param name="password" value="pwd" />
        <param name="url" value="jdbc:cloudbees://sw-uni" />
    </resource>
</cloudbees-web-app>

Ça fonctionne, mais ça me gène quand même d’avoir mon mot de passe en clair dans un fichier de configuration inclus dans le code source du projet. Surtout pour une base de données accessible à distance.

Et pour être tout à fait honnête, j’ai dû faire quelques corrections dans mon application, car celle-ci tournait sous Tomcat 5.5 qui est plus laxiste que Tomcat 6.0. Ces corrections sont effectivement liées à la version de Tomcat et pas au fait de déployer sur CloudBees.

La mise en ligne de mon application a été presque aussi simple que son build ; juste quelques lignes de documentation à lire. Cette simplicité ne sera peut-être plus aussi flagrante avec une application réelle car dans ce cas, on se confrontera peut-être aux contraintes du cloud.

Combien ça coute ?

C’est gratuit pour commencer, avec des capacités limitées : 2Go de stockage, 300 minutes de build par mois et quelques autres limitation. Pour passer aux choses sérieuses, les souscriptions vont de $15 à $100 par mois. Tous ces chiffres sont valables au moment de la rédaction du billet (05/2011) et peuvent évidemment évoluer.

Pour qui ?

Pour moi ! Ou n’importe quel prestataire de service qui ne veut pas s’embêter avec un infrastructure. Pour chaque nouveau projet, quelques clics suffisent pour avoir un Jenkins opérationnel, avec un déploiement accessible par le client. Ensuite, le modèle peut être affiné : faut-il ouvrir un compte par client, par projet ? Faut-il tout mutualiser sur le même compte ? Comme souvent avec ce type de service, ça ouvre des perspectives qu’il faut affiner avec de la pratique.

On peut aussi penser au éditeurs en mode SaaS. La formule peut être intéressante pour lancer un nouveau produit en réduisant les coûts fixes.

Finalement, ça concerne n’importe quelle entreprise qui veut arrêter de s’embêter avec de l’infrastructure.

La suite

Le concept est en place, le nombre d’utilisateurs augmente, la société recrute régulièrement, et que des cadors. La concurrence aussi se mets en place, dans les différents créneaux du PaaS. Ce qu’on attend maintenant de CloudBees, c’est plus de fonctionnalités.

Le premier ajout qui me plairait, c’est le support de JavaEE 6, en particulier du Web Profile. Comme il semblerait que cette demande soit assez répandue, ça devrait arriver prochainement.

Les incidents récentes chez Amazon ont mis en évidences les limites du cloud. Un fournisseur de PaaS comme CloudBees a la possibilité d’amortir l’effet de grosses pannes en diversifiant ses fournisseurs IaaS et en permettant de déployer de façon transparente sur plusieurs plateformes. Ça aussi, ça semble être dans les plans.

Enfin, pour toucher les entreprises plus grosses et les projets plus importants, CloudBees devra améliorer le passage entre DEV@cloud et RUN@cloud. La simple opération bees:deploy devra intégrer un workflow, avec une gestion des autorisations affinée.