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.
On the Linux Foundation blog, David A. Wheeler, Director of Open Source Supply Chain Security writes about CII Gold Badges:
“…a CII Best Practices badge, especially a gold badge, shows that an OSS project has implemented a large number of good practices to keep the project sustainable, counter vulnerabilities from entering their software, and address vulnerabilities when found. Projects take many such steps to earn a gold badge, and it’s a good thing to see.”
The Linux Foundation has a new blog post about why training and professional certifications are important for open source communities:
“The open source community works more organically and cyclically, which necessitates that a cadre of expertise is built for it not just to be deployed (as the commercial training and ecosystem have worked historically over the past 40 years) but also as part of its continuing development and for it and all of its participants to thrive.
An open source software community develops software, and it gets deployed by professionals. Those professionals often eventually move on to different organizations and implement the same software. Those organizations will ultimately need more people to support deployments and write applications to extend and customize the software. These organizations also need system administration professionals and cloud providers to support solutions based on these open source software systems.”
Alexander wanted to become a more effective open source contributor in the future, so he applied for and was awarded a Linux Foundation Training (LiFT) Scholarship in the Kernel Guru category.
Learn more at Linux Foundation Training
Donut is an open-source social networking project created by Codeuino, a volunteer-driven, open-source, social networking software development organization that wants to change the way communities and individuals use and create open-source social-environment tools.
Swapnil Bhartiya interviews Jaskirat Singh, Founder, Codeuino on behalf of the Linux Foundation. Here is the transcript of the interview:
Swapnil Bhartiya: Hi, this is Swapnil Bhartiya and today we have with us a special guest from India, Jaskirat Singh, founder of Codeuino, an open-source project or a community, that’s building amazing software for social networking. Jaskirat, first of all, welcome to the show. Now, tell us a bit about the project itself.
Jaskirat Singh: Codeuino is basically a social networking community that takes into the account of only social environment projects, like the Donut project, the Codebadge project, and the Spenceberry project.
Swapnil Bhartiya: So, basically it’s like an open-source community that is creating software targeted at social networking solutions.
Jaskirat Singh: Well, we just build the software side. So we have projects which any other external communities, any other projects, can use in their own way. We just provide a set of projects to make it available for the other external projects, other communities too. And those things can be used in their customization since it’s open-source and it’s free.
Swapnil Bhartiya: Now, you’ve mentioned three projects. One of the projects that I am personally interested in is project Donut. Tell us a bit more about the Donut project.
Jaskirat Singh: Donut is basically an open-source, feature-rich, and highly privacy-friendly social media platform. It is not a replication of Facebook. It’s a platform that has been built for community-oriented collaborations, in a customized way. It’s built on the Node.js framework that helps other communities to set-up their own platform.
This will act as the bridge between their projects and their users of the community. So this is basically a social media platform. And this comes with an expansive set of a library of modules, where you can even customize with some external as we have mentioned. We have an appropriate mechanism inside this Donut platform where you can organize, you can create more features inside the Donut platform itself with one click. So this is something which even helps you to create your own features, functionalities inside the Donut platform.
Swapnil Bhartiya: Now, if you look at history, there have been many efforts to create open-source solutions for social networking. I mean, Mastodon is a very good example, which did not get the kind of traction we expected it to get. So how different is Donut from these open-source efforts?
Jaskirat Singh: The world we currently live in is full of jarring technologies. And with each passing day, new software or gadget is brought into the market which tends to improve our lives in one or the other way. Communication technology has enabled new approaches to the external communities project and end-users in which stakeholders across various sectors are engaged in consensus building, and basically in the implementation process. So basically this Donut project allows the users to have one-on-one interaction with their own community.
So this is basically a platform that would help bridge the gap between the communities, their own workings, their own working ethics, and the targeted users, which gets involved with the communities because for every open-source community or every open-source project the most prioritized thing is their users. And every community, usually within the open-source, basically depends on the contribution they receive from the external users. So I think, this is something which would help engage the external users with their projects and they would be able to organize their own stuff on this particular self-hosted version of their own Donut on their server. So, this is something that will act as two sides of the Facebook network, which is a social media platform.
Swapnil Bhartiya: If I’m not wrong, you’re not building the next Mastodon, you’re not building the next Facebook or Twitter, you’re actually building an open-source social media solution or software that others can leverage to build a social network for their own needs. Is that correct?
Jaskirat Singh: Yes. We are building software.
Swapnil Bhartiya: Who is the target audience of Donut? If I’m not wrong, you seem to be looking at business-to-business or B-to-B space and not at business-to-consumer or B-to-C space. Is that correct?
Jaskirat Singh: Okay. Basically, if I talk about the targeted audience, so targeted audience in the sense, this is available to the communities. Suppose if I talk about a Linux Foundation community, it has got quite a lot of users, right? So, to sustain those users with their own communities, and to keep them updated about the stuff, and engage them with the external stuff like their media or even the projects, events and other things. So this is something that would help engage both the external communities as well as the targeted users for those particular communities.
Swapnil Bhartiya: And you have also been accepted into Google Summer of Code. What has been that experience so far?
Jaskirat Singh: We are involved in many major development programs like Google Summer of Code, Google Code-in, Google Season of Docs. We are currently in the phase of Google Summer of Code 2020. So, I think participation through these programs has enabled us to grow our community of various developers and other activists. And I think being a social networking community it fulfills a social need to interact with various other activists, researchers, designers, and developers across the globe.
Swapnil Bhartiya: I also want to know a bit about how widespread is the community. I do understand that it originated from India, but tell us a bit about where its developers are, is it specific to a region or it’s a global phenomenon?
Jaskirat Singh: Oh. Well, this is something not really restricted to our country. So this is something globally present. So, anyone can join our community.
Swapnil Bhartiya: Now, I want to take a step back. I understand a lot about the project. I want to know the story, why and when you got the idea to create this project? What problem did you see in this market that you wanted to solve with it?
Jaskirat Singh: Oh. Well, I just want you to know, when I started with this project, I was around 14 years old, and the major problem for me was to seek some contribution, like how to basically set up the foundation for this particular project. Because, I actually got to know about the open-source stuff from one of the contest by Google, which is named as Google Code-in. And after that, it really made me research how social media platforms are made. So I was wondering, how about if every community and every project have their own Facebook? So this is something that helped me and motivated me to research these topics. I started brainstorming around why there is a need for social environments, why there is a need for a community bridge between the users, why there’s a need for sustainability within any community or any project.
This motivated and encouraged me to start with this particular project, and with this growing project, we had a chance to integrate other projects like discussion forums with this social media platform and the project, which measures the health of the user. So it’s all about getting all in one place. Even more importantly, this type of project doesn’t exist for now. We would be the first one to do it.
Swapnil Bhartiya: Now, one of the critical pieces of any project especially open-source projects is funding. So how are you funding or sponsoring the project?
Jaskirat Singh: Well, for now, we don’t have enough funding. We don’t receive enough funding for now, but whatever the funding we receive, is basically from the development programs, and anyone like I just had Google Summer of Code, and those are the things, they usually pay, they support some open-source communities who do participate. So this basically, we are even looking forward to having financial support from the communities, some large base communities, and where we could help grow our market, we could have grown our development phase, so this is something. Even now if I talk about, I would really like to thank Linux Foundation, because the Linux Foundation recently is supporting us, and even we got approved for a Linux Foundation’s new CommunityBridge Mentorship program, where Codeuino is participating with the two mentees. So I think this is something we are really excited about.
Swapnil Bhartiya: Right. If you look at open-source, the commercialization of open-source is critical to the health of the project, and its ecosystem. It ensures that the project has some longevity. Do you have any plans to commercialize Donut?
Jaskirat Singh: Now, basically yes, because currently, we have a lot of goals. We are currently in a phase of making this reach to some external markets as well, making it a more viable product at a production level. And we are heavily working on this Donut platform, and other interlinked projects to have security and vulnerabilities related stuff, because if any community use this platform for their own, like for on their self… So the very first priority would be to have that security, right? So security and privacy play the most important part of any community. So this is something we are really trying to build on, and really trying to make it more secure, so that this could be reached to the major production level, and this could be used by many other communities and projects.
Swapnil Bhartiya: Can you talk about what does your roadmap for the year look like?
Jaskirat Singh: Basically, the very first priority for us would be to seek some funding from the communities and from the projects, because funding plays a vital role for us because we have to… Because basically, for any open-source community or project, they usually depend upon the contributions they receive from the external users. So this is something which would help us to enable and get into the markets, and organize some meetups, organize some of the development sprints, online hackathons, where we could introduce the project, and we could have the better improvements inside the platforms we are working on.
I think, adding AI to projects would even enable us to seek some more growth. So this is something we really plan to do this in particular, this year.
Swapnil Bhartiya: That was great. Thank you, Jaskirat Singh, for taking time out and talking to me today. Good luck with your project, and I look forward to talking to you again, once you hit some of those milestones on your roadmap. Thank you.
Jaskirat Singh: Sure. Thank you. Thanks a lot.