Unlocking PaaS Power: A Deep Dive into Cloud Foundry Architecture and Extensions

PaaS Overview

Platform as a Service (PaaS) provides a unified runtime environment that abstracts infrastructure management, enabling developers to focus on code, testing, deployment and operations. By delivering on‑demand, standardized environments, PaaS reduces manual setup, eliminates configuration drift between development, test and production, and lowers overall delivery cost.

Technology Choices

Early adopters favored Cloud Foundry for its maturity. With containerization, alternatives such as OpenShift, Docker + Kubernetes, Docker + Mesos + Marathon and Cloudify have emerged. The optimal choice depends on specific functional and operational requirements.

Cloud Foundry Fundamentals

Cloud Foundry is an open‑source, production‑grade PaaS that supports multiple languages and frameworks. It has evolved through V1, V2 and V3 releases, each adding performance improvements, architectural refinements and container support via Garden and Diego.

Core Architecture

Routing & Load Balancing : haproxy and gorouter distribute incoming traffic to the Cloud Controller or DEA nodes.

Authentication & Authorization : UAA and the Login Server manage user identities and tokens.

Application Lifecycle Management : The Cloud Controller stores application metadata in CCDB, stages apps on DEA nodes, and works with the Health Manager (HM9000) to reconcile desired and actual app states.

Application Storage & Execution : The Blobstore holds source code, buildpacks and droplets; DEA (or Diego) runs the droplets inside containers.

Service Broker : Exposes managed services (e.g., MySQL) that can be bound to applications.

Messaging : NATS provides lightweight publish‑subscribe messaging for internal component communication.

Logging & Metrics : Loggregator aggregates application logs; Metrics Collector gathers performance data for monitoring.

Application Deployment Workflow

From the application root, run cf push using the cf CLI.

The CLI instructs the Cloud Controller to create an application record.

Metadata (name, instance count, selected buildpack, etc.) is persisted in CCDB.

Application files are uploaded to the Cloud Controller and stored in the Blobstore.

Running cf start triggers the staging phase.

A staging DEA (or Diego cell) selects the appropriate buildpack, resolves dependencies, and produces a droplet.

Staging logs are streamed back to the CLI for troubleshooting.

The resulting droplet is saved in the Blobstore.

The Cloud Controller schedules one or more runtime containers to run the droplet.

Running containers report health and status back to the Cloud Controller.

Buildpacks

Buildpacks detect the language/runtime requirements of an application, fetch necessary dependencies, and assemble a runnable droplet. Developers can modify existing buildpacks, create custom ones, or use community‑provided buildpacks (including those from Heroku). Typical usage patterns include:

Adapting a buildpack to install a specific middleware version or an APM probe.

Adding a .NET buildpack via the IronFoundry plugin and a Windows DEA.

Publishing custom buildpacks as offline packages and uploading them to the Blobstore.

Extending Cloud Foundry

Runtime Extensions : Custom buildpacks add middleware, instrumentation, or language runtimes.

Service Middleware Extensions : Implement Service Brokers to expose databases, caches, or other services. Example repositories:

https://github.com/cloudfoundry-community/spring-service-broker.git

https://github.com/cloudfoundry-samples/github-service-broker-ruby.git

Management UI / SDKs : Cloud Foundry’s REST API can be accessed via SDKs such as the Java client: https://github.com/cloudfoundry/cf-java-client.git Monitoring & Logging : Health Manager and DEA/Diego metrics provide basic health checks; custom logging or APM integration can be added for deeper insight.

Auto‑Scaling : Manual scaling commands can be automated by analyzing metrics and invoking scale‑out actions via the API.

Continuous Integration : Typical CI pipelines combine Git (source), Nexus/Artifactory (artifacts) and Jenkins (build/test/deploy) to push artifacts to Cloud Foundry automatically.

TCP Support : Adding a TCP router enables non‑HTTP services. Reference implementation:

https://github.com/cloudfoundry-incubator/cf-tcp-router.git

Diego – Next‑Generation Runtime

Diego replaces the legacy DEA and HM9000 components with a Go‑based container management system. It decouples scheduling from the Cloud Controller, supports both Linux and Windows workloads, and runs droplets inside Garden containers. In Cloud Foundry V3 the component stack includes:

Cloud Controller (CC)

UAA (authentication)

Diego (runtime)

Loggregator (log aggregation)

Gorouter (routing)

Buildpacks

Service Brokers

BOSH (deployment)

Diego resolves several limitations of earlier architectures: tight coupling between components, triangular dependencies among Cloud Controller, DEA and HM, and lack of native Windows support.