Cloud Foundry is attracting a solid base of partners, who are adding value and are packaging the PaaS project for deployment in various forms.
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.
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
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
Cloud Foundry in Action
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
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
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.