Chip Childers: Now that Kubernetes has reached a point where it’s serving the overwhelming majority of use cases, we’re on a mission to bring the developer experience that hundreds of thousands of enterprise developers use to Kubernetes infrastructure. We’ve reached the point where our whole ecosystem is aligned on that mission.

Over the last five years, we’ve done major architectural shifts in the in the platform multiple times. The biggest architectural shift that we did was when the Foundation was started, and the core architecture was, frankly, a bunch of Ruby code, and where Kubernetes is now stepping in there were these things called [Droplet Execution Agents (DEAs)]. Then we transitioned to that Diego scheduler layer [during] a 12-month migration process where all the downstream distros began embracing Diego and commercializing it. We’re probably just at the first step of that transition [for Kubernetes], with the work of a project team from SUSE, which recently donated this thing called KubeCF, the first easy-to-deploy distribution of the Cloud Foundry platform that can just install on top of the Kubernetes cluster, that has a lot of the same operational characteristics that we get with BOSH. It’s going to take time for that to mature. There’s also a lot of work happening in the other component project teams where they’re adapting their own internal architectures to be more Kubernetes-native.

What does Cloud Foundry bring to the table with its developer experience that users can’t get from the numerous cloud-hosted Kubernetes distros and other products that are available?

Childers: First, equating the Cloud Foundry experience to a Kubernetes experience is like equating apples and walnuts. They’re not at all related. Kubernetes is all about being an infrastructure abstraction, but that’s not optimized for developers, and it has a more broadly applicable set of use cases — you can take a legacy app, slap it into a container and run it on Kubernetes; you could craft your own containers that are for a more modern architecture and run that on Kubernetes; and a whole bunch of things in between. The Cloud Foundry experience is focused on optimizing for the developer that’s writing custom software for business or, in many cases, government applications. It’s all about custom code.

We’re going to see continued evolution in the architectures, as things like Prometheus continue to mature — it’s going to get brought in. We have new features with the integration of Istio that don’t look and feel like Istio, because frankly, a lot of these components that we’re bringing into the architecture are built to be incredibly powerful, but not to be consumed by the typical developer.

Pivotal Cloud Foundry had had been the most visible commercial partner, and under VMware it seems to be drifting away towards Kubernetes and Knative. How does that affect Cloud Foundry?

Childers: Pivotal did not drift away at all — Pivotal’s acquisition by VMware is actually an increase in investment. Paul Fazzone, in the VMware Tanzu Group, is stepping up as chairman of our board. And a very core part of VMware Tanzu is the Tanzu Application Service. That’s Cloud Foundry. That acquisition of Pivotal, and then VMware setting its Kubernetes strategy, was one of the key things that helped re-converge our whole community on this shared mission now.

Some people see Knative as the future of PaaS, event-driven computing that people can tinker with under the covers and control. Knative also has Google’s backing. Is that something that affects Cloud Foundry?

Childers: Our community overlaps with all of these other projects — there are people in project leadership positions in our community that are also actively involved in the development of Knative, Istio and Kubernetes. Knative’s not really mature enough yet and you also have to use things like Tekton, so there are a few things to think about. But maybe it makes sense that at some point, Knative becomes another thing that we bring in, that lets our community continue to move further and further up the stack.

At Cloud Foundry Summit last year, people asked why the Cloud Foundry Foundation doesn’t join forces with the Cloud Native Computing Foundation (CNCF)? Why are there two separate open source foundations?

Childers: The CNCF’s goal is to be a neutral place where competitive components live that can be put together into Cloud Native architectures. We think of CNCF as one of the fertile grounds that we can use to help support project development, but it’s part of a broader pool. The focus of our technical community is to curate from that broader open source ecosystem and integrate hundreds of other open source projects into an application developer platform. There’s a very big difference there.

Cloud Foundry doesn’t have the name recognition of Kubernetes, so it might be easy for people to get confused about where everything plays. Is it a challenge to continue to keep Cloud Foundry visible to potential new users?

Childers: You don’t always have to be doing this thing where events get bigger and everything gets bigger. The technology has reached the point in the maturation cycle where most of the adoption is occurring commercially. We’ve stepped back and said, our job as a foundation is to focus on nurturing the community that builds the software, and let it fit appropriately into the portfolios of commercial companies. It’s a key part of VMware’s Tanzu, and SAP, SUSE and IBM’s go-to-market strategies. I don’t see that as, as a negative at all — it’s actually as a positive because I want the vendors that helped build Cloud Foundry to be competitive with each other in the market, because it’s at that phase where they need to be.