Tag :CloudBees

Sacha Labourey nous parle de cloud

Le Lyon JUG accueille le 18 octobre prochain Sacha Labourey pour un talk intitulé “Développement dans le cloud”. Sacha est CEO et fondateur de CloudBees, une plate-forme Java pour le Cloud qui couvre l’ensemble du cycle de vie d’une application : de son développement à sa mise en production. Elle permet notamment le stockage de code, d’artefacts Maven, l’exécution de builds et de tests basés sur Jenkins ainsi que le déploiement d’applications en production, le tout de manière intégrée.
Agnès Crépet et Alexis Hassler, tous deux membres de la team du Lyon JUG ont posé quelques questions à Sacha, pour vous mettre l’eau à la bouche avant sa session à Lyon !

@SachaLabourey Quand on demande à Sacha de se présenter voici ce qu’il nous répond : “Je suis né en 1975 à Neuchâtel, en Suisse. Après un bac socio-économique j’ai rejoint les rangs de l’École Polytechnique Fédérale de Lausanne où j’ai effectué un master en informatique. Durant mes études, j’ai créé ma première boîte, Cogito Informatique. J’avais pour but d’entrer dans le monde du travail mais également … de payer mes études :) ! Après mes études, j’ai continué à faire du consulting dans le middleware puis me suis focalisé en 2001 sur l’aventure JBoss. D’abord en tant que développeur du clustering, puis en devenant GM Europe de JBoss, et finalement CTO en 2005. Après l’acquisition de JBoss par RedHat, je suis devenu co-GM de la division middleware chez RedHat, société que j’ai quitté en avril 2009. Après quelques mois de repos pas du tout reposants, j’ai commencé à réfléchir à ce qui deviendra plus tard CloudBees, qui a été formellement démarré le 1er avril 2010. Je vis toujours à Neuchâtel et travaille avec une équipe répartie sur 6 pays et 3 continents, ce qui rend donc la question géographique très relative.”
Nous vous invitons pour découvrir un peu plus Sacha à aller visiter son blog, fort intéressant (avec beaucoup d’articles sur le cloud, vous l’aurez deviné !)

Agnès & Alexis: Quelle est la cible des clients de CloudBees ? S’agit-il d’entreprises de tailles moyennes ou de plus grande envergure, de sociétés de services, d’éditeurs, d’entreprise déjà sensibles à l’open source ?

Sacha: Nous avons des clients de taille très différente, notre solution n’est pas spécifique à certains types de sociétés. Néanmoins, étant donné que notre offre est uniquement disponible dans le cloud public aujourd’hui, il est évident que les projets n’ayant pas besoin d’accéder à des ressources se trouvant sur un réseau protégé (bases de données, mainframes, etc.) sont clairement avantagés, ce qui est statistiquement plus le cas pour les petites structures ou, dans un domaine particulier, les sociétés développant des applications pour mobiles par exemple.

Agnès & Alexis: Est-ce que CloudBees peut vraiment être concurrentiel sur son offre RUN@Cloud, vu la taille des autres concurrents PAAS (GAE, Amazon Beanstalk) ? Comment RUN@Cloud se démarque de ces mastodontes, mais également d’autres comme Cloud Foundry?

Sacha: Ces grosses sociétés ont évidemment l’avantage en terme de ressources et, du moins pour VMware et RedHat, elles disposent d’un accès privilégié aux développeurs Java. Néanmoins, ces sociétés ont également les inconvénients de leurs avantages : elles sont lourdes, innovent moins vite, sont moins focalisées sur les besoins des développeurs (et plus sur ceux des CIO), etc. Par ailleurs, ces sociétés disposent de revenus importants en entreprise et bien qu’il leur est relativement simple de proposer une offre dans le cloud qui soit gratuite et en béta – donc non concurrentielle – il leur est très difficile de transformer leur modèle économique en un modèle de type cloud: les modèles de ventes sont très différents, l’organisation interne doit être différente, il y a un fort désir de protéger les revenus existants, etc. Ceci représente l’un de leurs plus gros challenges. Il m’arrive régulièrement d’en discuter avec les vendeurs de ces sociétés: le modèle cloud représente un vrai danger pour elles.

Agnès & Alexis: Je pense que l’intégration continue (IC) se prête complètement à une offre cloud : à certains moments de la journée, on peut avoir besoin d’un grand nombre de ressources de calcul, mais à d’autres moments on ne les utilise pas du tout. Votre offre Dev@Cloud peut être donc très appropriée pour les équipes de développement qui veulent faire de l’IC sans être en charge de la maintenance de l’environnement, et en ayant surtout à disposition un environnement toujours performant et stable. Je pense que les meilleurs clients de Dev@Cloud sont donc les développeurs eux-mêmes (j’ai tant rêvé moi-même à des environnement d’IC stables et disponibles !). Le problème que l’on rencontre souvent quand on présente ce type de solution à nos décideurs ou aux personnes de la production, c’est la problématique de l’hébergement du code dans le cloud qui leur fait peur… Comment peux-tu m’aider à convaincre mes décideurs si je suis à court d’arguments ?

Sacha: Il est toujours intéressant d’observer que ces mêmes décideurs n’ont généralement pas trop de problèmes à mettre dans le cloud (sur salesforce.com) l’ensemble de leur pipeline de vente, la liste de leurs prospects, les produits qui les intéressent, etc. Les ventes et le marketing seraient donc des données moins critiques que du logiciel ? Je suis intimement convaincu du contraire, à quelques rares exceptions près.
Par ailleurs, il y a ce sentiment de sécurité quand les données sont hébergées en interne: on peut voir la machine qui héberge les données, on connaît personnellement la personne qui s’en occupe, c’est rassurant. Hors, ces éléments sont justement ceux qui rendent une telle solution moins fiable à mon avis. Ainsi, la majorité des intrusions informatiques en entreprise sont liées à du “social hacking” (téléphonez à un employé en vous faisant passer pour l’IT et demandez-lui son mot de passe, etc.)
Je pense que les sociétés qui ont objectivement analysé la sécurité de leur propre installation, et non pas uniquement effectué une comparaison entre la sécurité estimée du cloud par rapport à une sécurité théorique maximale telle qu’on la trouve dans les livres, sont généralement beaucoup plus ouverts au cloud public. Par ailleurs, les sociétés du cloud, bien que pas infaillibles, sont extrêmement sensibles à ces problèmes, elles savent quelles pourraient être les conséquences d’une intrusion ou de pertes de données.
Beaucoup de travail reste bien évidemment à faire de la part des sociétés actives dans le cloud afin de rendre cette infrastructure publique encore plus sûre. Notamment, un grand travail de transparence, de communication et d’éducation est nécessaire.

Agnès & Alexis: Une solution Cloud peut être très bien appropriée également pour les tests de performances. Je n’ai à priori pas besoin en continu d’une plateforme pour de tels tests, je n’en aurais besoin par exemple qu’en fin d’itérations de développement. Et pour une entreprise le fait de disposer d’un tel environnement, à l’image de celui de la production, de le maintenir, coûte très cher. Quelles solutions propose CloudBees sur cette problématique des tests de performances et sur quelle stack technique (outils de tests de performance pour la montée en charge, le monitoring, la persistance des métriques?)

Sacha: Pour le monitoring, nous proposons NewRelic à l’heure actuelle. Quand aux tests de performances eux-mêmes, nous sommes actuellement en discussion avec un certain nombre de partenaires afin de proposer cette offre, de la même manière que nous proposons aujourd’hui une offre de test de UI avec saucelabs.com.

Agnès & Alexis: CloudBees propose sa propre version “entreprise” de Jenkins, du nom de Nectar. Quelles sont les fonctionnalités proposées en plus par rapport à Jenkins ? Du point de vue stratégique, pourquoi en avoir fait une offre propriétaire ? Quel rapport entre les cycles des releases des deux projets ?

Sacha: La différence tient en plusieurs points:

  • Nectar est releasé tous les 6 mois et le passage d’une version à la suivante est testé et simplifié, ce qui intéresse fortement les entreprises qui n’arrivent pas à suivre avec les releases hebdomadaires actuelles.
  • Nous testons un certain nombre de plugins FOSS types avec Nectar, afin que nos clients soient assurés que la migration vers une nouvelle version de Nectar ne leur posera pas de problème. La compatibilité plugin-core est régulièrement un problème pour les entreprises.
  • Nous offrons un ensemble de plugins propriétaires qui intéressent particulièrement les entreprises, t.q. l’intégration avec VMware, le contrôle d’accès par rôles, etc.

A noter qu’un certain nombre de clients désirent conserver leur Jenkins pré-déployé actuel tout en profitant de ces plugins additionnels : ceci sera possible dès notre prochaine release de Nectar, dans quelques semaines.

Agnès & Alexis: [Cloud privé/Cloud public] Est-ce que le cloud public est économiquement viable ? Est-ce que ce ne serait pas pour beaucoup d’entreprise un moyen d’évaluer l’approche cloud avant d’acheter une solution cloud privé ?
Penses-tu que le cloud privé soit pérenne ? Ne serait-ce pas une période de transition avant le cloud public généralisé ?

Sacha: Peu de sociétés évaluent complètement le coût de leur hébergement actuel : superficie des locaux, travaux techniques, climatisation, électricité, personnel, matériel, logiciels, maintenance, etc. Quand le calcul est bien fait, je pense que le cloud public est d’ores et déjà plus concurrentiel qu’un hébergement privé pour bon nombre de sociétés et la différence ne va faire que s’accroître avec la compétition sur ce marché, les marges réduites, etc. Resteront ensuite les sociétés avec des besoins massifs et génériques de puissance de calcul i.e. des déploiements identiques sur des centaines de nœuds. Ceux-ci pourraient rester privés, mais ce sont des cas spécifiques.
Quand au cloud privé, et non pas uniquement de la virtualisation, celui-ci est encore très difficile à maîtriser en interne. J’ai notamment rencontré des banques qui effectuaient des déploiements privés de stacks IaaS: ceci était loin d’être simple pour arriver à en faire une vraie infrastructure “self-service” qui soit stable, déterministe, etc. Ces déploiements nécessitent des ingénieurs IT à la pointe du progrès. Hors ceux-ci ne sont rentables (notamment en mode 24/7) que pour des déploiements massifs.
Il ne faut pas oublier que le cloud public représente un risque fort pour bon nombre de professionnels de l’IT. Ceux-ci n’ont évidemment pas grand intérêt à accélérer l’adoption de clouds publics par leur entreprise. Qui veut noyer son chien, l’accuse de la rage :)

Agnès & Alexis: Est-ce que le cloud Paas Java est limité aux conteneurs Web, comme Tomcat ou Jetty ? Est-ce qu’un javaee@cloud est envisageable ? Si oui, quand pourrait-on en profiter chez CloudBees. Est-ce que le support Java EE Web Profile puis le support full Java EE sont envisagés (si oui sur quels serveurs ?) ? (question posée avant l’annonce officielle!)

Sacha: Le support de JavaEE6-WP est désormais disponible. Nous ne pensons pas fournir le support du profil complet mais nous ajouterons probablement un certain nombre de services additionnels (t.q. JMS) à l’offre actuelle. Pour le runtime du support JavaEE WP : JBoss 7 pour l’heure, mais ceci pourrait changer dans le futur. Nous essayons tant que possible de ne pas exposer l’implémentation du container – l’utilisateur ne devrait pas avoir à s’en soucier.

Merci Sacha!

Les inscriptions pour la session de Sacha au Lyon JUG le 18 octobre sont ouvertes !

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer