 Hi, this is Abil Bhatia, and today we have with us two guests, Kashyap Vethalmudi, product manager at VMware, and Chip Childers, executive director of Cloud Foundry. First of all, welcome to the show. Today, we are going to talk about Packato Buildpacks, which was announced. I don't want to get into that old debates about Dockerfiles versus Buildpacks. We have talked about that for ages. But there are two things that I do want to talk about before we talk about Packato in specific. And that is, I had a long discussion with Derkonda at VMware. And one is compliance, and when it's security, when you look at, you put everything in a container-like image. You don't know the source where it's coming from. If you're a big organization, you may run the risk off. Compliance, you don't know whether the application that you're running there is compliant with you, and also security, because there may be hard links to something you don't know what is running. So how does Buildpacks solve these two problems? So we have a couple of things. We're constantly shipping Buildpacks in just whenever a upstream security vulnerability comes out, a new language family version, things like that. So Buildpacks make it much easier, especially for enterprise users, just to continuously make sure that their apps stay up-to-date and secure and compliant. So this is, I think, a huge value proposition of what Buildpacks offer versus using dog profiles to build your apps in production. The history of the Cloud Foundry project is it's been using Buildpacks since nearly the beginning of its inception, originally at VMware, before it took its journey to Pivotal and then the CFF. So Buildpacks have demonstrated their value when used with a platform that's able to implement them effectively a few times. In particular, I'm thinking about the OpenSSL Heartbleed vulnerability. I found that to be a great example of when languages and runtimes don't embed too many things in their distribution statically, then you're able to use the Buildpack process to roll out security patches to these really important underlying libraries very quickly. As an example, your catch-up said that the Buildpack project is always and willing with Pequedo, they've always been keeping up-to-date with all the critical vulnerabilities or high vulnerabilities from all the languages and frameworks that get pulled together. We had the OpenSSL update rolled out to the whole ecosystem and it managed to percolate through all the platforms that had the CF Buildpacks embedded in them very quickly, like in a matter of days. And it was really smooth. The only hiccup back then was that Node.js actually included the OpenSSL library in its own distribution. So I think it was about a month or so after Heartbleed that they split that out and then Buildpacks could be more effective at helping to support some of its underlying libraries. Thanks for explaining that. And if I'm not wrong, last year, a CNCF also announced a Buildpack project. If I am not wrong, is that correct? I may have the timeline totally wrong. So my question is that why is Pequedo.org now as part of the same company working on this Buildpack. So what is the difference between what CNCF is doing there versus what you guys are trying to do here? That's a great question. And probably like the biggest question we've been getting asked with this whole launch. So the CNCF CloudNative Buildpacks project, they build the underlying like specification and tooling needed to like build a CloudNative compliant Buildpack. Well, the Pequedo project is just a set of language family implementations on top of these CloudNative Buildpack specification. So we build implementations of when we launched the other day, we have Java, Node.js, PHP, .NET Core, and probably a couple others that are missing a Buildpack implementations on top of that spec. And why do you call it Pequedo Buildpack? The specific reasons for this naming? That's a great question as well. To be completely honest with you, our whole engineering team went through about like two different naming exercises just to generate different names for Buildpacks. At a team lunch a couple of months ago, someone came up with Pequedo, which translates to Greek in, sorry, it translates to package in Greek. What we really liked about it was Kubernetes translates to pilot in Greek. And we liked that with Pequedo translating the package in Greek, we can come off with the association that like Pequedo Buildpacks package your apps as container images that like any CloudNative platform similar to Kubernetes can orchestrate. So the name kind of stuck at the end. Talk a bit about the collaboration between CloudFoundry and VMware for this project. The interesting thing is that CloudFoundry is part of Linux Foundation. CNCF is also part of Linux Foundation. VMware does a lot of work in Kubernetes space and through Pevital does a lot of work in. It's kind of, you're talking about a galaxy where everybody is kind of sharing their raw material with each other. So talk about the chemistry between VMware, CloudFoundry, CNCF around this Pequedo Buildpack. I just, I want to start probably by saying, so the Pequedo Buildpack project is a CloudFoundry foundation project, right? And so what that means is it's the same engineers that are and contributors that are working on the traditional CloudFoundry Buildpacks are building the Pequedo collection, right? So you get all their past experience as a community, building and maintaining and keeping up to date. These new, you know, CloudFoundry Buildpack compliant things. You know, one of the goals of the project team, which I'm sure Ketchup could share a little bit more about as well is that, you know, traditionally, the CloudFoundry Buildpack collection has seen the majority of the effort that was put into maintaining it coming from, coming from Pevital. There were certainly a lot of casual contributors, but it was something that kind of Pevital bore the full burden on. And we think that it's incredibly important that now that the CloudNative Buildpack spec can be used in many different platforms that a lot of participants kind of rally around this because it's an opportunity to get really high-quality Buildpack code brought into whichever platform you're using, whether it's Tecton or it's Google Cloud Run or whether it's, you know, the CFRCATES distribution of CloudFoundry, there are going to be a lot of end users that should be able to amplify, you know, the feedback loop, you know, back to the project team and, you know, we're very open to new contributors there. That's an excellent point. And what kind of community are you planning to build around these Pecando Buildpacks? And when I talk about community, you know, there is no single community. There are vendors, there are users, there are a lot of major contributors. Can you talk about that a bit? And also that while CNCF is kind of working on compliance, but where will people get their Buildpack? Can you talk about whether there will be a marketplace or there will be a kind of just the way there was a Docker Hub, a lot of, you know, resources or registries. So it's a two-part. What kind of community are you building around it and what will be the resources available for the community to build and consume these Buildpacks? I think just to add on a little bit to what Chip said, community is like super important for us with this whole Pecando launch. I think what we're looking for ideally is a mix of vendors helping us out similar to what Cloud Foundry Foundation has had in the past as well as like individual contributors. And what's super exciting to see is we just launched a couple of days ago and we're already seeing a bunch of people reaching out and trying out Pecando Buildpacks and interested in contributing. We're seeing that maybe like people might be interested in helping us develop a Python Pecando Buildpack, which is really cool to see. To answer the second part of your question around like a marketplace or some sort of ecosystem, I think in the future that would be super cool to have something like that. In the short term, what we're doing is we have this concept of builder images where like a builder is effectively a set of Buildpacks, Pecando Buildpacks that are packaged in there. So we ship our builders onto a GCR registry that users can then use to consume our Buildpacks. Is there any specific Buildpacks that will be available or you'll be focusing on to start with? Yeah, so when we launched the other day, we have officially have Java, Node.js, .NET Core, PHP and IngenX Pecando Buildpacks available at the moment. We're currently just getting started around a Ruby Pecando Buildpack and looking into publishing some sort of official project-wide roadmap in the future to show what's coming next. I think that's another really good opportunity for people to get involved. As you said, there's been interest organically in helping to add Python as a Buildpack. There's a very long tail of different languages and frameworks that are used in the enterprise context. And so Pecando was going out the door with a set of Buildpacks that basically solve the majority of enterprise development use cases, right? Python is used very heavily, but it's a little bit less than Java, right? And so the tail starts to drop a little bit, but there's a lot of opportunity in those languages and frameworks that the Pecando project team hasn't created on their own. But those same patterns can be followed for languages that might be maybe less or used. And as the community grows around, not just the Cloud Native Buildpacks spec, right? Because anyone could build a Buildpack to that spec. But I think the practices of the Pecando project lend themselves to a kind of a quality distribution of a Buildpack, right? If you search on GitHub for Buildpacks, even if you're just looking at kind of the past version of the way Buildpacks work, you find thousands of them, right? But some of them are stale. Some of them are, you know, they're kind of half work. And I think that more important than, you know, exactly which Buildpacks are offered today is that the Pecando project is an opportunity for people to come together around the discipline of building quality Buildpacks and then maintaining them over time. Yeah, exactly. That's a really good point. And I think that, like, over the next coming weeks to months, we're really focused on improving a lot of our documentation to help enable things like this. We have a couple tutorials right now just to help users create, like, a Pecato-style Buildpack and lots of tools and things like that out there. So my end goal, and I'm sure Chip agrees with this, which is, like, I'd love to see a user just coming in with very little Buildpack experience and be able to build, say, a Rust cloud-native Buildpack or something like that very simply and easily and support that. And that's, like, the end goal of where we want to go in terms of enabling the community to build Buildpacks easily. So what happens to the exit? Because there are, like, a lot of Buildpacks already there. So is there any path where they can just bring it into that? Or what happened to this existing Buildpack that a lot of companies or organizations have deployed already? For Cloud Foundry Buildpacks, we're going to continue providing support for CF workloads into the foreseeable future. So what we did is we built a concept of, like, a compatibility layer on top of every one of our Pecato Buildpacks, which allow us to ship a Cloud Foundry-compatible cloud-native Buildpack. And that enables your CF workloads to continue to work with Pecato Buildpacks. I think one of the things to understand, and this is where it gets a little bit confusing, right? Buildpacks as a concept has a fairly long history. So it started at Heroku. The CF then was emulating Heroku, right? It was like the open source alternative to Heroku. And it implemented Buildpacks in order to have that support. And for a while, they were largely compatible, right? You could take a Heroku Buildpack and you could use that in a Cloud Foundry context, or you could do the reverse. And so that worked for a while. The two platforms, Cloud Foundry and Open Source Community and then Heroku as a product or platform as a service that's all proprietary, they started to diverge, right? So the compatibility within the ecosystem started to break down. When the CNCS Cloud Native Buildpacks project kicked off, to me that was actually one of the most important moments in the platform as a service space in a number of years because it represented a kind of a reconvergence of streams of work and sets of experiences with different end users that made a ton of sense for everyone. But what that means though is that the CNB spec is it's a new way to build Buildpacks, right? So all that historical work for the CF community building that shim is important, but it's really critical to understand that a Cloud Native Buildpack compliant Buildpack is different from a kind of traditional Heroku or Cloud Foundry older version Buildpack. They're implemented differently. So it's like a new generation of them and that's where a new ecosystem because there are multiple platforms that now support their use is really gonna kind of kick in here. So Kashyap, you mentioned there will be a lot of resources and documentation that will be coming up. So what are the resources that are available at this moment that people can either read or go through that to get more kind of aware of the project at the same time, how they can get involved with the project? So right now we have like a couple tutorials out there just around like how to get started with Pocato Buildpacks as well as like how to go ahead and create your own Pocato Buildpack. In terms of getting started and helping out and getting involved, I think the best way to get started right now is to join us on Slack. Our Slack is slack.pocatopaketo.io or visit our website and go through the content. The website is pocatopaketo.io. And Kashyap, thank you so much for taking time out of your schedule and talking to us today about this project. And good luck with that project and thank you once again.