Cloud Foundry is an industry standard cloud application platform. Developers can use it to build apps without having to worry about the nitty-gritty of hardware and software maintenance. By focusing solely on the application, they can be more productive.
Cloud Foundry is an open source, Platform as a Service (PaaS) offering, governed by the Cloud Foundry Foundation. You can deploy it on AWS, Azure, GCP, vSphere or your own computing infrastructure.
The different landscapes for applications
Let’s take a step back and quickly check out all the landscapes for applications. If you want an application to cater to one of your needs, there are several ways of getting it to do so.
1. Traditional IT: In a traditional landscape, you can procure your infrastructure, manage all the servers, handle the data and build applications on top of it. This gives you the most control, but also adds operational complexity and cost.
2. Infrastructure as a Service (IaaS): In this case, you can buy or lease the infrastructure from a service provider, install your own operating system, programming runtimes, databases, etc, and build your custom applications on top of it. Examples include AWS, Azure, etc.
3. Platform as a Service (PaaS): With this, you get a complete platform from the service provider, with the hardware, operating system, and runtimes managed by the service provider –you can build applications on top of it. Examples include Cloud Foundry, OpenShift, etc.
4. Software as a Service (SaaS): Here, the service provider has already a pre-built application running on the cloud —if it suits your needs, you just get a subscription and use it. There might be a pre-existing application to meet your needs but if there isn’t, this offering provides very little room for customization. Examples include Gmail, Salesforce, etc.
Why opt for a PaaS offering like Cloud Foundry?
Choosing a PaaS offering has multiple benefits. It abstracts away the hardware and infrastructure details so your workforce can concentrate more on application development, and you require very few operations to be managed by the IT team. This leads to faster turnaround times for your applications and better cost optimization. It also helps in rapid prototyping as you have the platform taken care of; so you can build prototypes around your business problems more rapidly.
Figure 1: Cloud landscapes
Cloud Foundry: A brief description
Cloud Foundry is multi-cloud, open source software that can be hosted on AWS, Azure, GCP or your own stack. Since Cloud Foundry is open source, you get application portability out-of-the-box, i.e., you are not locked into a vendor. You can build your apps on it and move them across any of the Cloud Foundry providers.
The Cloud Foundry project is managed by the Cloud Foundry Foundation, whose mission is to establish and sustain the development of the platform and to provide continuous innovation and value to the users and operators of Cloud Foundry. The members of the Cloud Foundry Foundation include Cisco, Dell, EMC, GE, Google, IBM, Microsoft, Pivotal, SAP, SUSE and Vmware.
From a developer’s point of view, Cloud Foundry has support for buildpacks and services. Buildpacks provide the framework and runtime support for apps. Typically, they examine your apps to determine what dependencies to download, and how to configure the apps to communicate with bound services. Services are often externally managed components that may or may not be hosted on the Cloud Foundry stack (examples include databases, caches, etc). They are available in the marketplace and can be consumed by the application by binding to them.
Cloud Foundry architecture
Cloud Foundry components can be broadly classified into the following categories.
1. Routing
• Router: This is the entry point into the Cloud Foundry (CF) instance. CF provides REST services for administration purposes too. So, the call is initially received by the router and redirected to the cloud controller, if it’s an administration call, or to an application running on the stack.
2. Authentication
• User account and authentication (UAA) server: The role of the UAA server is to log in users and issue OAuth tokens for those logged in, which can be used by the applications. It can also provide SSO services and has endpoints for registering OAuth clients and user management functions.
3. Application lifecycle
• Cloud connector: The cloud connector is responsible for the deployment of applications. When you push an app to CF, it reaches the cloud connector, which coordinates with other components and deploys the application on individual cells in your space.
• Application availability components (nsync, BBS and Cell Reps): These components are responsible for the health management of the applications. They constantly monitor an application’s state and reconcile them with their expected states, starting and stopping processes as required.
Figure 2: Cloud Foundry architecture
4. App storage and execution
• BLOB storage: This is binary storage, which stores your application binaries and the buildpacks that are used to run the applications.
• Application execution framework (Diego): Application instances, application tasks and staging tasks all run as Garden containers on the Diego cell VMs. The Diego cell rep component manages the life cycle of those containers and the processes running in them. It reports their status to the Diego BBS, and emits their logs and metrics to Loggregator.
5. Services
• Service broker: Cloud Foundry has external components like a database, SaaS applications and platform features (e.g., the platform can offer services for analytics or machine learning), which are classified as services. These services can be bound to an application and be consumed by it. The service broker is responsible for provisioning an instance of the service and binding it to the application.
6. Messaging
• The platform’s component VMs communicate with each other and share messages over HTTP and HTTPS. This component is responsible for sharing messages, and also storing long-lived data (like the IP address of a container in a Consul server) and short-lived data (like application status and heartbeat messages) on Diego’s bulletin board system.
7. Metrics and logging
• Metrics collector: This collects statistics from the components, which are used for book-keeping and health management by the framework as well as by the operators managing the infrastructure.
• Loggregator: Applications built on top of the Cloud Foundry stack need to write their logs on the system output streams. These streams are received by the Loggregator, which can be used to redirect them to file systems, databases or to external log management services.
Cloud Foundry is a highly scalable, easy-to-manage, open source platform that can be used to develop applications of all types and sizes. To get further information about the ecosystem, you can visit https://www.cloudfoundry.org.