Déployer son application sur le Cloud

Quelle application voulons nous déployer et pourquoi ?

Lors de Devoxx nous avions un jeu concours sous forme de quiz en ligne, en plus d’animer le stand le but était de faire une démonstration de nos compétences dans le développement distribué et tout particulièrement dans le domaine du cloud computing.

Le temps où l’on regardait le cloud avec des yeux curieux mais distants, mêlés d’une pointe d’appréhension vers cette « technologie de demain » arrive à sa fin. En effet le cloud computing arrive à maturité, ses contours sont mieux définis et de nombreux outils ont été développés afin de simplifier son utilisation et son apprentissage.

C’est dans cette optique que nous avons conçu notre application de quiz en ligne, afin d’en faire une petite vitrine faisant la promotion de l’utilisation et des possibilités du cloud et plus particulièrement des offres PaaS qui nous semble avoir le plus de valeur pour le SI. Nous avons voulu montrer aussi quelques pratiques faciles à mettre en place pour que l’application soit portable et ne soit liée ni à un cloud ni à un paas-fabric spécifique et garde toute son indépendance. Nous voulons en quelque sorte démystifier le cloud et montrer que son utilisation n’est finalement pas si complexe et que le moment opportun est peut-être arrivé pour prendre le cloud en vol !

Revenons en à notre application, c’est donc un quiz en ligne, elle est écrite en Java et utilise Spring MVC ainsi que la bibliothèque Jquery qui permet d’avoir un rendu optimal pour téléphone portable. Tomcat a été choisi pour le conteneur web et MongoDB comme base de données. Lors de Devoxx l’application tournait sur le cloud Amazon EC2 et plus précisément sur le data center « eu-west-1″ situé en Irlande, le déploiement étant automatisé via le paas-fabric Cloudify.
Durant le développement et les tests nous déployons en local ou sur CloudFoundry. Déploiements rapides en local pour les premiers tests, puis déploiement sur Cloudfoundry pour les tests plus poussés, et enfin déploiement de production sur EC2 via Cloudify.

C’est ce cheminement que avons retenu lors du développement de notre application et c’est celui que nous allons présenter ici.

En développement …

En phase de développement nous voulons voir si telle fonctionnalité marche comme attendue, où si telle page s’affiche comme l’on voudrait. Un simple déploiement local fait l’affaire : il suffit donc de lancer MongoDB et Tomcat et d’y déployer le WAR de l’application. Simple et rapide cette méthode a aussi l’avantage d’être réactive ; sous Eclipse on peut ainsi corriger une classe et le nouveau WAR est redéployé à chaud, permettant de voir tout de suite les conséquences de la correction.

Déploiement sur CloudFoundry

Mais notre ordinateur de développeur ne permet sûrement pas de faire tous les tests que nous souhaitons mener : tests de charge, de résilience, etc. Ou alors nous voulons faire des tests distants tout en gardant une certaine rapidité et simplicité de déploiement. CloudFoundry peut alors être la solution idéale, ce PaaS Open Source initié par vmware permet en effet avec peu de changement de code et très peu de configuration de déployer son application sur un ensemble de PaaS dont cloudfoundry.com (opéré par vmware) qui offre les avantages de simplicité et d’une vitesse de déploiement relativement rapide.

Pour cela il suffit d’installer le plugin d’intégration de CloudFoundry dans Eclipse, de créer un compte (on peut créer un compte de test gratuitement), puis l’on est prêt à démarrer l’utilisation. On sélectionne alors les applications que l’on veux déployer, dans notre cas le quiz, puis l’on choisit l’url du site web et les services dont l’on dépend, ici MongoDB. Ensuite le déploiement sur cloudfoundry.com commence : le type de l’application est détecté automatiquement, dans notre cas un conteneur web est utilisé. Les services comme le conteneur web et MongoDB sont déjà pré-déployés sur le cloud, ce qui permet d’avoir un déploiement relativement rapide, dans notre cas une minute suffit.

L’effort de configuration est très réduit, une grand partie est automatiquement prise en charge et cachée à l’utilisateur. Pour le quiz il a juste fallu remplacer le bean qui crée la connexion vers Mongo, au lieu de donner une IP on donne le nom du service Mongo précédemment déployé dans Cloudfoundry. Afin de gérer les différentes configurations nous avons utilisé les profiles Spring apparus avec Spring 3.1. Ainsi un profile « défaut » est utilisé pour le déploiement local dans Tomcat tandis qu’un profil « cloud » est automatiquement activé lors du déploiement sur CloudFoundry et nous avons créé un profil Cloudify pour les déploiements opérés par Cloudify. La contre-partie à la facilité d’utilisation de Cloudfoundry est qu’on a que peu de maîtrise sur les détails de configuration des services comme la version de Mongo où son tunning, de même pour le conteneur web.

Déploiement en production sur Amazon EC2 à l’aide de Cloudify

Notre application est maintenant prête à passer en production. Nous voulons pouvoir automatiser le déploiement sur le cloud sans pour autant être dépendant d’une solution donnée et en gardant une grande liberté de configuration, Cloudify devient alors un outil attractif. C’est un paas-fabric Open Source initié par GigaSpaces tout comme CloudFoundry mais leur philosophie est très différente, Cloudify tente de concilier le paas-fabric et les principes du dev-ops.

L’idée est d’avoir une solution non intrusive qui gère tout le cycle de vie des applications et non pas seulement le déploiement, et ceci par exécution de recettes/scripts « à la chef (ou puppet) », pouvant être écrits en groovy, bash ou bat. Cette utilisation des scripts rend l’utilisation de Cloudify plus complexe que CloudFoundry mais offre un niveau de contrôle et de configuration bien plus poussé. Des fonctionnalités supplémentaires sont en plus disponibles, un monitoring customisable des applications, le self-healing qui redémarre automatiquement les services en erreur ou encore l’auto-scaling en fonction de critères monitorés.

L’intégration de Cloudify avec les différents clouds se fait via des drivers d’infrastructure, grâce à cela on est capable de déployer la même application avec la même configuration sur différents clouds public dont Amazon Ec2, Rackspace et Windows Azure ou privés comme OpenStack.
C’est par ce biais que nous avons pu déployer notre quiz sur Amazon Ec2 en Irlande. Cloudify n’est pas intrusif, mais il faut tout de même s’adapter à la dynamicité de l’environnement. Dans notre cas on récupère les IPs des bases Mongo via une variable d’environnement qui est settée par Cloudify et qui est ensuite utilisée dans la config spring pour créer le proxy Mongo.

Conclusion

Au travers de cet exemple de développement et de déploiement d’une application de quiz en ligne nous avons voulu montrer un premier aperçu des possibilités et outils du Cloud et que ces différent(e)s méthodes et outils ne sont pas forcément concurrent(e)s
mais peuvent être complémentaires. De même avec quelques bonnes pratiques il est facile d’avoir une application portable pouvant prendre en charge différentes configurations.

Nous pensons qu’il est temps de lever les yeux vers le cloud car celui-ci est maintenant suffisamment accessible et mature pour devenir la solution idéale à un certain nombre des besoins et défis de l’informatique d’aujourd’hui et de demain.

Le déploiement de notre quiz via CloudFoundry et Cloudify est illustré dans cette vidéo qui inaugure l’arrivée de la chaîne youtube FastConnectTV.

De nouvelles vidéos sur le cloud vont y être ajoutées très prochainement !

Les Rencontres Spring 2008

Le 13 novembre à La Défense ont eu lieu « les rencontres Spring ». La conférence était animée par Didier Girard (directeur de l’innovation de SFEIR) ainsi que Julien Dubois (Directeur régional France de SpringSource). La salle était pleine, environ 200 personnes étaient présentes ; FastConnect y était représenté en les personnes de Gauvain Girault et Cyril Martin (moi).

Voici le programme de notre journée :

  • 08:30 – Accueil
  • 09:00 – Keynote par Didier Girard, Julien Dubois et Guillaume Laforge (l’ancien CTO de G2One)
  • 09:45 – Roadmap des projets Spring par Peter Cooper-Ellis (senior vice-president of engineering de SpringSource)
  • 10:30 – Pause
  • 11:00 – Tomcat en production, avec Mark Thomas (principal contributeur au projet Apache Tomcat)
  • 12:10 – Spring 3.0, par Juergen Hoeller (co-fondateur et principal développeur du framework Spring)
  • 12:30 – Table ronde avec de grands utilisateurs de Spring (banques, sites de e-commerces…)

Ci après le détail des différentes interventions. Toute la journée a été filmé par TV4IT, voici le programme présenté par Julien Dubois :

  • http://www.tv4it.net/permalink/6932/rencontres-spring-rendezvous-le-13-novembre.aspx

Les slides et les vidéos des présentations sont disponibles:

  • Keynote de Didier Girard (pdf, vidéo)
  • Keynote de Julien Dubois (pdf)
  • Keynote de Guillaume Laforge (pdf)
  • Roadmap SpringSource de Peter Cooper Ellis (pdf, vidéo)
  • Tomcat en production de Mark Thomas (pdf, vidéo)
  • Spring 3.0 de Juergen Hoeller (pdf, vidéo)

Accueil

La vidéo.

9:00 (pdf), Didier Girard nous accueille : il fixe l’agenda de la journée, présente les principaux participants, touche deux mots de Spring et J2EE en introduction et, surtout, fait la pub de sa société avant de prendre le rôle d’animateur pour le reste de la journée.

9:25 (pdf), Julien Dubois, directeur régional France de SpringSource, prend la parole. Il commence par faire la publicité de la nouvelle édition de son livre : Spring par la pratique. J’espère qu’un patron charitable va nous le commander :-) Puis il nous parle de Spring Source SARL.

Julien Dubois est revenu sur la nouvelle politique de support de Spring qui a tant fait couler d’encre ces derniers jours : à partir de maintenant les corrections ne sont plus « backportées » pour les « anciennes » versions publiques de Spring.
Seuls les clients (ceux qui souscrivent) bénéficient des corrections sur les anciennes versions. Il semblerait que la mauvaise communication autour de ce changement de politique ait été finalement profitable à Julien Dubois car elle a été l’occasion d’être contacté par beaucoup d’utilisateurs français de Spring.

9:35 (pdf), Guillaume Laforge, l’ancien CTO de G2One, chef du projet Groovy et nouvel employé de Spring Source France suite au rachat de G2One par Spring Source, nous a parlé de Groovy et Grails bien sûr.

Le langage Groovy ouvre aux développeurs Java de nouvelles perspectives en permettant d’élaborer des constructions syntaxiques complémentaires. Plus qu’un langage de script, il est qualifié de langage dynamique par le leader du projet Open Source. Le framework Grails est certainement la killer application de Groovy. C’est un framework de développement web fondé sur le concept « Convention over Configuration ». Grails offre un dialecte Java dédié au développement web, une sorte de DSL donc.

La société G2One, fondée il y a un an à peine, proposait des formations et du support pour groovy et grails. Guillaume Laforge devrait continuer les mêmes activités au sein de Spring Source. Il a annoncé aussi qu’il allait travailler sur le support de groovy et grails pour Eclipse.

The SpringSource Product Roadmap

Les slides, la vidéo.

Peter Cooper-Ellis, en tant que VP « Engineering and Product Management » chez SpringSource, est le responsable de la roadmap des produits SpringSource.

Cette présentation nous a donné la roadmap jusqu’à fin 2009 pour l’ensemble des produits maintenus par Spring Source. Peter nous a montré la cohérence de l’ensemble avec le refrain : « Provide weapons for the war on complexity ».

  • SpringSource Application Platform
  • Spring Enterprise
  • SpringSource dm Server
  • Tomcat
  • SpringSource Tool Suite
  • SpringSource Application Management
  • Spring Web
  • Spring Security
  • and more…

Tomcat Optimization & performance Tuning

Les slides, la vidéo.

Mark Thomas est le plus gros contributeur au code source de Tomcat. Son intervention portait sur l’utilisation de Tomcat en production, et en particulier sur l’optimisation des performances de votre serveur.
Tomcat est livré avec une configuration qui sied aux développeurs et non à la production. Parmi les points abordés, j’ai noté en particulier :

  • certains logger écrivent dans deux fichiers,
  • l’écriture des logs est synchrone
  • on utilise les connecteurs a priori les plus stables, mais ce sont assurément les moins performants,
  • il faut tuner la taille du pool de threads répondant aux requêtes,
  • configurer le cache (indiquer précisement le contenu statique et le contenu dynamique)
  • tuner la JVM (le GC en particulier)

Spring Framework 3.0: the next generation

Les slides, la vidéo.

Juergen Hoeller est le co-fondateur du framework Spring (avec Rod Johnson). Il est aujourd’hui le principal développeur du framework.

The upcoming Spring Framework 3.0 release introduces further annotation-based configuration options, unified expression language support and comprehensive REST support. This talk discusses Spring as a modern Java 5 oriented application framework, covering:

  • Spring’s comprehensive annotation-based component model
  • The use of expression language in Spring bean configuration
  • REST support in Spring MVC
  • Annotation-based model validation
  • The upgrade path from 2.5 to 3.0

Table Ronde

La table ronde réunissait :

  • François Cherpion (HSBC),
  • Alexandre Navarro (Société Générale Banque d’Investissement),
  • Ben-Amar Kacimi (Voyages SNCF Technologies),
  • David Duquenne (Improve)
  • Guillaume Laforge (G2One / SpringSource)

Voyages SNCF Technologies s’occupe notamment (mais pas seulement) du site www.voyages-sncf.com. Ce site reçoit 5 à 7 millions de visiteurs tous les mois. Aussi la principale préoccupation est la tenue face à la charge, hotspot, et la tolérance aux fautes.

HSBC utilise massivement Spring dans ses développements. Les buts sont la réduction des coûts et une meilleure qualité de code. L’expérience semble très concluante.

Spring Hibernate and GWT Integration built with Maven

I worked with a colleague, Xavier, to build a kind of « best of breed » Web 2.0 technologies project template that we could reuse from project to project.

Our aim for this project was to :

  • build a simple Web 2.0 project based on the technologies or libraries we like to use in Java EE today’s world (GWT, Spring, JPA/Hibernate, Acegi, Maven)
  • and to create a Maven archetype (as we didn’t found anyone which already provides integration of  these technologies together).

Let’s consider the following architecture : we have an existing domain model and a traditionnal multilayered application (business layer, data access layer, database), and we want to be able to use GWT as the presentation layer.

Basically, points we wanted to take into consideration were :

  • how can GWT interact with Spring ?
  • managing Hibernate lazy collections.
  • how can Acegi be used to improve security of such a GWT based application ?

A Maven based project

We’ve started using the archetype gwt-archetype.

This archetype provides a Maven based project with a simple GWT client.

With the gwt plugin maven-googlewebtoolkit2-plugin, we are able to launch the GWT Debug Console and also the embedded Jetty container with the Jetty plugin for Maven.

GWT / Spring communication

Several scenarii are available to integrate GWT and Spring.

We have tested 2 of them :

Strong integration , following Chris Lee’s post GWT-RPC with Spring 2.x.

GWT services are beans, configured in the Spring context. You annotate them with a custom annotation @GwtRpcEndPoint.

Then you write your own class extending Spring’s AbstractDetectingUrlHandlerMapping class. Its role is to detect the annotation and to generate urls that will be handled by Spring and mapped to corresponding ‘controller’.

Finally, you write an another class that extends RemoteServiceServlet (provided by GWT) which is responsible to handle RPC calls.

This first approach looks good for IoC purists : GWT services are not servlets, and you can even think about using your business layer as GWT endpoints.

But is this really a good idea ? It seems like a violation of SoC paradigm, isn’t it … ?

Whatever, when considering the use of Hibernate, that also needs to rewrite parts of RemoteServiceServlet, you come into troubles …

So we have finally choosen a kind of light integration : GWT services simply get business service implementations from context.

In their init() method, GWT endpoints – that extend RemoteService, so Servlet by inheritance – get their dependencies from the context.

BeanFactory factory = WebApplicationContextUtils.getWebApplicationContext(config.getServletContext());
taskManager = (TaskManager) factory.getBean("taskManager");

Don’t be offended (as we initially were !) by this approach : just consider GWT layer as a presentation layer which comes on top of an existing Spring multilayered architecture, as we mentioned in the intro.

GWT / Hibernate communication

We wanted to use Hibernate as an implementation of JPA specification for differents reasons : convention over configuration, choice for implementation, standard use.

At the time we had chosen to use the freshest GWT build which was a pre-release of version 1.5 since it supports Java 1.5 features : annotations, generics.

However, we can’t use our Hibernate objects directly.
As we can read in the post Why GWT 1.5 won’t solve your Hibernate issues : « Hibernate POJO are not real POJO. The persistence library adds a lot of needed information, such as session factory, by creating a dynamic proxy (with CGLIB or Javassist) around your instance. When you manipulate an Hibernate POJO, you do not do it with an instance of your class, but with a instrumented, derived one! »

As a consequence, we have to duplicate our domain model. One domain for backend processes (typically POJOs with JPA annotations), and one other domain for GWT serialization processes (DTOs).

As managing this duplication can sound bad, we have chosen hibernate4gwt, a library that can help us managing this.

As you can read in its documentation, hibernate4gwt offers different ways to manage domain model duplication : stateless, dynamic proxy, Java5 support and stateful.

Since dynamic proxy seems to be the less intrusive for our POJOs, it gained our preference.

(Moreover, with 1.5 GWT pre-release, we can use our 1.5 annotated POJOs.)

Initially we wanted to use stateless mode, but having unresolved issues with StatelessPojoStore down the road we decided to use HttpSessionPojoStore.
May look like a hack but it worked and allowed to avoid building in-house code.
More importantly we thought duplicating the domain objects could be an error prone task.

Acegi

Then we started to focus on security.

Considering using Acegi in a GWT project gives us 2 solutions.
We have tried to use a HTML form to authenticate. This is simple but is incompatible with the use of GWT console to debug the application. Effectively, GWT Console needs a GWT module to run, it doesn’t want to know anything about html pages.

So to be able to debug our application in the GWT console, we have preferred the second approach which in fact is to use a second GWT Login component : a single EntryPoint which declares a FormPanel, which posts to j_acegi_security_check.

We have included a simple Acegi configuration file : if you are not authenticated, it enforces you to login by redirecting you to the login module.
Authentication is made upon the database with a DaoAuthenticationProvider, which takes as a parameter a custom implementation of UserDetailsService. This one uses the service layer to look for the users in the database.

More informations :

How to build the project : https://opensource.fastconnect.org/redmine/wiki/spring-gwt-archetype

Sources : http://opensource.fastconnect.org/svn/toolbox/maven2/archetypes/hibernate-spring-gwt-archetype/trunk/