Devoxx team used to host it's registration and call-for-paper applications on it's own hardware, and as I proposed to host it on CloudBees Platform as a Service, they were so enthusiastic 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 those application 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 application, 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.
Most container 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.
CloudBees platform let you inject parameters and resources to an application, so that you can have the exact same binary WAR deployed on 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 staging environment be an exact replica of production environment, just with less connected users :) Deployment process is also the exact same one, and is ran on every commit that successfully builds the WAR. With such an homogeneous infrastructure, they can be very confident when deploying to production.
Devoxx team quickly setup a continuous delivery pipeline. As they push code to bitbucket - they use Mercurial, sorry for that, read my previous post - Cloudbees DEV@Cloud Jenkins is building the app and automatically deploying to the staging environment.
As the Platform handles concurrent versions deployment, 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 stress anymore, with twitter announcement about temporary service black-out.
After some more testing, they can promote the build to production. A single click to deploy app in production, cool isn't it ?
This encourages rapid feedback, small change-sets between "releases", so small risks ... I won't explain you here what agile software development is !
Devoxx team also wanted to test the scalability of the platform, and then hit an issue as vaadin is using HTTP session to store UI state, so you can't use round-robin load balancer. Hopefully, cloudbees platform can be configured to enable sticky session. 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 even don't know (I think about you spring-security!). The other option is to enable session clustering around the nodes your application is running on.
The Call For Paper application required more changes to be "cloud-compliant". This application let speakers upload existing slide decks so the CFP team can review a proposal from existing content. The application 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 local file-system can be used for temporary files during request processing, it is not persistent, neither replicated.
This is something CloudBees plan 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 his application and - if necessary - change the platform configuration to use larger nodes, more nodes, or both. They also enabled NewRelic add-on to get fine grained analysis, that could help in case something wrong happes.
