Cloud Foundry Overview

Page last updated: November 20, 2015

The Industry-Standard Cloud Platform

Cloud platforms let anyone deploy network applications or services and make them available to the world in a few minutes. When an app becomes popular, the cloud easily scales it to handle more traffic, replacing with a few keystrokes the build-out and migration efforts that once took months.

Not all cloud platforms are created equal. Some have limited language and framework support, lack key application services, or restrict deployment to a single cloud. Cloud Foundry (CF) has become the industry standard. It’s an open source platform that you can deploy to run your apps on your own computing infrastructure, or deploy on an IaaS like AWS or vSphere. You can also use a PaaS deployed by a commercial CF cloud provider. A broad community contributes to and supports Cloud Foundry. The platform’s openness and extensibility prevent its users from being locked into a single framework, set of application services, or cloud.

Cloud Foundry is ideal for anyone interested in removing the cost and complexity of configuring infrastructure for their applications. Developers can deploy their applications to Cloud Foundry using their existing tools and with zero modification to their code.

Cloud Foundry Subsystems

Clouds balance their processing loads over multiple machines, optimizing for efficiency and resilience against point failure. A Cloud Foundry installation accomplishes this at three levels:

  1. The BOSH system creates and deploys virtual machines (VMs) on top of a physical computing infrastructure, and deploys and runs Cloud Foundry on top of this cloud. To configure the deployment, it follows a manifest document.

  2. The CF Cloud Controller runs the applications and other processes on the cloud’s VMs, balancing demand and managing app lifecycles.

  3. The (Go)router routes incoming traffic from the world to the VMs that are running the applications that the traffic demands, usually working with a customer-provided load balancer.

To meet demand, multiple VMs may run duplicate instances of the same application. This means the apps must be portable. Cloud Foundry distributes application source code to VMs with everything needed to compile and run the apps locally. This includes 1) the OS stack that the application runs on, and 2) a buildpack containing all languages, libraries, services etc. that the app uses. Before sending an app to a VM, the Cloud Controller stages it for delivery by combining stack, buildpack, and source code into a droplet that the VM can unpack, compile, and run. (For simple, standalone apps with no dynamic pointers, the droplet can contain a pre-compiled executable instead of source code, language, and libraries.)

To organize user access to the cloud and to control resource use, a cloud operator defines Orgs and Spaces within an installation and assigns Roles to all users: admin, developer, manager, auditor, etc. The User Authentication and Authorization (UAA) server supports access control as an OAuth2 service, and can store user information internally or connect to external user stores through LDAP or SAML.

Cloud Foundry uses the git system on github to version-control all source code, buildpacks, documentation, and everything else. Developers on the platform also use github, for their own applications, custom configurations, etc.

As the cloud operates, the Cloud Controller VM, router VM, and all VMs running applications continuously generate logs and metrics. The Loggregator system corrals this information into structured, usable form. This high-volume stream of event data, the Firehose, can be tapped in full, or else directed to specific uses by applying Nozzles—for example to monitor system internals or analyze user behavior.

Cloud Foundry components communicate with each other internally using the NATS messaging system.

Typical applications depend on free or metered services such as databases or third-party APIs. To incorporate these into an application, a developer writes a Service Broker, an API that publishes to the Cloud Controller the ability to list service offerings, provision the service, and enable applications to make calls out to it.