Cloud Foundry Foundation recently announced the launch of Paketo Buildpacks for cloud native developers and operators. But what’s the difference between Cloud Foundry’s Packet and the Buildpacks announced by CNCF? What does it mean for developers who are already using buildpacks? What kind of community is Cloud Foundry look at building around Paketo? What does the roadmap look like?
To get answers to these questions and deep dive into Paketo Buildpacks, Swapnil Bhartiya, Founder of TFiR.io spoke with Chip Childers, Executive Director, Cloud Foundry Foundation and Kashyap Vedurmudi, Product Manager at VMware.
Here is a lightly edited transcript of the interview:
Swapnil Bhartiya: Today we have two guests, Kashyap Vidurmudi, product manager at VMware, and Chip Childers, executive director of Cloud Foundry. Today we are going to talk about the recently announced Paketo Buildpacks. I don’t want to get into that old debate about Docker files versus Buildpacks, but there are two things that I do want to talk about before we talk about Paketo in specific – compliance and security. How does Paketo Buildpacks solve these two problems?
Kashyap Vidurmudi: So, we have a couple of things. We are constantly shipping Buildpacks just whenever 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 Docker files to run your apps and to build your apps and production.
Chip Childers: The history of the Cloud Foundry project is, it’s been using Buildpack since nearly the beginning of its inception, originally at VMware, right, before it took it to 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, right? 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.
Chip Childers: As an example, Kashyap said that the buildpack project with Paketo Buildpacks, they’ve always been keeping up to date with all their 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 no 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 these underlying libraries.
Swapnil Bhartiya: Thanks for explaining that. If I’m not wrong, last year, CNCF also announced a Buildpack project. What is the difference between what CNCF is doing there versus what you guys are trying to do?
Kashyap Vidurmudi: That’s a great question and probably the biggest question we’ve been getting asked with this whole launch. So the CNCF Cloud Native Buildpacks project, they built the underlying specification and tooling needed to build a Cloud Native compliant Buildpack. Or the Paketo Buildpacks project is just a set of language family implementations on top of these Cloud Native Buildpack specifications. So we build implementations when we launched the other day, we have Java, node.js, PHP, .NET Core, and probably a couple of others that I’m missing, Buildpack implementations on top of that spec.
Swapnil Bhartiya: And why do you call it Paketo Buildpacks, the specific reasons for this naming?
Kashyap Vidurmudi: That’s a great question as well. To be completely honest with you, our whole engineering team went through about two different naming exercises just to generate different names for Buildpacks. At a team lunch, a couple of months ago, someone came up with the Paketo, which translates to Greek and… Sorry, it translates to package in Greek. What we really liked about it was Kubernetes translates to pilot and Greek, and we liked that with Paketo translating a package in Greek. We can come off with the association that Paketo packages your apps as container images that any Cloud Native platforms similar to Kubernetes can work as straight. So the name stuck at the end.
Swapnil Bhartiya: Talk a bit about the collaboration between Cloud Foundry and VMware for this project.
Chip Childers: I want to start probably by saying, the kind of Buildpack project is a Cloud Foundry Foundation project, right? And so what that means is it’s the same engineers and contributors that are working on the traditional Cloud Foundry. Buildpacks are building the Paketo Buildpacks collection, right? So you get all their past experience as a community building and maintaining, and keeping up to date these new Cloud Native Buildpack compliant things. One of the goals of the project team, which I’m sure Kashyap could share a little bit more about as well, is that traditionally the Cloud Foundry Buildpack collection has seen the majority of the effort that was put into maintaining it coming from pivotal.
There were certainly a lot of casual contributors, but it was something, that pivotal bore the full burden on. And we think that it’s incredibly important that now that the Cloud Native Buildpacks spec can be used in many different platforms. That a lot of participants 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 the CF [inaudible 00:07:06] distribution of Cloud Foundry. There are going to be a lot of end-users that should be able to amplify the feedback loop back to the project team. And we’re very open to new contributors there.
Swapnil Bhartiya: What kind of community are you planning to build around these Paketo Buildpacks and what will be the resources available for the community to build and consume these Buildpacks?
Kashyap Vidurmudi: I think just to add on a little bit to what Chip said, the community is super important for us with this whole Paketo Buildpacks 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 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 Paketo Buildpacks, and interested in contributing. We’re seeing that maybe people might be interested in helping us develop a Python, Paketo Buildpacks, which is really cool to see. To answer the second part of your question around a marketplace or some 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 with this concept of builder images where a builder is effectively a set of Buildpacks, Paketo Buildpacks that are packaged in there. So we ship our builders onto a GCR registry that users can then use to consume our Buildpacks.
Swapnil Bhartiya: Is there any specific Buildpacks that will be available or you’ll be focusing on to start with?
Kashyap Vidurmudi: Yeah. When we launched the other day, we officially have Java, node.js, .NET Core, PHP, and Nginx Paketo Buildpacks available at the moment. We’re currently just getting started around a Ruby Paketo Buildpacks and looking into publishing some official project-wide roadmap in the future to show what’s coming next.
Chip Childers: 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 Paketo Buildpacks was going out the door with a set of Buildpacks that basically solved 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 Paketo Buildpacks project team hasn’t created on their own. But those same patterns can be followed for languages that might be maybe less used.
As the community grows around, not just the Cloud Native Buildpacks spec, right, because anyone can build a Buildpack to that spec. But I think the practices of the Paketo Buildpacks project lend themselves to quality distribution of a Buildpack, right? If you search and get up for Buildpacks, even if you’re just looking at the past version of the way Buildpacks work, you find thousands of them, right? But some of them are stale, some of them are, they have work. And I think the more important than exactly which Buildpacks are offered today is that the Paketo Buildpacks project is an opportunity for people to come together around the discipline of building quality Buildpacks and then maintaining them over time.
Kashyap Vidurmudi: Yeah, exactly. That’s a really good point. And I think that 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 of tutorials right now just to help users create a Paketo style Buildpack and lots of tools and things like that out there. So my end goal and just sure Chip agrees with this, which is, 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 the end goal of where we want to go in terms of enabling the community to build Buildpacks easily.
Swapnil Bhartiya: So what happens to the existing Buildpacks that people are already using?
Kashyap Vidurmudi: 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 a compatibility layer on top of every one of our Paketo Buildpacks, which allow us to ship a Cloud Foundry compatible Cloud Native Buildpack. And that enables your CF workflows to continue to work with Paketo Buildpacks.
Chip Childers: 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. CF was emulating Heroku, right? It was 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, right, Cloud Foundry and opensource community. And then Heroku as a product or a 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 CNCF 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 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 CMB 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 traditional Heroku or Cloud Foundry, older version Buildpack. They’re implemented differently. And so it’s a new generation of them. And that’s where a new ecosystem because there are multiple platforms that don’t support their use, is really going to kick in here.
Swapnil Bhartiya: Kashyap, you mentioned there’ll be a lot of resources documentation that would be coming up. What are the resources that are available at this moment that people can either read or go to that to get more aware of the project at the same time, how they can get involved with the project?
Kashyap Vidurmudi: Yeah. So right now we have a couple of tutorials out there just around how to get started with Paketo Buildpacks as well as how to go ahead and create your own Paketo Buildpacks. 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.paketo, P-A-K-E-T-O.io, or visit our website and go through the content. The website is P-A-K-E-T-O.io.
Swapnil Bhartiya: Chip and Kashyap, thank you so much for taking time out of your schedule and talking to us today about this project. Good luck with that project and thank you once again.
