Devoxx on CloudBees

Devoxx conference is much more than an annual event for the Java Community. With DevoxxFrance, DevoxxUK and Devoxx4kids it’s now a growing ecosystem of great community events.

The Devoxx team used to host its registration and call-for-paper applications on its own hardware. I proposed to host it on CloudBees Platform as a Service; they were so enthusiastic about it, I quickly understood being sysadmins on this infra to keep the apps up and running 24x7 isn’t a fun job. They prefer to focus on making the conferences happen and be even better every year.

The interesting challenge is that the Devoxx applications haven’t been designed to be hosted in the cloud. They don’t use a fully-stateless web framework à la Play. They aren’t split into small REST services invoked from a pure Angular javascript frontend, they are … like 99.9% existing applications, using common Java Frameworks.

Registration application was the simpler one to migrate. It’s a very classic servlet-based application, designed using Vaadin for web UI, and a Spring and MySQL backend. We just had to make some minor configuration changes so that the app can get a datasource injected by the platform, as well as SendGrid JavaMail session.

Devoxx applications
Most containers require you to add a dedicated deployment descriptor to declare container resources (jboss-web.xml, weblogic-web.xml, etc). If you don’t want production information to be stored in SCM neither hard-wired within the artifact, you probably rely on an external properties file to be loaded by spring on startup or comparable workaround.

The CloudBees Platform lets you inject parameters and resources to an application, so that you can have the exact same binary WAR deployed on both the staging environment and then on production, with just the adequate Mysql DataSource bound and configuration parameters(secret credentials…) injected.

Thanks to this feature, the Devoxx team is able to have a staging environment that is an exact replica of the production environment, just with less connected users. :) The deployment process is also the exact same one and is run on every commit that successfully builds the WAR. With such a homogeneous infrastructure, they can be very confident when deploying to production.


The Devoxx team quickly setup a continuous delivery pipeline. As they push code to Bitbucket - they use Mercurial, sorry for that, read my previous post - the CloudBees DEV@cloud Jenkins service is building the app and automatically deploying to the staging environment.
 

CloudBees DEV@cloud Jenkins service

They also enabled the Sonar add-on service, because continuous delivery doesn’t prevent you from writing ugly code! :)

As the CloudBees Platform handles concurrent deployment versions, the service isn’t interrupted as you deploy a new app, the “old” application remains active until the “new” one is ready to handle requests, and then http traffic routing is switched. So, deployment to production isn’t a stressful process anymore, with Twitter announcements about temporary service black-outs.

After some more testing, they can promote the build to production. A single click to deploy app in production is all it takes. Cool, isn’t it?

 

 

Jenkins deploy app

This encourages rapid feedback, small change-sets between “releases,” so small risks… I won’t explain to you here what agile software development is!

The Devoxx team also wanted to test the scalability of the platform, but then hit an issue as Vaadin is using an HTTP session to store the UI state, so you can’t use a round-robin load balancer. Fortunately, the CloudBees Platform can be configured to enable sticky sessions. This is something you have to consider to host your application on a cloud platform, as most frameworks rely on this feature, and sometimes you don’t even know (I think about spring-security!). The other option is to enable session clustering around the nodes your application is running on.

The Call For Papers application required more changes to be “cloud-compliant.” This application lets speakers upload existing slide decks so the CFP team can review a proposal from existing content. The application is used to store those files on file system, using a parameter to configure the local directory. How does this translate when running in the cloud? The app is running on multiple clustered nodes. It starts on fresh new nodes every time a new version is deployed. So, even a local file-system can be used for temporary files during request processing, it is not persistent, neither replicated.

This is something CloudBees plans to address in 2013, but at this time there was no other option than changing the application code to use Amazon S3 to store files. jclouds API and S3 provider helped a lot to reduce the amount of time spent to fix this design issue, and the application was running on the staging environment after a few hours of coding.

The RUN@cloud console gives general health and performance information about the applications, so the team can monitor the application and - if necessary - change the platform configuration to use larger nodes, more nodes or both. They also enabled the NewRelic add-on for performance monitoring to get fine grained analysis, that could help in case something wrong happes.

 

 

 

 

NewRelic add-on for performance monitoring

 

 

 

The Devoxx team officially announced registration for DevoxxFrance to be open, running on the new CloudBees infrastructure. The CFP application has been migrated earlier today. So feel free to register for Devoxx and propose your talk! The app is now running on a Platform as a Service, with the CloudBees team ready to help in case anything goes wrong. And the Devoxx team can work on the real added-value: continue to make Devoxx the best conference ever.

—-

 

Nicolas De Loof
Senior Engineer
CloudBees, Inc.
JUG-Leader
 

Nicolas De Loof Senior Engineer CloudBees

 CloudBees Twitter