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 clouds

1 2 3 4 5 6 7 Page 4
Page 4 of 7

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.

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

1 2 3 4 5 6 7 Page 4
Page 4 of 7
How to choose a low-code development platform