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.
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
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
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.
Conclusions. Due to its simple deployment process and reasonable pricing and service-level agreements, we think CloudBees is a good choice for deploying Java applications, legacy or not. It's at a disadvantage from a business standpoint in that it doesn't have the relationships with existing customers in the manner of VMware or Red Hat. On the other hand, CloudBees isn't stuck with these companies' management structures and compensation models, either. This should allow it to be more agile in attracting new customers to the cloudy world of PaaS.
Google App Engine
Differentiators. Hey, it's Google. GAE offers the same APIs that Google uses for deploying its own applications. The pricing model allows you to pay only for what you use, and the minimums appear to be cheaper than other vendors. Google's SLA also appears to beat the competition. Moreover, App Engine runs on Google's infrastructure. Most other PaaS offerings are front-ending Amazon.
Lock-in. Google's PaaS seems to be the most proprietary of all. We're talking serious lock-in, as in "download this to CSV and fix your code not to use Google's APIs." Ouch!
Security. Google App Engine is SAS70 (now SSAE16 and ISAE 3402) compliant.
Who's using it? Google sees mobile, Web, and gaming companies as being prime candidates. Google publishes an impressive list of customers that include companies like Pulse, Best Buy, Khan Academy, and Ubisoft.
How did they do? We couldn't get Granny to work on App Engine despite spending nearly five times as many minutes/hours we spent on the others. Google provides Spring examples, but the example apps are more simply structured than our application, which was originally based on the Spring Tool Suite IDE template.
Conclusions. Google's SLA is the best. This alone is why many companies we've worked with have chosen App Engine. Also, App Engine is mature. However, App Engine might not be our first choice for a legacy app, considering the amount of work we might have to do. We'd be even more concerned about lock-in for new apps. We'd want to do a lot more due diligence to prove we weren't stuck. When your stock price is $718 per share, investors are going to look to you to provide that value somewhere. Companies who base their entire infrastructure on you and can never leave would be one way you could do that in the long run.
Heroku