The PaaS space has witnessed a lot of changes since the advent of Cloud Foundry in 2012. There are, of course, various distributions of the open source core, but the assembled ecosystem of Pivotal Cloud Foundry is one of the most impressive in the lot.
So, what is Pivotal Cloud Foundry?
Cloud Foundry is an open source cloud platform as a service (PaaS) that provides a choice of clouds, application services, and developer frameworks to clients. Cloud Foundry makes the process of building, testing, deploying and scaling applications must easier and faster.
Since it is an open source project, it is made available through various private cloud distributions as well as public cloud instances. Cloud Foundry leverages BOSH, an open source tool for lifecycle management, release engineering, deployment, and distributed systems monitoring so that it can be configured, managed, deployed, scaled, and upgraded on any cloud IaaS provider.
Overview of Pivotal Cloud Foundry
Cloud platforms enable anyone and everyone to deploy network applications or services and make them available to the world within minutes. When an application becomes popular, the cloud scales it up to handle more traffic.
However, not all cloud platforms are created equal. Some have limitations in terms of language and framework support, while others lack key application services, or restrict deployment to a single cloud. Therefore, Cloud Foundry has become the industry standard. This open source platform lets you run your apps on your own computing infrastructure, or it can be deployed on an IaaS like AWS, vSphere, and OpenStack.
Cloud Foundry is supported by a broad community that contributes to the extensibility and versatility of this cloud platform. Cloud Foundry simplifies the process of deployment by removing the cost and complexity of configuring infrastructure for their apps. Cloud Foundry allows developers to deploy their apps using existing tools without any modification to their code.
Overview of Deploying Cloud Foundry
Cloud Foundry boasts a design that is capable of being configured, deployed, managed, scaled, and upgraded on any IaaS provider. As we have mentioned before, Cloud Foundry leverages BOSH to achieve this.
At a conceptual level, the steps of deploying Cloud Foundry are the same regardless of the IaaS provider. Here follow the steps to deploy Cloud Foundry on IaaS:
Set up all external dependencies, such as external load balancers, IaaS account, DNS records, and other additional components (if required).
- Create a manifest for deploying a BOSH Director.
- Deploy the BOSH Director.
- Now, create a manifest in order to deploy Cloud Foundry.
- Finally, deploy Cloud Foundry.
What are Cloud Foundry Components?
Now that we have an idea of how Cloud Foundry is deployed on an IaaS, let’s take a brief look at the components of Pivotal Cloud Foundry.
To summarize, Cloud Foundry components comprise a scriptable command line interface (CLI), a self-service application execution engine, and an automation engine for application deployment and lifecycle management. Cloud Foundry is also integrated with development tools to enable seamless deployment processes. Cloud Foundry boasts of an open architecture which consists of a cloud provider interface, an application services interface, and a buildpack mechanism for adding frameworks.
Let’s take a deeper look at the components now:
The router directs incoming traffic to the concerned component, which is either a Cloud Controller or a hosted application running on a Diego Cell.
OAuth2 Server (UAA) and Login Server
The OAuth2 server (UAA) and Login Server work together to deliver identity management services.
Cloud Controller and Diego Brain
The Cloud Controller (CC) administers the deployment of applications. It is the Cloud Controller which has to be targeted to push an app to Cloud Foundry. The Cloud Controller then commands the Diego Brain via the CC-Bridge to coordinate with individual Diego cells to stage and run applications.
nsync, Cell Reps, and BBS
The nsync, Cell Reps, and BBS components work in collaboration along a chain to keep applications running by constantly monitoring their states and reconciling them with their expected states, starting and stopping processes as and when required.
The blobstore is basically a repository for large binary files that cannot be managed Github. Blobstore binaries consist of application code packages, droplets, and buildpacks.
Each application virtual machine has a Diego Cell that executes the start and stop actions of an application locally, manages the virtual machine’s containers, and reports app status and other data to Loggregator and the BBS.
Service brokers are service providers that offer necessary services to run the applications. When a developer provisions a service to an application, the service broker is responsible for providing the particular service instance.
A Consul server stores control data that lives longer, such as component IP addresses and distributed locks, to prevent components from duplicating actions.
Diego’s Bulletin Board System (BBS) stores data that are disposable and are frequently updated such as heartbeat messages, cell, and application status, unallocated work, etc. The BBS uses Go MySQL Driver to store data.
The Loggregator, an amalgamation of the words “log” and “aggregator”, streams application logs to developers.
The metrics collector helps operators to monitor a Cloud Foundry deployment by gathering metrics and statistics from the components.
How Cloud Foundry Works
Cloud Foundry consists of subsystems that perform specialized functions to serve and scale apps online. Here is a brief overview of how some of these subsystems work:
How The Cloud Balances Its Load
Cloud balances its processing load over multiple machines, optimizing for efficiency and resilience. For a Cloud Foundry installation, this is accomplished in the following ways:
- BOSH creates and deploys virtual machines (VMs) over a physical computing infrastructure, and then deploys and runs Cloud Foundry on top of the cloud.
- The Cloud Foundry Cloud Controller runs the applications and other processes on the cloud’s VMs to manage app lifecycles and balance demand.
- The router directs incoming traffic to the VMs that run the apps that are in demand, usually working with a customer-provided load balancer.
How Apps Run Anywhere
Cloud Foundry assigns two types of VMs, the component VMs that constitute the platform’s infrastructure, and the host VMs that host applications for the world. The Diego system distributes the hosted app load over all of the host VMs within Cloud Foundry and keeps it running and balanced through demand surges, outages, or other changes.
Cloud Foundry distributes app source code to VMs, including the OS stack on which the app runs, and a buildpack containing all libraries, languages, and services that the app uses. Cloud Controller stages an app for delivery by combining stack, buildpack, and source code into a droplet before sending it to a VM.
How Cloud Foundry Organizes Users and Workspaces
A cloud operator defines Orgs and Spaces within an installation and designates Roles like developer, admin, or auditor to each user in order to organize user access to the cloud and to control resource use.
The User Authentication and Authorization (UAA) server backs access control as an OAuth2 service, and stores user information internally or connects to the external user stores through SAML or LDAP.
How Cloud Foundry Stores Resources
Cloud Foundry leverages the git system on GitHub to version-control source code, documentation, buildpacks, and other resources. GitHub is also used by developers on the platform, for their own apps, and custom configurations. Cloud Foundry maintains an internal or external blobstore to store large binary files like droplets.
How Cloud Foundry Components Communicate With Each Other
Cloud Foundry components interact with each other by posting messages internally with the help of HTTP and HTTPS protocols, and by sending NATS messages to each other directly.
How Cloud Foundry Monitors and Analyzes a Deployment
The router VM, Cloud Controller VM, and all VMs that are running apps continuously generate logs and metrics throughout the cloud operation. The Loggregator system aggregates the metrics in a usable form, called the Firehose. All of the output of the Firehose can be used or directed to specific uses, such as monitoring system internals or analyzing user behavior, by applying nozzles.
How to Use Services with Cloud Foundry
Typically, apps depend on free or metered services like databases or third-party APIs. To use such services in Cloud Foundry, a developer needs to write a Service Broker, an API that provisions the services and enables the apps to make use of the service offerings.