Cloud Foundry is large and complex, because that is what happens when we build software to automate tasks we’ve been doing manually. In this series, we are previewing the Cloud Foundry for Developers training course to help you better understand what Cloud Foundry is and how to use it. In case you missed the previous articles, you can catch up here:
and download the sample chapter here.
Platform Evolution
Back in the olden days, provisioning and managing IT stacks was complex, time-consuming, and error-prone. Getting the resources to do your job could take weeks or months.
Infrastructure-as-a-Service (IaaS) was the first major step in automating IT stacks, and introduced the self-service provisioning and configuration model. VMware and Amazon were among the largest early developers and service providers.
Platform-as-a-Service (PaaS) adds the layer to IaaS that provides application development and management.
Cloud Foundry is for building Platform as a Service (PaaS) projects, which bundle servers, networks, storage, operating systems, middleware, databases, and development tools into scalable, centrally-managed hardware and software stacks. That is a lot of work to do manually, so it takes a lot of software to automate it.
Cloud Foundry Command-Line Interface
The Cloud Foundry command-line interface (CLI) is the cf command. You run cf on your local machine to log in to remote Cloud Foundry instances and perform operations such as view logs, manage apps, run health checks, manage buildpacks, manage users, manage plugins, and many more. cf is written in Go, and it is extensible via plugins.
In part 4 in this series, we’ll learn how to install and use cf. To learn more, visit Cloud Foundry CLI and cf CLI Plugins.
Cloud Controller
The Cloud Controller exposes the REST APIs of Cloud Foundry. This is the endpoint that the the cf command talks to when you interact with a Cloud Foundry instance.
As a developer, one of the first things you will do is push an application to Cloud Foundry using the CLI. The Cloud Controller responds to client requests and then interacts with the appropriate Cloud Foundry components to deploy, run, and manipulate your applications and services. In part five of this series we will learn how to push an application.
To learn more, visit Cloud Foundry API and Component: Cloud Controller.
Diego Container Management System
The Diego Container Management System is responsible for the lifecycle of applications and tasks. Diego sees applications as long-running processes, like a Java-based online transaction processing (OLTP) application, or a Rails Web application. One-off processes, e.g. a database migration, are called tasks. Both applications and tasks are run inside containers.
Diego contains one or more compute nodes (virtual machines) called cells. Cells run containers, which execute applications and tasks.
To learn more visit Diego Components and Architecture and Cloud Foundry Containers.
Gorouter for Scalable Dynamic Routing
The router is responsible for routing traffic into applications and to the cloud controllers. As application instances are spun up and down, die and are recreated, fast automatic updating of route tables is crucial. Your applications might scale up or down. Instances might crash or Diego Cells might go offline. The router ensures traffic is routed appropriately to live, available instances.
To learn more visit Component: Gorouter.
Buildpacks for Dependencies
Buildpacks manage dependencies, such as Ruby, Node, or Java Runtime Environment (JRE). As a developer, you want your applications to run in a consistent manner. Buildpacks provide this consistency for developers and operators, by centralizing the container and runtime configuration logic, and are extensible and customizable.
Buildpacks prepare applications for execution inside containers in Diego. Applications go through a process called staging. This is where runtime dependencies are added, memory allocations are calculated, and start commands are set. The output is called a droplet, which is a combination of the application and the runtime dependencies.
To learn more visit Buildpacks.
Loggregator
How do we know what is happening on this complex always-changing platform? We need logs and metrics. Loggregator automatically aggregates your logs for you. Cells collect logs from all application instances and forward them to the Loggregator.
To learn more visit Loggregator.
User Account and Authentication (UAA)
The User Account and Authentication (UAA) service provides fine-grained control for our complex systems. UAA is a OAuth2 provider for securing the Cloud Foundry platform, and for individual applications. It provides enterprise-level authentication features such as single-sign on, or using an LDAP store for user credentials.
To learn more visit User Account and Authentication (UAA) Server and OAuth 2.0.
Service Broker API
Applications often need services like databases, caches and messaging systems. Service brokers provide access to these services in Cloud Foundry through a standardized interface. This interface allows services to be provisioned and consumed using the Cloud Foundry APIs, without knowledge of the underlying service. For example, you can write an application that leverages MySQL without knowing how to deploy or manage MySQL, or even knowing how the broker is provisioning the database.
Service brokers implement an API and are registered with the Cloud Controller. Developers issue service management commands via the Cloud Foundry CLI, which communicates them to the Cloud Controller, which, in turn, invokes the service APIs and provisions, de-provisions, configures, and manages the underlying service.
The Service Broker API provides a key extension point for Cloud Foundry. If you can implement the API, you can expose your services in the platform.
To learn more visit Broker Overview and Open Service Broker API.
Come back for part 4 to learn how to install and use the Cloud Foundry CLI, and in part 5 deploy and application.
The information in this series is based on the Cloud Foundry for Developers (LFD232) training course from Cloud Foundry and The Linux Foundation. You can download a sample chapter from the course here.
