blog single gear

Connecting the Dots from Cloud Foundry to Kubernetes

When I took on the role of Executive Director last month, I wrote about the Cloud Foundry ecosystem’s shift to focus on bringing the value of the Cloud Foundry developer experience to Kubernetes users. This change has been happening slowly within our community since 2018, but has accelerated dramatically over the last couple of months. In just the last six weeks, we have accomplished an extraordinary amount of work aligned around the goal of integrating Cloud Foundry and Kubernetes. I’d like to take a moment to revisit these achievements.

It’s amazing how much progress and real world impact the Cloud Foundry community has made in just five years as a foundation. Dell Technologies and I are excited about the transition to the next phase with Chip taking the lead. It is a critical time as the cloud native ecosystem coalesces into a more system oriented structure. The alignment with Kubernetes and other projects allows us to remove duplication, get project and community leverage and ultimately should accelerate Cloud Foundry into its next role as the best developer experience in the Kubernetes ecosystem.
– John Roese, CTO, Dell Technologies


In March, the Cloud Foundry Foundation accepted KubeCF as its newest incubating project. Contributed by SUSE, KubeCF is an open source distribution of Cloud Foundry Application Runtime (CFAR) designed to run on top of — you guessed it — Kubernetes. It provides the full CFAR experience to which Cloud Foundry developers are accustomed to Kubernetes clusters, and gives platform operators the ability to manage the infrastructure abstraction with Kubernetes tools and APIs. KubeCF is an integral piece in building the bridge between these two projects and communities. It lets users get the existing Cloud Foundry platform architecture deployed into a Kubernetes environment.

“I am extremely excited that we’re bringing `cf push` to Kubernetes. It means getting started with Cloud Foundry and contributing back to Cloud Foundry will be easier than ever. I can’t wait to see what this unlocks!” 

– Dieu Cao, Product Lead for Tanzu Application Service, Cloud Foundry Foundation PMC Council Chairperson


Just a month after KubeCF’s official incubation, the community announced a new project: Cloud Foundry for Kubernetes, A.K.A. cf-for-k8s, another take at creating a Kubernetes-native Cloud Foundry distribution. What’s most important about this initiative is the focus that it has put on all of the various component projects (UAA, Cloud Controller, Logging and Metrics, etc.) to rethink their parts of the larger architecture using Kubernetes-native approaches and other open source project components (KPack, Istio, Prometheus, Fluentd, etc.).

Looking at cf-for-k8s as a distribution, you see the same developer experience emerging with a very different underlying architecture from the traditional Cloud Foundry. This new architecture’s focus on rethinking components enables a super quick installation: less than 10 minutes on a Kubernetes cluster. 

Why Two Approaches?

It’s logical to wonder why two projects exist in the community that serve as “distributions” of Cloud Foundry. There are two key reasons today, which will eventually become one reason. 

The first reason, which is more short term, is that each initiative started with a different focus. KubeCF was started to bridge the gap between the Cloud Foundry project’s use of BOSH releases as their primary release packaging mechanism to Kubernetes deployments. Cf-for-k8s started with the goal of enabling the Cloud Foundry community’s projects themselves to efficiently rebuild their components of the architecture to be more natively “Kube-friendly.” I say this reason is “short term” because it will eventually fade away as the projects converge on the goal of enabling both the Cloud Foundry contributors and users. 

As work progresses within the community, the redesign of each architectural component will typically be initially introduced through the cf-for-k8s project and later will be incorporated into KubeCF. As this work completes, the “bits” that are being distributed will end up being the same. 

The second longer-term reason is the difference between each project’s approach to packaging and installation: KubeCF uses helm and cf-for-k8s uses kapp and ytt.

These two projects are working together, accepting the difference in packaging but driving adoption of Cloud Foundry within Kubernetes environments together.

“This next chapter for Cloud Foundry will be a shift forward in focusing on evolving the technology to a Kubernetes-based platform and supporting the diverse set of contributors who will make that outcome possible.”  

– Paul Fazzone, SVP Tanzu R&D, VMware

Paketo Buildpacks

In late April, we announced the launch of Paketo Buildpacks, built by the same team that has been building and maintaining Cloud Foundry Buildpacks for years. Paketo represents a bit of a “rebirth” of our buildpack efforts. Paketo buildpacks align with the CNCF’s Cloud Native Buildpack specification, meaning Paketo can be adopted by the broader cloud native open source community, including Kubernetes users. We in the Cloud Foundry community are all familiar with the immense value provided by buildpacks, and I’m proud that we have extended that value to the Kubernetes ecosystem (and beyond).

“To combine the powerful Cloud Foundry developer experience with growing adoption of Kubernetes is the logical next step in this journey. It is great to see the Cloud Foundry community’s commitment to bring this together and its continued investment in innovation of the platform.” 

– Stephan Massalt, VP Innovation Lab, Swisscom

2020 Platform Certification

Each year, the Foundation certifies proprietary versions of Cloud Foundry offered by key vendors in the ecosystem. We do this for purposes of standardization, as certification guarantees that each certified platform uses the same core Cloud Foundry software, ensuring consistency, reliability and portability. In 2020, the updated platform certification specification now includes the option for the architecture to bring Cloud Foundry to Kubernetes users. This means that all certified platforms use either the previous standard Diego, the more recently developed Kubernetes-based Eirini, or both, as the internal product architecture for the container orchestration layer in certified Cloud Foundry platforms. This is yet another example of how the Cloud Foundry ecosystem is bridging the gap between users.

“The members and this community have strongly come together once again to embrace architecture changes and improvements based on the broader open source ecosystem, while keeping the strengths of the Cloud Foundry experience. We’re very excited to see this happening and the focus and passion the Cloud Foundry Foundation puts on supporting the community.” 

– Thomas di Giacomo, President of Engineering and Innovation at SUSE

Google’s Platinum Commitment

Between project rollouts and platform certification, we were thrilled when Google, a stalwart Gold member, made the decision to upgrade their membership to Platinum. Given Google’s outsized role in the birth and rise of Kubernetes, their commitment to the Cloud Foundry Foundation is an unmistakable show of solidarity with the Cloud Foundry community. 

As the Cloud Foundry ecosystem grows in size and continues to incorporate Kubernetes-based projects, we recognize that our communities are mingling. We couldn’t be happier to see that Google is building a bridge back towards us in the opposite direction.

“We are excited that the Cloud Foundry community is aligned on bringing the Cloud Foundry developer experience to the Kubernetes ecosystem. By exchanging parts of Cloud Foundry-developed assets with counterparts from the Kubernetes community, the Cloud Foundry community can continue focusing on delivering a world-class Platform-as-a-Service experience with the leading container orchestration platform as its underlay. We are looking forward to making Cloud Foundry’s transition happen with the broad set of Cloud Foundry member companies and the Cloud Foundry Foundation.” 

– Michael Wintergerst, SVP & Head of SAP Cloud Platform Core, SAP SE

Connecting the Dots

In just six weeks as Executive Director, I’ve witnessed a wave of energy and a renewed commitment to a shared direction from the Cloud Foundry community start to produce significant results. I can’t say I’m surprised. I’ve been in this community for more than five years now and I’m surrounded by folks who are ceaseless in their ambition to create better, simpler solutions and connect the dots from Cloud Foundry out into the wide cloud native universe.


Chip Childers Profile Image

Chip Childers, AUTHOR