Mardi dernier se tenait le traditionnel Paris JUG, recevant Patrick Chanezon venu nous parler du Cloud. Au passage, félicitons l’organisation qui est passée de JugEvent à EventBrite, beaucoup plus fiable (et qui m’a permis d’avoir une des dernières places libérées le jour même de la conférence).

Dans la nuit qui a suivi, Olivier et Nicolas ont respectivement publié des excellents comptes-rendus de cette soirée. Merci et félicitations à eux donc :

Voici donc, modestement, un petit compte-rendu de tests que j’ai eu l’occasion de faire sur deux des plate-formes dont il était question à cette soirée.

Cloud Foundry

Logo CloudFoundry

J’ai déjà eu l’occasion de parler de mes tests de déploiement d’une application Play Framework sur cette plate-forme, ici et . C’est un projet que j’apprécie beaucoup, pour plusieurs raisons :

  • il est Open Source, ce qui permet de monter une plate-forme de cloud privée (voire un « micro-cloud »)
  • il permet de faire tourner des applications de plusieurs types (Java, Ruby, NodeJS…), avec des frameworks associés, et le nombre de technologies supportées sera prochainement élargi (par exemple, la gestion native des applications Play est dans les tuyaux)
  • il est multi-services (MySQL, MongoDB, …)
  • il n’y a pas d’API spécifique à Cloud Foundry, ce qui évite de se lier avec la plate-forme au point de ne plus pouvoir en sortir facilement
  • il n’est pas dépendant d’une infrastructure particulière : on peut installer le système sur la couche de virtualisation que l’on souhaite : VMWare, VirtualBox, …
Je suis très enthousiaste concernant Cloud Foundry, et c’est pourquoi j’ai poursuivi mes tests. En particulier, en découvrant le langage Scala, j’ai déployé (toujours avec Play) un simple solveur de Sudoku (dont les sources sont accessibles sur GitHub). C’est à ce moment que Nicolas de Loof m’a proposé de déployer la même application sur son nouveau protégé, afin de comparer les deux solutions :

CloudBees

Logo CloudBees

Inscription

La procédure d’inscription est un poil plus compliquée que celle de Cloud Foundry (mais en même temps, on peut difficilement faire plus simple que le bouton unique de ce dernier). Rien de bien dramatique cependant : en moins d’une dizaine de minutes tout compris, on a un compte prêt à l’emploi. Voici donc mes premières impressions, en essayant de les comparer à ce que j’ai pu voir sur Cloud Foundry.

Dev@Cloud

Avec une application Play Framework, je n’ai pas vraiment pu tester cette partie. Cependant, j’espère avoir l’occasion de le faire prochainement : l’approche est intéressante ! Elle consiste à pouvoir construire son application et la valider dans les nuages. Le principe est d’empiler à la demande les services dont on peut avoir besoin autour de l’intégration continue Jenkins : dépôts Maven (Archiva), tests fonctionnels avec Selenium, analyse de qualité avec Sonar… CloudBees propose même de mettre sa gestion de configuration dans les nuages avec des dépôts Git (ou autres dont on ne doit pas prononcer le nom). Et la gestion de ces différents services dispose d’une interface très conviviale :

Chaîne des services CloudBees

Chaîne des services CloudBees

RUN@Cloud

Passons maintenant à la partie déploiement. Depuis une application Play, la procédure pour monter une application dans le Cloud est très proche de celle de Cloud Foundry : il suffit de configurer et d’utiliser le module dédié, Au moment du déploiement, comme pour Cloud Foundry, l’application est convertie en archive WAR, puis est chargée sur le Cloud via l’API du service.

30 minutes après le premier échange de tweets avec Nicolas, la même application était en ligne sur CloudBees (avec l’aide de François pour la correction de quelques bugs de la première version). Entre les versions Cloud Foundry et CloudBees, aucune ligne de code n’a été modifiée pour permettre le déploiement. Le déploiement est donc aussi simple sur les deux environnements. Et dans les deux cas, on n’est pas lié par des API propriétaires. Le coût de sortie est donc faible.

Un petit avantage va cependant à Cloud Foundry : il gère une liste complète des fichiers déjà déployés (quel que soit l’utilisateur les ayant mis en ligne), et permet de ne charger que ce qui n’est pas déjà connu en ligne (soit quelques Ko). Sur CloudBees, il n’y a pas cette liste globale : le premier chargement nécessite donc le transfert complet des 50 Mo de l’application. Les déploiement suivants se font par contre bien de façon incrémentale (ouf !).

Monitoring

Sur ce point, CloudBees gagne sans aucune discussion possible. Sa console d’administration est graphiquement très agréable, et permet un monitoring complet de l’application : requêtes, mémoire, temps de réponse, etc.

Console de monitoring CloudBees

Console de monitoring CloudBees

Au niveau de Cloud Foundry, il n’y a pour le moment quasiment aucune possibilité de monitoring, et uniquement via l’outil « vmc ». Il est ensuite possible de palier à ce manque avec des produits tierces : Hyperic, NewRelic, etc.

Mais n’oublions pas que Cloud Foundry est encore en phase de béta. On ne sait pas encore quel sera le mode de pricing de la version finale, ni quels seront les services associés mais cela m’étonnerait grandement qu’aucune solution de monitoring ne soit intégrée à l’offre commerciale.

Extensibilité

Une des choses qui m’a beaucoup séduit dans Cloud Foundry, c’est son extensibilité avec la possibilité d’utiliser les services que l’on souhaite (type de base de données, etc.). Sur ce point, CloudBees devrait proposer une approche similaire, en proposant des services partenaires. A l’heure actuelle, ce système de services est en place pour la partie DEV@Cloud, mais je ne sais pas ce qui pourra être rendu disponible sur la partie RUN. L’avantage est donc à Cloud Foundry pour la partie « services PaaS disponibles ».

Performances

Ma petite application de test n’utilise pas de base de données. Je m’attendais donc à ce qu’elle tourne de manière identique sur les deux environnements, d’autant plus qu’ils utilisent tous les deux des serveurs Tomcat pour l’exécution des applications Java. Or, les tests de monitoring que j’ai pu effectuer montrent que ce n’est pas le cas :

  • Sur Cloud Foundry, l’application ne descend pas sous la barre des 200 Mo de RAM consommés
  • Sur CloudBees, elle reste aux alentours des 60 Mo de RAM consommés
Cette différence peut sans doute s’expliquer par le fait que le Tomcat de Cloud Foundry est installé « out of the box », alors que celui de CloudBees a été largement customisé.

Conclusion

Sur la partie DEV@Cloud, CloudBees n’a pas de concurrent chez Cloud Foundry (je ne sais d’ailleurs pas s’il a un concurrent tout court…).

Pour la partie PaaS, CloudBees est moins « couteau suisse » que Cloud Foundry, mais en revanche mieux optimisé sur l’exécution de programmes Java.
Dans un nombre significatif de cas, mes besoins sont uniquement Java + base relationnelle. Si je dois héberger une telle application dans les nuages, les bonnes performances et les possibilités de monitoring me feraient préférer CloudBees… tout en sachant que si mes besoins évoluent, il n’y a pas d’adhérence forte à la plate-forme, et que je pourrai l’héberger facilement ailleurs.