eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The point of platform as a service is to enable developers to focus solely on their application code and data, leaving the maintenance of the underlying stack to the service provider. One of the biggest potential problems with this approach is that of lock-in: Moving from one PaaS (platform as a service) to another, in case of pricing, reliability or other service issues, can prove disruptive.
For instance, Google is in the process of changing the way it prices its AppEngine PaaS, which is resulting in higher hosting costs for many AppEngine users. The fact that AppEngine is available only from Google leaves most of these customers without an easy exit route.
Enter Cloud Foundry, an open-source PaaS project from VMware, which was first released in April with support for running applications written in Java Spring, Ruby on Rail and Node.js, with support for MySQL, Reddis and MongoDB data stores (see NoSQL story here).
Considering the central role that one’s cloud-hosting provider plays in a PaaS product, Cloud Foundry can’t solve the PaaS lock-in problem on its own. Rather, VMware is looking to fashion a sort of Linux of the PaaS world, along the same lines as what the Rackspace-sponsored OpenStack project seeks to accomplish in the infrastructure-as-a-service space.
Since its launch, Cloud Foundry has made good progress toward this goal, picking up support for additional runtimes and data services, and attracting a solid base of partners who are at work adding value to Cloud Foundry and packaging it for deployment in various forms. Last month, VMware announced a Community Leads program, in which project partners contribute and maintain compatibility for new Cloud Foundry languages.
Activestate, which is currently beta testing a private cloud version of Cloud Foundry, called Stackato, joined the project as a community lead for Python. PaaS vendor AppFog (formerly known as PHPFog) is serving as a lead for PHP support. In addition, AppFog has announced plans to migrate its existing PHP-based PaaS (see our review here) to a multi-runtime service based on Cloud Foundry.
Canonical is packaging Cloud Foundry for its upcoming Ubuntu 11.10 release, combined with Canonical’s own system orchestration facility, called Ensemble. Through Canonical’s work, it’s possible to launch a Cloud Foundry deployment that runs on Amazon EC2 and spans multiple virtual machines, with support for scaling out the hosting VMs as needed.
For its own part, VMware maintains a developer preview Cloud Foundry service at cloudfoundry.com, and offers a “micro” edition of the PaaS for use from a downloadable virtual machine image. What’s more, the code for Cloud Foundry is available for download from a Github repository, complete with an installation script for getting the PaaS project up and running on a single Ubuntu 10.04 server instance.
Cloud Foundry in Action
I tested Cloud Foundry as distributed by VMware, Canonical and Activestate, as well as direct from the latest code available at Github. From the perspective of a user deploying Web applications, I found Cloud Foundry very easy to use-the client application for the service, which is written on Ruby and runs on Windows, Mac and Linux, sports a simple command syntax that I used to create, update, monitor, allocate resources to, scale, and decommission the simple applications with which I tested.
On the back end, Cloud Foundry consists of a collection of server components, with a cloud controller to manage the system, a DEA (Droplet Execution Agent) service to host individual applications, a set of services for serving data, a health manager for monitoring the state of the system and a router service for maintaining communications between the components. All of these components can run on a single machine for testing, and can be spread out among multiple nodes for production.
Activestate’s Stackato builds on the Cloud Foundry base with support for Python and Perl, with a pair of additional client-side features, and with built-in facilities for creating and managing a multi-node Cloud Foundry cluster.
Stackato’s added client-side features, run and dbshell, address a limitation of Cloud Foundry’s push-and-run deployment model, which lacks support for working interactively with hosted applications. I was able to run arbitrary commands on particular instances and invoke an interactive database shell for data services bound to my applications.
I deployed Stackato on a VMware vSphere 5 cluster in our lab using an OVF template provided by Activestate. The VM was configured to run as a single server, but I was able to convert it to a multi-node configuration by creating a few clones of the VM, and using Activestate’s stackato-admin tool to assign specific roles to each node. I tested with a three-node cluster, with one node for the DEA service, another the data services, leaving the cloud controller and other functions on the third node.
Also notable for its back-end support enhancements is Canonical’s integration work around Cloud Foundry, which the Linux vendor is slated to support in the upcoming Ubuntu 11.10. Compared to the source-based install of Cloud Foundry, using Canonical packages for the project cut significantly the time it took me to get up and running.
Though I’ve yet to test them myself, I’m also impressed by what I’ve seen of Canonical’s work building Cloud Foundry formulas for Ensemble, Canonical’s service orchestration effort, which further speeds the process of deploying and scaling Cloud Foundry nodes. For a detailed how-to on Cloud Foundry and Ensemble, click here.