At SpringOne Platform 2019, Matthias Haeussler and Dr Nic Williams delivered a session titled “Platforms Demystified,” comparing major cloud platforms from a developer perspective. This article summarises the key concepts, tools, and architectural decisions they covered, including Cloud Foundry, Kubernetes, Project Eirini, Project Quarks, Cloud Native Buildpacks, kpack, and Knative. The original talk was reported by InfoQ.
What Makes a Platform?
Haeussler and Williams opened with a history of container technology, tracing a timeline from chroot in 1979 through to Knative and Project Eirini in 2018. The historical arc frames an important insight: a mature cloud platform is not just an orchestrator — it is an opinionated layer that delivers real value to every role in the organisation.
According to the speakers, a well-designed platform should provide:
- Self-service for developers — deploy, scale, and inspect applications without filing tickets.
- Coherent UX for all support roles — operators, security engineers, and platform teams each have clear, role-appropriate interfaces.
- Automation and monitoring — health checks, log aggregation, and metrics out of the box.
- Self-healing and resource optimisation — the platform restarts failing instances and manages capacity automatically.
- Application focus over infrastructure focus — developers describe what to run, not how to wire up infrastructure.
Avoiding the “Not Invented Here Platform” Anti-Pattern
One of the talk’s strongest warnings was about teams that believe they are not using a platform. Haeussler and Williams argued that if you are not adopting a standard platform, you are implicitly building your own — often without realising it. Custom deployment scripts, internal tooling chains, and bespoke CI pipelines accumulate into an undocumented, undertested DIY cloud platform that nobody fully owns.
Standard platforms do impose constraints, but those constraints exist because they solve common problems at scale. Teams that bypass them frequently end up solving the same problems themselves, at greater cost and with less reliability.
Cloud Foundry: Developer-Centric Deployment
Cloud Foundry (CF) remains one of the most developer-friendly platforms available. The developer workflow is deliberately simple. Core CLI commands include:
# Push an application
cf push my-app
# Scale horizontally
cf scale my-app -i 3
# Open an SSH session into a running instance
cf ssh my-appCode language: PHP (php)The platform handles buildpack detection, container image creation, routing, and health management automatically. Developers interact with logical concepts (apps, spaces, orgs) rather than infrastructure primitives.
Project Eirini: Kubernetes as a CF Backend
Project Eirini is an effort within the Cloud Foundry ecosystem to replace the default Diego container scheduler with Kubernetes. Instead of Diego cells, Eirini deploys application container instances as OCI-compliant images onto a Kubernetes cluster. The result is that operators can choose their scheduling backend — Diego or Kubernetes — without exposing that choice to application developers, who continue to use the standard cf push workflow.
Key points about Eirini:
- Translates Cloud Foundry’s application model into Kubernetes
StatefulSetsand related primitives. - Uses OCI images as the deployment artifact, enabling compatibility with standard container registries.
- Preserves the CF developer experience entirely — no Kubernetes knowledge required from app teams.
Project Quarks: Containerising the CF Control Plane
While Eirini targets application workloads, Project Quarks (also from the Cloud Foundry Foundation) targets the Cloud Foundry control plane itself. Traditionally, Cloud Foundry Application Runtime (CFAR) is deployed and managed by BOSH, which treats VMs as the unit of deployment. Quarks repackages CFAR components as containers, making the entire platform deployable on Kubernetes.
The goal is to provide an identical developer experience to a BOSH-managed CF installation, while reducing operational overhead for organisations already running Kubernetes. Eirini and Quarks are complementary: Quarks runs the CF control plane on Kubernetes, while Eirini uses Kubernetes to schedule application instances.
Cloud Native Buildpacks: Standardising the Build Process
Cloud Native Buildpacks (CNBs) is a joint CNCF project that defines a standard interface for transforming application source code into OCI images. The goal is to decouple the build process from any specific platform, so the same buildpack can produce images for Cloud Foundry, Kubernetes, or a local development environment.
CNBs provide several operational advantages beyond basic builds:
- Layer rebasing — update the OS or runtime layer in an existing image without rebuilding application layers, dramatically reducing patch time.
- OS-level updates — apply security patches to base images and automatically propagate them to all derived application images.
- Vulnerability detection — identify outdated or vulnerable layers and trigger targeted updates across a cluster.
- Local and cluster execution — developers can run the same build process on their laptop that runs in CI.
kpack: Kubernetes-Native Buildpack Builds
kpack is a Kubernetes-native implementation of Cloud Native Buildpacks. It uses Kubernetes Custom Resource Definitions (CRDs) to represent build configurations, making image builds a first-class Kubernetes primitive. When source code or a buildpack is updated, kpack automatically triggers a new build and publishes the updated OCI image to a registry.
At the time of the talk, kpack was part of the Pivotal Build Service. It integrates with standard Kubernetes RBAC and works with any OCI-compliant registry.
Open Service Broker API: Plug-and-Play Backing Services
The Open Service Broker API (OSB API) is an open specification that allows cloud vendors to expose managed backing services — databases, message queues, caches — to workloads running on Cloud Foundry, Kubernetes, or other platforms using a common API surface. This gives organisations a consistent way to provision and bind services regardless of the underlying platform, reducing lock-in and simplifying operator workflows.
Istio: Service Mesh for Cloud Native Applications
The speakers demonstrated how Istio can be layered into cloud native deployments to provide traffic management, mutual TLS, observability, and policy enforcement between services. Istio operates as a sidecar proxy alongside each application instance, making network behaviour configurable through declarative Kubernetes resources rather than application code changes.
Knative: Serverless Workloads on Kubernetes
Knative is an open-source platform built on Kubernetes that adds serverless capabilities. It is designed to run event-driven and request-driven workloads efficiently. Key features include:
- Scale-to-zero — idle workloads consume no resources and spin up automatically on incoming requests.
- Autoscaling — Knative Serving scales instances up and down based on concurrency or request rate.
- In-cluster builds — Knative Build (now superseded by Tekton) provided a build pipeline primitive inside Kubernetes.
- Eventing framework — Knative Eventing provides a broker-and-trigger model for routing CloudEvents between producers and consumers.
Knative sits above raw Kubernetes and can be combined with Istio for advanced traffic routing, enabling capabilities like canary deployments and traffic splitting at the serverless layer.
Platform Comparison Summary
| Capability | Cloud Foundry (Diego) | CF + Eirini | Knative on K8s |
|---|---|---|---|
| Developer abstraction | High (cf push) | High (cf push) | Medium (YAML / CLI) |
| Scheduling backend | Diego | Kubernetes | Kubernetes |
| Scale-to-zero | No | No (by default) | Yes |
| Build standardisation | CF Buildpacks | Cloud Native Buildpacks / kpack | Tekton / CNBs |
| Service binding | OSB API | OSB API | OSB API / custom |
| Control plane packaging | BOSH VMs | Quarks (containers) | Helm / operators |
Video: SpringOne Platform 2019 Session
The full session playlist from SpringOne Platform 2019 is available on YouTube:
Key Takeaways
- Every engineering team uses a platform — the question is whether it is a well-maintained standard one or an accidental DIY creation.
- Cloud Foundry and Kubernetes are converging through projects like Eirini and Quarks, not competing.
- Cloud Native Buildpacks and kpack provide a portable, secure build abstraction that works across platforms.
- Knative adds serverless semantics — particularly scale-to-zero and eventing — to Kubernetes without replacing it.
- Open Service Broker API reduces vendor lock-in by standardising how backing services are provisioned and bound.
Original talk coverage by InfoQ. Presented by Matthias Haeussler and Dr Nic Williams at SpringOne Platform 2019.