Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Which freaking PaaS should I use?

Andrew C. Oliver and Lifford Pinto | Oct. 10, 2012
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).

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.

 

Previous Page  1  2  3  4  5  6  7  8  9  10  Next Page 

Sign up for Computerworld eNewsletters.