Tag :Cloud

Retour sur l’EclipseCon France 2017

Les 21 et 22 juin avait lieu à Toulouse l’EclipseCon France. J’y participais pour la première fois grâce aux invitations que la fondation Eclipse a offert à Duchess France. J’avais la chance d’accompagner Aurélie Vache, bien connue des Duchess France et aguerrie à l’EclipseCon. Lire la suite

Meetup le 29 mars : Concevoir une application scalable dans le Cloud

Ne manquez pas cette session de notre série de meetups sur le Cloud Computing qui aura lieu le 29 mars dans le centre de Paris

Après AWS, c’est au tour de Microsoft de nous présenter sa solution Cloud : Microsoft Azure. Lire la suite

Découvrons Cloud Foundry!

Deux soirées plutôt qu’une! Le 19 février prochain, le Lyon JUG invite Eric Bottard pour un talk sur Cloud Foundry. Eric est Developer Advocate chez VMware, la société derrière Spring et Cloud Foundry. Passionné d’informatique depuis l’arrivée du TO7, il a notamment consulté pendant 10 ans autour des technologies Java. Maintenant, il va beaucoup mieux. Le lendemain, Eric revient, accompagné de Florent Biville pour un atelier sur Cloud Foundry, pour voir de prêt à quoi ressemble la bête! Florent est développeur chez Lateral Thoughts, la NoSSII transparente, fun et auto-organisée par une bande de geeks. Il n’a pas connu le TO7, mais il aime bien les technologies Java, les nouveaux langages et il va, ma foi, plutôt bien.

Pour vous donner tout de suite un avant-goût des soirées, allons poser quelques questions à Eric sur Cloud Foundry.

Eric Bottard

Cet interview a été préparé par la team « élargie » du Lyon JUG, Agnès CREPET, Cédric EXBRAYAT, Alexis HASSLER et Cyril LACOTE.

Lire la suite

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 !

Dernier AvantJUG avant les vacances !

Le Paris Jug organise mardi prochain une soirée « La mode cloud, collections d’été ». Elle sera animée par Patrick Chanezon, français d’origine parti travailler chez Google USA. Il dirige l’équipe en charge de la promotion des services Google dans le nuage (App Engine, Storage, Prediction, BigQuery, Go) et des outils (GWT).

Comme d’habitude, les Duchess organisent l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.

What’s next ?

D’ici deux semaines, les 26 et 27 mai aura lieu sur Paris What’s Next, conférence de deux jours autour de java, du Cloud, de NoSQL, de Clojure …

De speakers internationaux confirmés vont nous présenter des talks inédits orientés sur la question du futur des technologies. On y parlera par exemple de :

  • ElasticSearch par son fondateur Shay Bannon, moteur de recherche open source, distribué et RESTful.
  • Akka par Jonas Bonér, framework permettant d’écrire de gérer les applications concurrentes en utilisant entre autre les acteurs qui permet une vrai scalabilité, une tolérance aux fautes …
  • Le class loading par Jevgeni Kabanov, fondateur de ZeroTurnaround qui édite JRebel, un outil qui permet un rechargement à chaud des classes et qui se révèle d’un grand gain de temps de compilation. J’avais déjà eu une de ses présentations à Devoxx, très appréciée, désormais visible sur Parleys sur le fonctionnement des class loaders.

Le détail des sessions.

Nous vous y retrouverons nombreuses les 26 et 27 mai au grand Rex. Et cerise sur le gâteau, nous proposons à toutes les duchess une réduction de 25%, nous contacter pour plus d’infos !

Plus d’infos sur le site officiel

Bienvenue dans le monde d’Amazon Web Services!

izpackLe 17 mai prochain, le Lyon JUG propose une soirée autour d’Amazon Web Services. Le speaker, Fabien Bousquet, s’est prêté au jeu des questions/réponses et nous donne un avant-goût de sa session. Fabien est ingénieur R&D chez Kalistick. Il est responsable de l’infrastructure et de l’exploitation de la plate-forme, qui gère l’analyse de millions de lignes de code sur un environnement Cloud. Adepte de la polyvalence, il intervient également sur les développements Java et C#, qui sont sa première spécialité.
Cet interview a été préparé conjointement par Agnès et Cyril

@fafanoulele

Agnès & Cyril: Avant de parler d’Amazon Web Services, peux-tu nous en dire un peu plus sur toi, ton parcours? Qu’est-ce qui t’a mis la tête dans les nuages aujourd’hui ?
Fabien: J’ai un parcours des plus classiques en informatique. A la sortie de mes études, j’ai commencé comme développeur dans une SSII pendant 2 ans où j’ai touché un peu à tout. Ensuite je me suis lancé depuis 3 ans dans l’aventure Kalistick en tant que développeur dans l’objectif d’ajouter C# (.NET) à l’offre Kalistick. Ceci étant fait, je continue mon activité de développeur, mais je travaille aussi sur la partie infrastructure et hébergement de nos serveurs. C’est dans cette dernière activité que j’ai l’occasion d’utiliser Amazon Web Services (AWS).

Agnès & Cyril: Peux-tu nous situer AWS et ses produits dans l’écosystème Cloud ?
Fabien: AWS couvre un large spectre de services allant des services d’infrastructure (Iaas – bas niveau – machine …) à des services PaaS (haut niveau). On va donc pouvoir créer des serveurs virtuels (EC2), accéder à des espaces de stockage (S3), mais on va pouvoir aussi s’affranchir de l’infrastructure en utilisant le service Amazon Elastic Beanstalk en déployant directement une application Web Java. AWS donne aussi accès à des bases de données relationnelles (RDS), des bases de données NoSQL (SimpleDB), un content delivery network (CloudFront) etc…. En tout, 25 produits sont proposés par AWS. Tout le monde devrait trouver son bonheur !

Agnès & Cyril: Tu travailles pour Kalistick, peux-tu nous présenter cette société? Qu’est-ce que vous apporte AWS ? Pourquoi avoir choisi AWS plutôt que d’autres solutions ?
Fabien: Kalistick offre un service en SaaS qui permet de radiographier une application pour aider l’équipe de développement à améliorer la qualité en détectant les problèmes techniques, et l’équipe de test/validation à orienter son effort sur des zones à risques notamment pour les tests de régression.
Mais mieux que de longs discours, je vous propose de tester par vous même gratuitement notre offre sur https://cockpit.kalistick.com (hébergée sur AWS !) directement sur votre projet et en quelques minutes.

On s’est tourné vers AWS afin de bénéficier du Cloud :
– Elasticité : On peut moduler la puissance des machines en fonction des demandes. Nos serveurs d’analyse n’ont pas besoin de marcher si aucune analyse ne tourne mais au contraire, on doit augmenter le nombre de serveurs d’analyse lorsque il y a plusieurs analyses en même temps.
– A la demande : On ne paye que ce qu’on consomme réellement sans engagement. En effet, on a des pics de charge à certaines périodes de la journée.
– Réactivité : on dispose d’un nouveau serveur en quelques secondes sans aucun investissement.

Une autre raison nous a incitée à utiliser AWS : le fait de pouvoir monter des environnement de tests identiques très rapidement (pour qualification ou pré-production par exemple). On s’est rendu compte qu’au fur et à mesure de notre développement, nos machines internes limitaient notre capacité de test car elles étaient trop différentes de nos machines de production et ne permettaient pas d’exécuter de vrais tests quotidiennement. Faire cela sur nos serveurs internes devenait trop lent et trop coûteux, et cela ralentissait le déploiement de nos nouvelles versions.

Agnès & Cyril: Aller c’est décidé, je veux me mettre à AWS. En tant que développeur, quel est l’outillage nécessaire sur mon poste de développement : que dois-je installer ? Amazon fournit-il des outils ou préconises-tu d’autres outils tierces ?
Fabien: Il faut tout d’abord s’inscrire à AWS et rentrer sa carte bancaire ! Une fois fait, on a alors accès à une console Web. A partir de cette console, on va déjà accéder aux principales fonctionnalités. Si on veut interagir avec tous les services AWS et automatiser certains traitements, on va utiliser les outils ou SDK fournis par AWS. Par exemple, pour le produit EC2, on utilisera http://docs.amazonwebservices.com/AWSEC2/latest/CommandLineReference/.

Si on utilise Elastic Beanstalk (offre PaaS destinée au développeur), on pourra alors utiliser le plugin Eclipse dédié à ce service AWS. Ce plugin permet entre autres de déployer son application Java directement sur Elastic Beanstalk.

Agnès & Cyril: Quels sont les besoins et contraintes au niveau développement? Y’a-t-il des principes de design à respecter qui bouleversent les habitudes? Par exemple, on nous explique qu’un système distribué doit être tolérant aux pannes d’un composant : comment le tester en local?
Fabien: C’est un des avantages de AWS, il ne chamboule pas les habitudes de développement. On peut très bien reprendre son application existante : c’est ce que l’on a fait chez Kalistick. On a historiquement une offre hébergée privée que l’on a directement déployée sur AWS. Comme on était en mode SaaS, on avait déjà inclus la vision “extensibilité” dans notre infrastructure, ce qui a facilité la migration. En gros, on a des serveurs virtuels sur AWS avec les mêmes configurations que notre hébergement existant. Ainsi, pas de mauvaise surprise.

Après tout dépend des services AWS que l’on va utiliser. Chez Kalistick, on a fait le choix d’utiliser une couche plutôt basse d’AWS pour garder la main, ne pas devenir “AWS dépendant”, et avoir deux hebergements identiques entre AWS et notre offre privée. Mais par exemple, si on utilise l’offre PaaS d’AWS (Amazon Elastic Beanstalk), alors on va devoir développer une application Web Java au format WAR pour tomcat 6 ou 7 et se limiter à cela.

Agnès & Cyril: La grille tarifaire AWS semble très complexe. Comment estimez-vous et maîtrisez-vous cet aspect ?
Fabien: Oui, je confirme ce n’est pas évident d’estimer en amont le coût d’AWS.
On peut tout d’abord utiliser la calculette AWS. En gros, il va falloir estimer la durée d’utilisation de la (des) machine(s) virtuelle(s) (EC2) et la quantité de données à stocker. Mais il y a aussi d’autres coûts plus difficiles à estimer comme la quantité de données qui va transiter entre internet et nos machines virtuelles ou comme le nombre d’entrée/sortie sur nos disques virtuels.

Le paiement se fait au mois. Il n’y a aucun coût de mise en place ou d’installation. La règle, c’est qu’on ne paye que ce qu’on utilise. A noter que les tarifs varient en fonction de la région géographique où l’on va utiliser les services AWS (US, Europe, Asie).

Dans notre cas, après l’utilisation de la calculette AWS, pour être plus précis dans cette estimation, nous avons monté un environnement sur AWS pendant un mois en condition de production. Le résultat est que finalement, on n’était pas très loin de l’estimation de départ.
Le point à noter est que le coût des machines (CPU/Mémoire, partie EC2 de l’offre) est de loin l’élément le plus important mais aussi le plus simple à estimer. Les autres sont presque négligeables.
A noter qu’il est possible d’utiliser AWS gratuitement pendant un an avec pas mal de limites (attention on doit quand même rentrer sa carte bancaire….). Voir http://aws.amazon.com/fr/free/.

Agnès & Cyril: Une fois l’application développée et déployée, peux-tu nous expliquer comment il est possible de la monitorer et de l’exploiter ?
Fabien: Vu qu’on a accès au serveur virtuel (et donc à l’OS) sur lequel on a déployé son application, on peut alors monitorer son application comme on a l’habitude via une sonde SNMP et des outils de vérification comme IPCheck Server Monitor. A noter que AWS fournit aussi un service de monitoring pour les serveurs virtuels : Amazon CloudWatch.

Merci Fabien!

Les inscriptions sont ouvertes! Rendez-vous sur le site du Lyon JUG

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