Originally reported by SDxCentral (April 2020). Attribution: SDxCentral.com
Leadership Transition at the Cloud Foundry Foundation
The Cloud Foundry Foundation (CFF) announced a leadership change in early April 2020, with Chief Technology Officer Chip Childers assuming the role of Executive Director, succeeding Abby Kearns. Kearns had held the position since late 2016, taking over from Sam Ramji, who had departed to join Google alongside former CFF Executive Director Diane Greene.
In an interview with SDxCentral, Childers described the transition as “a great moment in time,” framing it as an opportunity for the foundation to become “very laser focused on the most important aspects of what the foundation has been doing historically.” He emphasized continued stewardship of the Cloud Foundry community and a commitment to helping its members grow as “great participants in the broader open source ecosystem.”
Why Kubernetes Is Central to Cloud Foundry’s Strategy
A core theme of the leadership transition is a tightened strategic focus on Kubernetes. Childers openly acknowledged that Kubernetes, despite its dominance in container orchestration, remains a complex platform to operate in production environments — a reality reflected in the proliferation of managed Kubernetes services offered by major cloud vendors.
Rather than competing with Kubernetes directly, the CFF has chosen a complementary path: positioning Cloud Foundry as a simplified, developer-friendly abstraction layer sitting on top of Kubernetes. The goal is to deliver “the best enterprise developer experience” while removing “any of the infrastructure conversation” from developers’ day-to-day workflows.
This approach gives Cloud Foundry a clear role in a Kubernetes-centric world:
- Cloud Foundry acts as the application-control layer — the developer-facing interface for deploying and managing applications.
- Kubernetes acts as the infrastructure-control layer — handling container scheduling, scaling, and cluster management underneath.
Key Projects Bridging Cloud Foundry and Kubernetes
Project Eirini
Adopted into the CFF in late 2018, Project Eirini serves as a bridge between Cloud Foundry’s legacy Diego container scheduling system and Kubernetes. In practical terms, Eirini allows Cloud Foundry deployments to use Kubernetes as their container orchestration backend, rather than Diego. This is the foundation upon which Cloud Foundry users can build Kubernetes-orchestrated workloads without leaving the familiar Cloud Foundry developer experience.
Project Quarks
Project Quarks enables Cloud Foundry’s BOSH-managed components to be packaged and run as containers on top of Kubernetes. This effectively allows the traditional BOSH-based Cloud Foundry deployment model to be containerized and managed natively within a Kubernetes cluster, reducing operational overhead for platform teams.
KubeCF Runtime
In March 2020, the CFF adopted the open source KubeCF runtime as an incubating project. KubeCF builds on Project Quarks to provide a Cloud Foundry runtime that runs entirely on Kubernetes. This allows organizations to run full Cloud Foundry deployments on standard Kubernetes infrastructure, further aligning the two ecosystems and simplifying the operational footprint for enterprises already invested in Kubernetes.
Community, Diversity, and Industry Outreach
Beyond the technical roadmap, Childers outlined a broader community agenda for the foundation. He committed to increasing focus on diversity and inclusivity within the Cloud Foundry community, and to creating pathways for newcomers to engage with the project.
A specific area of emphasis is reaching enterprise developers who may not yet have access to modern cloud-native platforms and who are still tied to legacy processes. Childers described plans for programs designed to “help move the whole software development industry forward by reaching to the late adopters and bringing them along for the ride.”
The CFF also stated its mission clearly: “to curate from the broader open source ecosystem, as well as the software that our community creates, to provide a developer-centric platform.”
What This Means for DevOps Teams
For DevOps and platform engineering teams evaluating Cloud Foundry in 2020 and beyond, these developments carry a few practical implications:
- Kubernetes investment is preserved: Teams already running Kubernetes can deploy Cloud Foundry on top of existing clusters using KubeCF, rather than maintaining a separate infrastructure footprint.
- Developer experience remains the differentiator: Cloud Foundry’s value proposition — push-to-deploy simplicity, built-in routing, service binding, and multi-tenancy — is being preserved and layered onto Kubernetes rather than replaced by it.
- Eirini and Quarks reduce lock-in concerns: The move away from Diego toward Kubernetes-native scheduling addresses a long-standing concern about Cloud Foundry’s compatibility with the broader container ecosystem.
- Foundation stability: The leadership transition, while significant, appears designed for continuity rather than strategic disruption.
Looking Ahead
At the time of the announcement, Childers hinted at additional news expected to emerge “every week” throughout April 2020, suggesting an active period of announcements for the foundation. The measured, community-first approach under new leadership signals that CFF intends to evolve Cloud Foundry incrementally rather than through disruptive pivots — a posture that may suit risk-averse enterprise adopters well.