 Hi, this is your host Sunny Bhartya. Today we have with us Yuvikao CF open source product lead at VMware and Paul Warren, product manager of CF4Kates at VMware. What was the drive behind CF4Kates? Yeah. Well, the drive behind CF4Kates is really about bringing Cloud Foundry as a developer experience to Kubernetes. But kind of doing that thoughtfully, looking at how can we take advantage of other projects in the ecosystem and that are up and coming or are proven already and how can we adopt that and make that experience more native. So really bringing the Cloud Foundry developer experience, but also integrating with many of the newer projects as well. And 1.0, I think is a huge milestone for us. Perfect. Since Paul, you are the product manager of CF4Kates. Talk about some of the, especially the 1.0 release, some of the key highlights, key features of this release. I think the problem we're trying to solve here is to bring the Cloud Foundry developer experience to Kubernetes. Kubernetes is great. It makes what was once very difficult now very possible. In essence, it's an entire ecosystem of tools, networking, load balancing, object storage, compute and memory allocation and scheduling. All working in concert to make that difficult possible. But operating and using this set of interconnected tools, particularly in production settings, is hard. And much as we would like it, there is no such thing as a self-tuning, self-healing, self-administering Kubernetes cluster. So Cloud Foundry helps with that, right? By bringing to the developers the famous CF push experience. So no more YAML for them, no more complicated Kubernetes resources like replica sets, services, load balances, DNS. It's easy. It's easy as CF push. And for platform operators, we think that this represents the entire Cloud Foundry community's learnings, knowledge and best practice on how to run a multi-tenants Kubernetes cluster for your teams of developers. Because it's open source and we release frequently, as we learn how to do that better and better, the platform operators gain from that almost immediately. One thing that I want to do, I mean, we have already, this is not even a topic at this point, but I just want to reiterate is that it's never about Cloud Foundry versus Kubernetes. It's about Cloud Foundry and Kubernetes. So how is CF for kids, not only further pushing that, you know, at the same time, how it's also helping, there are a lot of users who have investment in Cloud Foundry already. And some of them are also moving to Kubernetes. At the same time, there are a lot of people who are on Kubernetes, you know, but they can also leverage Cloud Foundry. So can you talk about the kind of bridge that you're trying to build here, if I'm right about calling it a kind of bridge? So you're right. It is about Cloud Foundry and Kubernetes. Really, we're trying to, you know, Kubernetes is now ubiquitous in the ecosystem and at a lot of companies out there. It's a lot easier to get access to a cluster, but you still have to wire quite a bit up together to get from your application code to running production environment. And so I think with Cloud Foundry being able to layer on top of that very quickly with a much smaller footprint than ever before, that it's very much a Cloud Foundry and Kubernetes. You can have both very, the developer experience while taking advantage of the ubiquity of the Kubernetes ecosystem clusters available in the cloud on-prem. Everyone's trying to provide that layer. And I think the developer experience is the real gap, you know, people don't want to have to tie together five, six, 10 different tools and have to curate that. Or maybe they do, but that takes quite a lot of expertise to be able to curate all of those things together and make sure they're up to date. And if the new thing comes out, being able to to bring that thing into the ecosystem, and if you're focused on building applications, then you want to just focus on building applications really. And CF really provides the best experience, in my opinion, for taking your application code and getting it to running and not worrying too much about the things in between. And as for folks who are going from who already know and love Cloud Foundry as it is, I think this really provides a path forward into the future for them. As more investments are made into Kubernetes and the surrounding ecosystem, this is allowing them a path to still maintain the Cloud Foundry developer experience. Those things will just get easier to get at as compared to VMs and the technologies and integrations will continue to mature. So I think this is really a bet into the future as well for them to be able to still have the Cloud Foundry experience on top of this new infrastructure. Paul, do you want to add something to that? Yeah, I think from my perspective, what I'd add to that is touching on a point I made earlier, running a multi-tenant Kubernetes cluster is hard. And one of the reasons why that hard is because actually there's a lot of decisions you have to make. So Kubernetes just doesn't come set up for that out of the box. So you need to think about your networking, and you need to think about your logging, and you need to think about your metrics. And so as well as just bringing the developer experience, we're also bringing a set of decisions ready made for you. So we've decided to use certain Istio projects and Envoy from the CNCF community. We've decided to use FluentD. We've decided to use Prometheus. And we set those up for you and they're up and running. So you don't have to worry about it. Can you talk about the release cadence because Kubernetes moves it at its own pace. And as you plan to keep supporting the new releases, talk about it. And also, since it may be the same question about your roadmap as well. Yeah, so we're typically looking to release on a fairly frequent cadence, somewhere between two every two weeks to a month. So fairly frequent. And some of those we do anticipate will be major releases, but we're working very hard in this release of this distribution of Cloud Foundry to make that upgrade path very, very easy. So we're putting a lot of effort in behind the scenes in our tooling and our delivery pipelines to ensure that that upgrade path is always there. And platform operators really can come with us on the journey. What is the difference between CF for Cates versus other Cloud Foundry distributions? Because it's kind of become not that crowded, but still a space. Yeah, I can take a shot at that. So I guess we need to differentiate in a couple of different directions. So CF for Cates is different from our original open source product called CF deployment. So CF deployment installs the Cloud Foundry onto a set of VMs. Whereas as we've been discussing here, CF for Cates installs the platform onto Kubernetes. And it also schedules the applications that the developer pushes onto that same cluster. So that's the first distinction to make. The second distinction to make is also within the foundation, there is a separate product called Kube CF. And that also installs Cloud Foundry on a Kubernetes cluster, but it goes about it in a fundamentally different way. So their architecture is essentially to take CF deployment that usually runs on VMs and to make it run on Kubernetes. So you're really getting the components that are originally architected to run on VMs running on the Kubernetes cluster, but you get a very, the experience is identical. With CF for Cates, we re-architected, we containerized the system components or completely re-architected them. So the whole thing is completely Kubernetes native. And therefore, we feel we'll be able to take better advantage of the facilities that Kubernetes provides us and be able to move quicker moving forwards. But that is a little bit of the expense of some subtle changes in behavior here and there. So we still have the famous CF push and it works, but there will be some subtle changes in perhaps how it, what's the right word, how it reasons about your source code. And so you might have to make some small adaptions here and there, but nothing big to make your app pushable on the new platform. But we do that because we feel that being Kubernetes native is going to serve our users the best moving forwards. Yeah, I'd agree in terms of the tooling, the operator tooling will be much more common. There'll be less layers of indirection because we're using more of the common technologies underneath. And really the projects I hope will converge over time. But in the near term, they're just very different approaches to each other. Can you also talk about what are the resources available there for those who want to try it out? And yes, to add what you were saying, I would like to emphasize that we have really tried very hard with this distribution of Kubernetes to make it really, really easy for you to get up and running. So essentially, there's a batteries included version. And on the website CF-4-Cates.io, there's a getting started guide that will get you from nothing to pushing your own app with the famous CF push experience in under 30 minutes. So there really is no need, no reason not to give it a go. Please give it a try. Please give us your feedback either on Slack, on the Cloud Foundry workspace CF-4-Cates, all of our issues and PRs to the GitHub repo. Awesome. Yui, Paul, thank you so much for taking time out today from your schedule and talk about this release. And I look forward to talk to you again because I'm pretty sure there's a lot of things going on in this project. So once again, thank you.