Which freaking PaaS should I use?
The ups, downs, ins, and outs of deploying a legacy Java application to 7 leading platform-as-a-service cloudsFollow @infoworld
Most of the buzz around the cloud has centered on infrastructure as a service (IaaS). However, IaaS is no longer good enough. Sure, you can forgo buying servers and run everything virtually on Amazon's EC2 server farm. So what? You still have to manage it, and to do that you'll have a growing IT bureaucracy. Companies that want to focus on writing their code and not have to think about application servers at all are now looking to platform as a service (PaaS).
A PaaS is a virtual instance running an application server with some management and deployment tools in front of it. Management of the infrastructure and the higher-level runtime (application server, LAMP stack, and so on) are taken care of for you, and there's generally a marketplace of other services like databases and logging for you to tap. You just deploy your application and provision instances.
[ Stay on top of the current state of the cloud with InfoWorld's special report, "Cloud computing in 2012." Download it today! | Also check out our "Private Cloud Deep Dive," our "Cloud Security Deep Dive," our "Cloud Storage Deep Dive," and our "Cloud Services Deep Dive." ]
Amazon, Google, Microsoft, Red Hat, Salesforce.com, and VMware all have PaaS offerings. There are also smaller vendors such as CloudBees that are compelling. (We also wanted to try out Oracle Cloud, but when we attempted to create an account, the site reported that the preview was full. We look forward to trying it at a later date.) Each vendor has a set of differentiating characteristics beyond the many technical and cosmetic differences. They might even be targeting different sorts of customers. Which one should you choose?
To find out, we examined seven PaaS solutions based on the top concerns we hear from customers:
- Key differentiators. What's the special sauce? What can you get from vendor X that you can't get from the others?
- Lock-in. Once you get on, how easy is it to get off?
- Security. Are important security standards (PCI, SAE, etc.) supported?
- Reference customers. Who are they marketing to and who is not a good fit? Are there any "keynote" deployments?
In addition to posing these questions to each vendor, we subjected each PaaS offering to a simple test.
The trouble is that all of the tutorials and getting-started documentation seems to be aimed at people working on green field applications. Most of us spend the majority of our time working on existing applications. The big money is getting the legacy to run in our new cloudy world. We wanted to see how easy or difficult it would be to port a legacy application to the cloud.
Our legacy app, called Granny's Addressbook (aka Granny), is a training exercise we use at my company to teach the Java-based Spring framework. The rationale: Chances are if you're comparing PaaS, you aren't a Microsoft shop. If you're not a Microsoft shop, then statistically speaking you're a John Doe with 2.3 kids and your application is in Java. If your application is in Java, then it is probably written in the Spring framework. This is basic market math, so we compared the process of deploying Granny on each of the PaaS clouds.
If you'd like to try this yourself or examine our code, you can download the Granny's Addressbook WAR file, find the Granny source code on GitHub, and follow our steps to deploying Granny to each PaaS (with screen images).
Before diving into the details, we'll give you an executive summary of our results. CloudBees and VMware's Cloud Foundry proved the easiest for deploying our legacy app. CloudBees shined with a built-in CI (continuous integration) tool, while Cloud Foundry's IDE integration was seamless and wonderful. Heroku was a distant third, but probably would have fared better if Granny had been written in Ruby.