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.
Sign up for Computerworld eNewsletters.