The Cloud Foundry Foundation recently announced the launch of Paketo build packs for cloud native developers and operators. But what is the difference between the Cloud Foundry package and the build packs announced by CNCF? What does this mean for developers who are already using build packs? What kind of community does Cloud Foundry consider to build Paketo around? What does the roadmap look like?
Swapnil Bhartiya, founder of TFiR.io, spoke with Chip Childers, Executive Director of the Cloud Foundry Foundation, and Kashyap Vedurmudi, Product Manager at VMware, to get answers to these questions and to look closely at Paketo build packs.
Here is a slightly 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're going to talk about the recently announced Paketo build packs. I don't want to get into that old debate about Docker files versus build packs, but there are two things I want to talk about before we talk specifically about Paketo – compliance and security. How does Paketo Buildpacks solve both of these problems?
Kashyap Vidurmudi: So we have a couple of things. We keep sending build packs when there is an upstream vulnerability, a new version of the language family, things like that. Build packs make it much easier, especially for corporate users, to continuously ensure that their apps stay up to date, safe, and compliant. I think this is a huge added value for what build packs offer compared to using Docker files to run your apps and build your apps and production.
Chip Childers: The story of the Cloud Foundry project is that it has been using Buildpack since almost its inception, originally at VMware, before making its way to the Pivotal and then the CFF. So build packs have proven their worth when used with a platform that they can effectively implement a few times, right? In particular, I'm thinking of the OpenSSL Heartbleed vulnerability. I found that this is a good example of how languages and runtimes don't statically embed too many things in their distribution. You can use the build pack process to quickly deploy security patches to these really important underlying libraries.
Chip Childers: As an example, Kashyap said that in the build pack project with Paketo build packs, they were always up to date on all critical vulnerabilities or high vulnerabilities from all languages and frameworks that are merged. We had introduced the OpenSSL update for the entire ecosystem and were able to penetrate all platforms in which the CF build packs were embedded very quickly, as in a few days. And it was really smooth. The only problem at the time was that no JS actually included the OpenSSL library in its own distribution. I think it was about a month after Heartbleed split it up, and then buildpacks could be more effective in supporting some of these underlying libraries.
Swapnil Bhartiya: Thank you for explaining that. If I'm not mistaken, CNCF also announced a build pack project last year. What is the difference between what CNCF is doing there and what you are trying to do?
Kashyap Vidurmudi: It's a great question and probably the biggest question we've been asked this whole start. As part of the CNCF Cloud Native Buildpacks project, they created the underlying specifications and tools required to build a Cloud Native-compatible buildpack. Or the Paketo Buildpacks project is just a series of language family implementations in addition to these Cloud Native Buildpack specifications. So we created implementations when we started them recently. We have Java, node.js, PHP, .NET Core and probably some others that I'm missing, build pack implementations in addition to this specification.
Swapnil Bhartiya: And why do you call it Paketo buildpacks, the specific reasons for this naming?
Kashyap Vidurmudi: That is also a good question. To be completely honest, our entire engineering team went through two different naming exercises to generate different names for build packs. At a team lunch a few months ago, someone came across the Paketo, which is translated into Greek, and … sorry, it translates into Greek. What we really liked was that Kubernetes translated into pilot and Greek, and we liked that when Paketo translated a package into Greek. We can assume that Paketo packs your apps as container images so that all cloud native platforms that resemble Kubernetes can work directly. So the name got stuck in the end.
Swapnil Bhartiya: Talk a little about how Cloud Foundry and VMware are working on this project.
Chip Childers: I probably want to start with the kind of build pack project being a Cloud Foundry Foundation project, right? So that means the same engineers and people are working on the traditional cloud foundry. Buildpacks build the Paketo Buildpacks collection, right? So you get all of your past experience building, maintaining, and updating these new Cloud Native Buildpack-compatible things. One of the project team's goals, which Kashyap could certainly write a little more about, is that the Cloud Foundry Buildpack Collection has traditionally done most of the effort to keep it central.
There were certainly many occasional contributors, but it was something that carried the full load. And we think it's incredibly important that the Cloud Native Buildpacks specification can now be used on many different platforms. Lots of attendees gather because it's an opportunity to bring really high quality build pack code to the platform you're using, whether it's Tecton, Google Cloud, or CF [unintelligible 00:07:06] Cloud Foundry distribution . There will be many end users who should be able to reinforce the feedback loop to the project team. And we are very open to new contributors.
Swapnil Bhartiya: What type of community do you plan to build around these Paketo build packs, and what resources are available to the community to build and use these build packs?
Kashyap Vidurmudi: I think to add a little to what Chip said, the community is very important to us in this whole launch of Paketo Buildpacks. I think we are ideally looking for a mixture of providers who will help us with the Cloud Foundry Foundation in the same way as in the past, as well as individual contributors. And what's super exciting to see is that we only started a few days ago and are already seeing a lot of people turning to Paketo buildpacks who are interested in contributing. We see that people may be interested in helping us develop a Python, Paketo build pack, which is really cool to see. To answer the second part of your question about a marketplace or an ecosystem, I think it would be super cool to have something like this in the future. In the short term, we have this concept of builder images, where a builder is effectively a set of build packs, Paketo build packs that are packaged there. Therefore, we send our builders into a GCR registry that users can use our build packs with.
Swapnil Bhartiya: Are there certain build packs that will be available or do you focus on them first?
Kashyap Vidurmudi: Yes. When we started recently, Java, node.js, .NET Core, PHP and Nginx Paketo build packs are officially available. We're just getting started with Ruby Paketo buildpacks and are trying to publish an official project-wide roadmap in the future to show what's next.
Chip Childers: I think this is another really good opportunity for people to get involved. As you said, there was organic interest in adding Python as a build pack. There is a very long tail of different languages and frameworks that are used in the corporate context. And so Paketo Buildpacks went out of the door with a series of build packs that basically solved most use cases for corporate development, right? Python is used a lot, but it's a little less than Java, isn't it? And so the tail begins to fall a little. However, there are many options in these languages and frameworks that the Paketo Buildpacks project team did not create themselves. However, the same patterns can be used for languages that may be used less.
As the community grows, not just the Cloud Native Buildpacks specification, right, because anyone can build a buildpack based on that specification. But I think the practices of the Paketo Buildpacks project are good for distributing the quality of a build pack, right? If you search for and get up build packs, you will find thousands of them, even if you just look at the earlier version of how build packs work, right? But some of them are stale, others are, they have work. And I think the most important thing, as exactly what build packs are offered today, is that the Paketo build packs project is an opportunity for people to come together in the discipline to build high quality build packs and then maintain them over time.
Kashyap Vidurmudi: Yes exactly. That is a really good point. And I think that over the next few weeks to months we will really focus on improving a lot of our documentation to make things like that possible. We just have a few tutorials to help users build a package pack style, as well as a lot of tools and the like. My ultimate goal and just sure Chip agrees to it. I would like to see how a user with very little build pack experience can come in and, for example, easily build a Rust Cloud Native build pack or something similar and easily and support that. And that is the ultimate goal where we want to go so that the community build packs are easy can create.
Swapnil Bhartiya: So what happens to the existing build packs that people are already using?
Kashyap Vidurmudi: We will continue to provide support for CF workloads for Cloud Foundry build packs in the foreseeable future. So on each of our Paketo build packs we created a concept for a compatibility layer with which we can deliver a Cloud Foundry-compatible cloud native build pack. This means that your CF workflows can continue to work with Paketo build packs.
Chip Childers: I think one of the things you have to understand and it gets a little confusing here, doesn't it? Buildpacks as a concept have a fairly long history. So it started with Heroku. CF emulated Heroku, right? It was the open source alternative to Heroku and implemented build packs to get this support. And for a while they were largely compatible, weren't they? You could take a Heroku build pack and use it in a cloud foundry context or do the opposite. And that worked for a while. The two platforms, right, cloud foundry and open source community. And then Heroku as a product or platform as a service, it's all proprietary, they started to differ, didn't they? Compatibility within the ecosystem began to deteriorate.
When the CNCF Cloud Native Buildpacks project started, this was actually one of the most important moments for me on the platform as a service area in a few years. Because it was a convergence of workflows and experiences with different end users that made a lot of sense for everyone. However, that means the CMB specification is a new way to build packs, right? Therefore, all of this historical work is important to the CF community building, but it is really important to understand that a Cloud Native build pack compatible build pack is different from a traditional Heroku or Cloud Foundry build pack from an older version. They are implemented differently. And so it's a new generation of them. And this is where a new ecosystem comes in because there are several platforms that do not support their use.
Swapnil Bhartiya: Kashyap, you mentioned that there will be a lot of resource documentation that will be released soon. What resources are currently available that users can either read or view to help them become more aware of the project and how they can participate in the project?
Kashyap Vidurmudi: Yes. At the moment there are some tutorials to learn how to start with Paketo build packs and how to build your own Paketo build packs. I think the best way to get started is to join us at 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 for taking the time to talk to us about this project today. Good luck with this project and thanks again.