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.
This article, "Which freaking PaaS should I use?," originally appeared at InfoWorld.com. Follow the latest developments in cloud computing at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.