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

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.


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

Sign up for Computerworld eNewsletters.