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 cloudsFollow @infoworld
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.