Summary:

CloudBees is now offering its RUN@cloud service as software that lets users build their own PaaS environments on OpenStack- or VMware vSphere-based infrastructure. Choice in PaaS deployment environments is becoming a new must-have feature, especially in light of Amazon’s recent outage and projects like Cloud Foundry.

Freedom-of-choice-a22077920

Platform-as-a-Service startup CloudBees is now offering its RUN@cloud service as software that lets users build their own PaaS environments on OpenStack- or VMware vSphere-based infrastructure. Until now, RUN@cloud has only been available as a public cloud service hosted atop Amazon EC2, but choice in where one hosts a PaaS is becoming a new must-have feature, especially in light of Amazon’s recent outage.

CloudBees CEO Sacha Labourey told me via e-mail that customers have been asking for this capability for a long time, but CloudBees decided to stick with its public-cloud-only approach for a while. However, he added, “As it became clear that for a significant number of the Java enterprises such an intermediary step is needed, we decided to embrace it and provide a unified story, from on-premise, to private external clouds, to public cloud.” But it need not just be an intermediary step. Customers designing to fail, so to speak, in order to avoid the fate of so many AWS customers over the weekend, might find a hybrid approach very compelling for the long run. And if OpenStack catches on, a collection of interoperable clouds provides a better public-cloud choice than using CloudBees’ hosted service. CloudBees, like other PaaS providers, was affected by the outage.

Labourey does acknowledge this latter option, too, where private clouds aren’t so much an intermediate step, but, possibly, a final destination made after much trial, error and thought:

This is really a two-step process instead of a single big step. In a first step, companies will learn how to interact with a PaaS, how to best make use of it, they will adapt their development and deployment processes, etc. Then, in a second step, they’ll be able to decide where they want their applications to run (on-premises or in the public cloud), with no impact on their processes since those will have already been adapted. This is actually a great way to increase the company’s cloud expertise while, in parallel, the public cloud offering matures to fit their requirements.

However customers decide to utilize RUN@cloud, though, CloudBees is once again demonstrating perfect timing in making major product advancements. Aside from the AWS outage, VMware recently announced its Cloud Foundry PaaS project that’s available both as a hosted service from VMware and as downloadable, open-source software that can run across a variety of environments. One big distinction between RUN@cloud and Cloud Foundry, though, is that the former supports Java applications only, while the latter supports Java along with a variety of other languages and frameworks. Both are open source. Late last year, after Red Hat bought PaaS provider Makara  and Salesforce.com bought Ruby PaaS Heroku , CloudBees made a small step toward consolidating its direct market by acquiring fellow Java PaaS provider Stax Networks and merging the two platforms.

Both RUN@cloud and Cloud Foundry have to keep their feet on the innovation gas pedals, though, because there’s plenty of competition for Java developers’ hearts. Google App Engine and Microsoft Windows Azure both support Java applications in the public cloud, and Red Hat (via Makara) and CumuLogic both offer downloadable software targeting Java applications. Red Hat will be announcing its first Makara offerings next month at its user conference, and CumuLogic is currently in private beta.

Image courtesy of Krzysztof Poltorak.

Comments have been disabled for this post