Review: Cloud Foundry Brings Power and Polish to PaaS

Cloud Foundry impresses with broad application support, streamlined deployment, and enterprise extras from Pivotal, though initial setup could be simpler

Cloud Foundry was created by VMware to streamline deployment for application developers, application operators, and cloud operators. Then in April 2011, Cloud Foundry was announced as open source under the Apache 2.0 license, with the pitch to developers that they could code in the language and Web framework of their choice without worrying about the IT environment.

In February 2014, VMware spin-off Pivotal announced the formation of the Cloud Foundry Foundation, with Pivotal, EMC, IBM, Rackspace, and VMware as Platinum sponsors. The foundation has since expanded to 33 members and 42 contributing companies. One differentiator for Cloud Foundry is support for Pivotal HD Hadoop MapReduce, HAWQ SQL for Hadoop, and GemFire XD analytics. Another is the availability of the Pivotal Mobile Services Suite, thanks to last year's acquisition of Xtreme Labs. Pivotal's big data services and mobile services are both now integrated with Pivotal CF, the company's enterprise version of Cloud Foundry.

Several Cloud Foundry Foundation members have released their own distributions of Cloud Foundry, including ActiveState with its Stackato product. The free Stackato Micro Cloud comes packaged for VirtualBox, VMware Fusion/Player, VMware vSphere, and KVM. While the Micro Cloud Foundry VM has not yet been updated to Cloud Foundry v2, you can install Cloud Foundry open source locally using either bosh-lite or cf_nise_installer. Bosh-lite supports VMware Fusion/Player, VirtualBox, and Amazon Web Services, while cf_nise_installer only supports VirtualBox.

I asked Pivotal about the lack of a Micro Cloud Foundry v2 VM and got this response from Jamie O'Meara, Pivotal CF community engineer:

Pivotal itself has two Cloud Foundry PaaS offerings: the online Pivotal Web Services, and the enterprise-oriented Pivotal CF. These are complemented by Pivotal HD and related cloud service offerings, as well as other specialized data offerings such as the Pivotal Greenplum RDBMS, Pivotal GemFire, and Pivotal SQLFire. In addition, Pivotal's acquisition last year of Xtreme Labs has given it a suite of mobile services that integrates with its PaaS and its big data services.

As mentioned in the statement by Jamie O'Meara, Pivotal CF runs on VMware, OpenStack, Amazon Web Services, and Google Cloud Platform.

Cloud Foundry architecture and featuresThe Cloud Foundry Elastic Runtime runs applications in packages called "droplets" in DEAs (Droplet Execution Agents). DEAs are managed by the Cloud Controller and monitored by the Health Manager, while Routers manage application traffic, do load balancing, and combine logs. In turn, DEAs call on service broker nodes, which communicate over a message bus. The Cloud Controller has access to a blob store and a database of application metadata and service credentials.

To deploy an application, the developer basically uploads the app bits and metadata, using the Cloud Foundry command line or plug-ins from Eclipse, Maven, or Gradle. In addition, the developer needs to create and bind services. This all boils down to building a WAR archive and uploading the WAR.

The Cloud Controller will automatically detect and load any necessary system buildpacks, create a droplet, deploy the application droplet to the DEAs, register the routes, and forward the ports. Once the DEAs are active, the Health Manager compares the expected state of DEAs from the Cloud Controller with the actual state from the DEAs. If the Health Manager detects a deviation, it will ask the Cloud Controller to restart any DEAs not in the expected state.

Administrators use BOSH, as opposed to other IT automation tools, such as Puppet or Chef, to manage the underlying infrastructure of Cloud Foundry. An open source tool chain for release engineering, deployment, and lifecycle management of large-scale distributed services, BOSH has its own command line, separate from the cf command line, but you don't need it to deploy an application. BOSH is for deploying VMs, not droplets.

At a very high level, BOSH clones new VMs from a "stemcell" to create the VMs needed for a deployment. A stemcell contains an operating system and an embedded BOSH agent that allows BOSH to control VMs cloned from the stemcell. A BOSH release is a collection of source code, configuration files, and startup scripts, with a version number that identifies these components. The BOSH deployment manifest is a YAML file defining the layout and properties of the deployment.

Cloud Foundry includes UAA (User Account and Authorization) and login servers. The UAA is the identity management service for Cloud Foundry. Its primary role is as an OAuth2 provider, issuing tokens for client applications to use when they act on behalf of Cloud Foundry users. However, it can also authenticate users with their Cloud Foundry credentials and act as an SSO (single sign-on) service. The login server performs authentication for the UAA, acting as a back-end service. The login server is where Cloud Foundry administrators set up their authentication sources, such as LDAP/AD, SAML, OpenID (Google, Yahoo, and so on), or social.

Down at the application execution level, the DEA uses Warden Linux containers. Warden provides a simple API for managing isolated, ephemeral, and resource-controlled environments, or containers. In the future, Cloud Foundry will support Docker containers.

A block diagram of the Cloud Foundry architecture. 

Deploying applications with buildpacksBuildpacks provide framework and runtime support for your applications. Four buildpacks are standard in Cloud Foundry and Pivotal CF: Java, Node.js, Ruby, and Go. (Stackato has Python instead of Go.) The good news is that buildpacks are readily available, easy to install, and even easy to construct, assuming you can write a few lines of Ruby or another scripting language. In most cases, the open source language and framework you want will be available as a buildpack, and all you'll need to load it will be a mention of the Git repository on the cf command line when you push your app:

$ cf push my-new-app -b git://github.com/johndoe/my-buildpack.git

Alternatively, mention the buildpack in your manifest. For example, a working WordPress for Cloud Foundry is available in this repository created by Daniel Mikusa. To install it, you simply clone the repo, which is not very big; create a MySQL service in your Cloud Foundry instance; edit the manifest and config files on your local machine; and cf push the app. The manifest.yml file looks like this before editing:

---applications:- name: mywordpress  memory: 128M  instances: 1  host: mywordpress  domain: cfapps.io  path: .  buildpack: https://github.com/dmikusa-pivotal/cf-php-build-pack.git  services:  - mysql-db

As you can guess, the buildpack line in the manifest references the Git repository of a PHP and Apache buildpack.

Cloud Foundry does messaging among the parts of its environment using NATS, a lightweight and distributed publish-subscribe messaging system written in Ruby.

1 2 Page
Insider Resume Makeover: Emphasize Your 'X Factor'
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies