Review: Cloud Foundry brings power and polish to PaaS

Cloud Foundry architecture and features
The 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.