Which PaaS Should I Use?

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).

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).

Slideshow: 10 Most Powerful PaaS Companies

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?

Advertisement

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.

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.

Lock-in. Lock-in is up to you. Since this is an IaaS, you can ultimately deploy what you want to.

Security. Amazon publicly lists its security and compliance certifications. It's an extensive list that includes FIPS 140-2, ITAR, ISO 27001, PCI DSS Level 1, FISMA Moderate, and SOC 1/SSAE 16/ISAE 3402. Amazon also provides a good amount of documentation on its security processes.

Who's using it? Amazon also publishes its customer case studies. It's an impressive collection of customers ranging from Amazon (duh) to Netflix to Shazam. It's also very long.

How did it do? It was straightforward to deploy our Granny app. To get Granny working with Amazon RDS (MySQL) required provisioning the database via the Elastic Beanstalk wizard and changing the data source descriptors in our application to match. Unfortunately, our progress was blocked by a connection timeout that other people also seem to have encountered. Supposedly you can fix this by adding IP addresses to a security group. However, debugging this took longer than deploying on other PaaS offerings, so we gave up.

Conclusions. Amazon Elastic Beanstalk is a middle ground between an IaaS and a PaaS. It's one throat to choke, but it isn't the real thing. You're going to do all the things that a PaaS would do for you by yourself. If you're thinking of cloud but you haven't decided to "go all in" and make it to PaaS, this might be a good compromise while you get there technically or psychologically. But if you can, go all PaaS and pick something else.

CloudBees

CloudBees was one of the first PaaS offerings aimed mainly at the Java developer. Another successful startup by members of the so-called JBoss mafia, CloudBees is backed by Matrix Partners, Marc Fleury, and Bob Bickel, and led by former JBoss CTO Sacha Labourey. CloudBees supports any JVM-based language or framework.

Differentiators. According to CloudBees, a key differentiator is that this is a PaaS company from the ground up, whereas most of the competitors are software vendors with a cloud play. As a proof point, CloudBees notes that neither Red Hat, Oracle, VMware, nor Microsoft has a production-ready for-pay public PaaS offering despite all four having made such an announcement more than a year ago. The implication is that these competitors know how to build, QA, and monetize software, but not a service.

Against "pure" cloud plays such as Heroku and Google App Engine, CloudBees cites its depth in Java as a key attraction. Indeed, this showed when deploying our legacy application. CloudBees also noted its integration of the CI tool, Jenkins, which allows you to develop "full circle" in the cloud from GitHub to build and deploy.

Lock-in. CloudBees doesn't see lock-in as an inherent issue. The company pointed out that Java PaaS providers tend to be based on open source application servers like Tomcat running on open source JDKs. This means you could take an app running on a pure play PaaS vendor and move it back on-premise very easily.

Security. CloudBees noted that while its PaaS is PCI compliant, your application should also be reviewed. CloudBees provides documentation of its security process and constantly reviews those processes. CloudBees offers additional security information under NDA.

Who's using it? CloudBees notes that in addition to startups and small companies "with no access to sophisticated IT staff and capital expenditures," adoption is being driven within larger companies by specific business units. In many cases, central IT isn't responsive enough to their needs, so the business units start working directly with PaaS providers.

CloudBees lists its reference customers publicly. The company pointed to one in particular, Lose It, which generates up to 25,000 transactions per minute on the CloudBees platform. It seems this company only has four employees: two in software development and two in marketing, with zero in IT. CloudBees pointed out that this is the type of "extreme productivity" possible only in the cloud.

How did it do? To get our Granny application running, CloudBees required a simple deploy from a Web page using a "free" trial account. Getting the app to use a CloudBees-provided instance of MySQL required provisioning an instance and changing the data source descriptor to use CloudBees' JDBC driver and the appropriate JDBC URL. Although the Web GUI doesn't make it clear, CloudBees allows you to automatically override the data sources with its command-line interface in a manner similar to Cloud Foundry's IDE.

1 2 3 Page 1
Page 1 of 3
Survey says! Share your insights in our 19th annual State of the CIO study