Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Which freaking PaaS should I use?

Andrew C. Oliver and Lifford Pinto | Oct. 10, 2012
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).

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.

Google App Engine has the best SLA but also a high risk of lock-in. Red Hat's OpenShift was a bit disappointing, but we expect the kinks will get worked out as it exits preview status. It likely would've been more impressive if Granny were a Java EE application instead of a Spring app. Red Hat and VMware had the best answers with regards to lock-in.

Amazon Elastic Beanstalk isn't really a PaaS, but it might be a good compromise if you need IaaS customizability with PaaS-like capabilities. Microsoft's Windows Azure supports the most languages, but it didn't function as a "true" PaaS for our application. Microsoft's tooling for Linux didn't work, and its tooling for Eclipse was underwhelming.

It's still a bit early in the PaaS space, but you can already begin porting legacy apps to some cloud platforms with only minor changes or possibly none at all. Big companies and small companies alike may find a PaaS to be a compelling way to deploy applications and cut capital expenditures. This market isn't as crowded as it might seem, as many of the big players aren't yet out of beta. But in the coming months we can expect that to change.

Amazon Elastic Beanstalk

Amazon's AWS Elastic Beanstalk kind of sticks out in this list. It isn't a PaaS so much as a deployment tool for Amazon Web Service's EC2. Think of Elastic Beanstock as a wizard for deploying applications to EC2 VMs. We've included it because you'd ask about it if we didn't!

Differentiators. The biggest differentiator in this is the mothership. Most of the other PaaS vendors (including CloudBees, Heroku, and Red Hat's OpenShift) are piggybacking on Amazon's infrastructure. That means if something goes wrong at the infrastructure level, despite their SLAs, they're talking to Amazon while you talk to them because this is really an IaaS you have ultimate control down to the OS level. On the other hand, where a true PaaS would give you "freedom from the obligation of control," Amazon Elastic Beanstalk still requires you to manage infrastructure-level resources.

 

Previous Page  1  2  3  4  5  6  7  8  9  10  Next Page 

Sign up for Computerworld eNewsletters.