Notes on IT Migrating From AWS Beanstalk to Cloud Foundry in (almost) zero steps :-)

I am developping a small web app for a few months during my free time. I used to deploy it to the AWS Beanstalk platform, today I’ve been amazed how easy it has been to migrate it to Cloud Foundry .

My app is mostly based on JSF2/jquery/Spring/Jackson + the AWS-specific APIs for storing data into AWS SDB and S3.

The migration to Cloudfoundry is the most straightforward migration experience I’ve seen up to now, it boiled down to:

• Downloading the Spring Micro Cloud + VMWare player and install them on my Ubuntu station, as instructed here and here.
• Creating a Cloud Foundry account, here
  
• Downloading Spring STS editor (I used to use the plain Eclise WDP in my previous version), installing it and following those instructions to install the pluging for Cloud Foundry support
• Fire up STS, import my existing Web project, let Maven do the plumbing, open the STS Server view, create a new Server of type “Cloud Foundry” running on my local environment, providing the credentials of my account

If everything goes well that’s all what it takes! Just right click on the newly created server and deploy the Web app and there we go .

Both platform are based on derivatives of Tomcat, so actually it’s not so surprising the migration is so easy, still it’s the first time I see a migration going so smoothly.

Actually I’m lying a bit…

Alright, the very first deployment I tried to do failed due to the following error:

OK, so Cloud Foundry does not support yet servlet 3.0… There’s actually very little documentation on Cloud Foundry at the moment, it’s a bit frustrating that we have to actually try a deployment to discover the supported stack of the platform, but as it is still branded as beta, I guess we just jave to live with this.

Beanstalk on the other hand is very well documented. For a few months it is based on Tomcat 7, which supports servlet 3. My app includes an upload servlet using the @MultipartConfig annotation to receive uploaded pictures from the end user. In order to adapt the application for Cloud Foundry, I had to rewrite this servlet using File upload lib from Apache, edit my web.xml and my pom.xml to rely on servlet 2.5.

Now what?

You certainly noticed that I mentioned AWS-specific APIs in the beginning of this post, those API are still there! It means I have only made the first step of the migration: the java code now runs on Cloud Foundry, but the data is still hosted by the Amazon systems.

I am very satisfied by the S3 solution of Amazon, especially the pre-signed URL feature (with expiration period) is pretty handy to let the browser access directly binaries (like images) protected by ACLs from the S3 cloud, so I am probably going to leave that there. I am very happy to see that the AWS stack run flawlessly on the Cloud Foundry platform (this was expected, but, well, there’s no bad surprises).

I am probably going to get rid of AWS SDB though, among other things because I find that the lack of nested structure is limitating. I tried to store whole JSON structures inside single field values to work around that, but because we are limited to 1Kb per value, this approach does not lead very far. I expect MongoDB to naturally solve this as their storage is based on JSON so nested storage is present by design.

Source: http://svendvanderveken.wordpress.com/2011/09/08/migrating-from-aws-beanstalk-to-cloud-foundry-in-almost-zero-steps/