Which freaking 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).
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
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.
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
Google App Engine (GAE) is Google's PaaS. Initially released all the way back in 2008, it's relatively mature compared to other PaaS offerings. App Engine supports Java, Python, and Google's Go language.
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
In development since 2007, Heroku is one of the original PaaS offerings. It was acquired by Salesforce.com in 2008. Heroku employs Yukihiro "Matz" Matsumoto, the creator of the Ruby programming language. In addition to Ruby, Heroku supports Java, Python, Node.js, Clojure, Grails, Gradle, Scala, and Play.
Differentiators. Heroku's key differentiator is its maturity. It has been publicly available for a number of years, and it enjoys a large marketplace of plug-ins. The company said more than 2.35 million apps are running live on the platform today. It noted that its official support for nine languages, and its many more community contributed languages and frameworks, differentiate Heroku from other PaaS offerings.
Lock-in. Heroku describes its PaaS as a 100% open platform that offers a native developer experience for both IDE-centric and command-line centric developers. In response to the lock-in question, the company said that code written to run on Heroku around modern best practices can easily run on any other standards-based platform, in-house or in the cloud.
Indeed the risks of lock-in do not seem more significant than with other PaaS offerings. We were able to deploy the Granny application without significant changes. However, it would be interesting to see how easy or difficult it is to dump data from a PostgreSQL or MySQL instance on Heroku.
Security. Heroku publicly lists its security compliance, noting mainly that it sits on Amazon Web Services infrastructure and Amazon is compliant with ISO 27001, SOC 1/SSAE 16/ISAE 3402, PCI Level 1, FISMA Moderate, and Sarbanes-Oxley (SOX). PCI compliance is provided by offloading credit card processing to a compliant third-party service.
Who's using it? Heroku said that it sees adoption from small startups through the largest enterprise customers in the world. It lists a good number of reference accounts, including social and Facebook apps, digital media sites, corporate marketing sites, city government sites, and more. In addition to those listed on the website, the company pointed to "exciting adoption" by Macy's, which is building Java apps on Heroku.
How did it do? Heroku was easier to work with than OpenShift but harder than CloudBees or Cloud Foundry. The documentation was fairly straightforward. In addition to uploading your WAR file, you have to log into your account and set up your database, then return to Eclipse to complete the process. This swapping between the Web GUI and Eclipse makes Heroku a less attractive option than Cloud Foundry. Heroku lacks the polish of some of the other offerings despite its maturity.
Conclusions. Heroku is a "safe" choice because it's well established, with a growing marketplace of add-on services. It isn't the easiest or hardest to work with. For a Ruby app, it might be our first choice. Our initial test was less positive, but after Heroku released improvements to the Java platform on Sept. 19, deploying Granny proved much more seamless. Heroku wouldn't be our first choice for a legacy application, but it's not bad at all.
Microsoft Windows Azure
Windows Azure is Microsoft's take on Amazon Web Services, encompassing both IaaS and PaaS offerings. In addition to .Net language support, there are SDKs for Java, Python, PHP, and Node.js.
Differentiators. First off, this is Microsoft -- your .Net apps can come here too. Further, Microsoft points out that Azure supports almost any developer language that's popular today, and more are being added. Unlike most competitors, which are AWS underneath, Azure runs on Microsoft's own cloud. Additionally, Azure is available for production today with publicly available pricing.
We don't consider Azure to be a true PaaS because the Azure tools actually deployed our entire Tomcat instance. On one hand, this is one way of answering the lock-in question. On the other hand, the whole idea behind choosing a PaaS is to be freed from having to manage your own application server.
Lock-in. According to Microsoft, making use of a PaaS solution means writing to a set of runtime libraries designed for that specific PaaS. This has excellent effects on scale, agility to write, and performance but requires custom work to move to another PaaS. The company notes that data migration is a simpler proposition because there are many ETL patterns supported by Windows Azure and other PaaS platforms.
In other words, we'd be careful to test elsewhere. Interoperability has never been a strong point for Microsoft, which focuses more on ease of entry. Then again, Microsoft does not have a history of price gouging its customers even when they're locked in. For software-freedom-loving open source guys like us, that's a hard admission, but for the most part we think that it is true.
Security. Microsoft has extensive documentation on Windows Azure's security certifications and procedures. These include ISO 2700, SSAE 16 ISAE 3402, EU Model Clauses, and HIPAA BAA. Frankly, this is how you get big government and corporate contracts, so we would expect no less. Microsoft goes above and beyond the certifications by not only penetration testing its product but offering penetration testing to its customers with seven days advanced notice.
Who's using it? Microsoft claims many thousands of Azure customers, from students to single-developer shops to Fortune 500 companies. It also notes that some legacy apps can pose a problem -- for example, an extremely stateful application with a frozen or nonmaintained code base that would preclude the architectural changes necessary to support the PaaS frameworks and its scalable tiers, availability sets, queuing across instances, and so on.
Microsoft sent us a number of published case studies. At the moment, these are mainly schools and municipalities. They don't appear to be specific to Azure either, let alone its PaaS offering. Additional case studies are available on the Azure site, but we're using Google Chrome on Ubuntu 12.04 and the site requires Silverlight.
How did it do? Microsoft called very shortly after we signed up and offered assistance. This is great customer service and honestly belongs among the differentiators. In this era of retail Internet service, "Can I help you?" can sway a decision.
Deploying Granny to Azure showed plenty of rough edges. Azure's Eclipse plug-in didn't work; in fact, it directed us to an EXE file, which obviously wasn't going to work on Linux. The Linux SDK also did not work. On Windows, deploying the application on Azure was only partially PaaS-like. Instructions for deploying the example "Hello, world" Web application include pointing the setup wizard to the local copy of your favorite application server and JDK. The app server is then merely copied to a Windows Server 2008 VM. After that, you can fairly easily have your application use Azure's SQL Server instance.
Conclusion. If you have legacy apps not based on .Net, then Azure probably won't be your first choice. However, with that hands-on approach to both customer service and security, Microsoft could go a long way.
We honestly expected a bit more from the Linux SDK and the Eclipse plug-in. Despite the talk of interoperability and all of the tweeting from OpenAtMicrosoft, Microsoft didn't shine here. Certainly, Microsoft has the wrong messaging on PaaS lock-in for our taste. That said, if you have a mixed infrastructure of .Net, Java, Ruby, Python, and PHP and can do some tweaking but prefer not to rewrite, Azure may be the best choice.
Red Hat OpenShift
Red Hat's PaaS offering, called OpenShift, is aimed at Node.js, Ruby, Python, PHP, Perl, and Java developers. OpenShift combines the full Java EE stack with newer technologies such as Node.js and MongoDB.
Differentiators. OpenShift runs Java applications on the JBoss Enterprise Application Platform (JBoss EAP), Red Hat's commercial distribution of JBoss. Red Hat considers Java Enterprise Edition 6 (Java EE 6) to be a compelling differentiator, along with allowing developers to choose the best tool for the job, whether it's Java EE 6, Ruby, Python, PHP, Node.js, Perl, or even a custom language runtime.
In the coming months, Red Hat will be launching the first commercial, paid, supported tier of the OpenShift service. Red Hat said it will also release an on-premises version for enterprises that can't run in the public cloud due to security, governance, and compliance restrictions.
Lock-in. "No lock-in" was one of the foundational principles used in the design and development of OpenShift, according to Red Hat. The company noted that OpenShift uses no proprietary APIs, languages, data stores, infrastructure, or databases, but is built with pure vanilla open source language runtimes and frameworks. This means, for example, that an application built with Python and MySQL on OpenShift will seamlessly port to Python and MySQL running on a stand-alone server or in another cloud (assuming the language versions are the same). Likewise, a JBoss Java EE 6 application running on OpenShift can be moved to any JBoss server.
Security. Red Hat publicly lists OpenShift's security compliance information. The company said that Red Hat's Security Response Team (the same team that continuously monitors Linux for vulnerabilities) is involved with the design and implementation of OpenShift and that the OpenShift OnLine PaaS service is continuously patched and updated by the OpenShift Operations team at the instruction of the Security team. Red Hat also noted that OpenShift runs SELinux, the security subsystem originally developed by the NSA.
Who's using it? Red Hat said a wide cross-section of companies are using OpenShift today, ranging from hobbyist developers to technology startups building their businesses in the cloud to systems integrators and service providers to Fortune 500 enterprises. The company noted that classic legacy applications that are running on mainframes or other legacy platforms are not great candidates for migration to a PaaS.
Because OpenShift is considered a "developer preview" -- Red Hat's term for beta or alpha -- the company didn't feel comfortable releasing any information about existing deployments.
How did it do? It was a lot more work than we expected to get Granny deployed to OpenShift. Swapping between the command-line deployment tool and the Web-based provisioning and management console lacked the user-friendliness of CloudBees or Cloud Foundry. The Red Hat Developer Studio plug-ins didn't work with our application out of the box. Ultimately, we had to edit a lot more descriptor files both inside and outside of the application than we did with other solutions.
Had we deployed a Java EE-compliant app, I'm sure OpenShift would have been friendlier. But when the command-line tool told me to run a command, then warned me that the command was deprecated, it left a bad taste in my mouth. This is truly a "developer preview" and rough around the edges.
Conclusions. If you're already developing JBoss applications, OpenShift may be a good fit. It's worth a preview now, but if you're looking to deploy to a PaaS today, it's not ready. Red Hat should continue to trumpet the Java EE compliance as a differentiating factor. However, even by 2006 when Andrew worked at JBoss, he noticed that most applications deployed in JBoss were written to the Spring Framework. Supporting Red Hat's existing customer base is all well and good, but greatness and business success will come from seamless deployment of applications developed by people who are not already in the Red Hat camp.
VMware Cloud Foundry
VMware bought SpringSource in 2009. Therefore, it isn't surprising that our "legacy" application, which was already based on the Spring Framework, worked seamlessly on Cloud Foundry. Although Cloud Foundry is still beta, it was very polished and worked well.
Differentiators. A key differentiator is the native support of the Spring framework. According to VMware, Cloud Foundry was built in collaboration with the SpringSource engineering team to ensure a seamless development, deployment, and management experience for Java developers. VMware also noted that Cloud Foundry is "unique in its multicloud approach," allowing developers to deploy the same application, without code or architectural changes, to multiple infrastructures both public and private. In fact this isn't unique, as OpenShift is similar, but VMware is uniquely positioned to do it. Unlike CloudBees, Heroku, and Red Hat, VMware has built its own cloud rather than building on Amazon Web Services.
Lock-in. VMware addressed the question of lock-in to my satisfaction. Because the platform is open source and there's a broad ecosystem of compatible providers (examples include CloudFoundry.com, Micro Cloud Foundry, AppFog, and Tier3), developers can easily move applications between Cloud Foundry instances, both on public clouds or private infrastructures. VMware noted that in addition to the multicloud flexibility, this open source flexibility ensures that developers and customers aren't locked into one cloud or one platform. As proof, the company pointed me to a blog post on extracting data using the Cloud Foundry data tunneling service, which is far and above "You can dump it to CSV and port it yourself."
Security. We were unable to find any published documentation on security certifications (PCI, SAE, and so on) for Cloud Foundry. VMware pointed me to its User Authentication and Authorization service, which appears to be a single sign-on scheme based on OAuth2. This could be a helpful service for application developers, but government organizations and large companies are going to require VMware to provide documentation of security certs before migrating to its cloud.
Who's using it? Cloud Foundry is well positioned to meet the needs of companies that want a combination of public and private PaaS. Its focus on an ecosystem of Cloud Foundry providers is a strong point, especially with regards to lock-in. Cloud Foundry is clearly aimed at Ruby, Node.js, and JVM-based languages. If you have a more diverse technology base, this may not be your first choice.
VMware pointed me to several published case studies, including Intel, Diebold, AppFog, Cloud Fuji, and others.
How did it do? We installed the Eclipse plug-in, deployed the WAR, and changed nothing. In fact, the first time we deployed Granny, we accidentally deployed it configured with CloudBees' JDBC information. Cloud Foundry automatically detected our Spring configuration and reconfigured the database settings for our Cloud Foundry database. This kind of magic may make some people nervous, but it worked seamlessly.
Conclusions. Cloud Foundry "just worked" -- we did nothing to the application but install an Eclipse plug-in. What's not to love? For ops teams, there's also a command-line interface. Once this PaaS launches, depending on pricing and such, it will certainly be a viable choice for Java developers. We can assume that for Ruby, which Cloud Foundry is written in, you would have a similar experience. (We have also tested the Node.js interface, which was a little trickier but still very workable.)
Cloud Foundry worked great and was the most straightforward. We were so successful with the Eclipse plug-in that we didn't try the command-line interface. Of course the test wasn't perfectly "fair" in that the app was a Spring app in the first place, but the app was written to be run on a local Tomcat instance, yet it deployed seamlessly to the Cloud Foundry cloud. Considering much of the legacy that will move to the cloud is Java and most existing Java apps are written in Spring, we're excited to see Cloud Foundry launch.