In this conversation, Ram Iyengar, Chief Evangelist at the Cloud Foundry Foundation, discusses Paketo Buildpacks and their role in simplifying containerization in the cloud-native ecosystem, with Kelly Fitzpatrick, senior analyst at RedMonk. Ram explains the evolution of Buildpacks, their advantages over traditional Docker workflows, and their applications in various domains, including MLOps. The discussion also highlights the importance of security and compliance in software development, emphasizing how Buildpacks inherently support these aspects. Finally, Ram provides guidance on how to get started with Paketo Buildpacks and where to find more resources.
This RedMonk conversation is sponsored by the Cloud Foundry Foundation.
Links
Transcript
Kelly Fitzpatrick (00:13)
Hello and welcome to this RedMonk Conversation on Paketo Buildpacks. My name is Kelly Fitzpatrick and with me today is Ram Iyengar, Chief Evangelist at the Cloud Foundry Foundation. Ram, thank you for joining me on the MonkCast.
Ram Iyengar (00:25)
Hey Kelly, it’s my absolute pleasure to be here on this podcast today.
Kelly Fitzpatrick (00:30)
thank you. And to kick things off, can you tell us a bit about who you are and what you do?
Ram Iyengar (00:35)
Sure, like you introduced me, I hold the position of chief evangelist at the Cloud Foundry Foundation. What that means is a lot of free t-shirts and stickers. But what that also means is I get to be at the forefront of marketing and evangelizing the open source Cloud Foundry project and a whole raft of projects that are also open source and associated with the cloud foundry ecosystem in a big way.
Kelly Fitzpatrick (01:04)
Well, thank you for that introduction. And Ram, you have spoken with RedMonk fairly recently. And for any of our listeners who have not yet seen it, I highly recommend the video that you did with my colleague, James Governor, on what is Cloud Native Buildpack, how to build a portable app with Paketo. I just rewatched it, and you do a great demo, by the way. I would rewatch that again just for the demo. But to my mind, there are some points from that conversation.
Ram Iyengar (01:23)
Thanks.
Kelly Fitzpatrick (01:29)
about cloud native buildpacks in general and Piquettos specifically that are worth digging into a little more. And I’d like to start with the fact that I have heard you call buildpacks cloud native’s best kept secret. So for folks who are not already in on that secret, what is the TLDR on buildpacks?
Ram Iyengar (01:41)
So a big part of containerization today is fairly mature. If you think about it, the Docker ecosystem is very active. A lot of the developers and the operators and the DevOps folks are all quite happy and content living in their Dockerized world. And to a large extent, Docker and containers are used synonymously by
a large part of the world. There’s a lot of evolution in the way we’ve been creating containers and buildpacks represents some of that. So it’s a way for software developers and operators to work together in making containers out of source code. But it encapsulates a lot of the container fundamentals. that you don’t have to do.
a lot of discovery on your own. You don’t have to do a lot of, you know, starting off with Docker and finding about multi-stage builds, for example, after a few years of, you know, using bloated containers. So it takes a lot of these lessons from the containers ecosystem and applies them by default to any of your containerization workflows.
Kelly Fitzpatrick (03:01)
And I think anything where you can take a workflow and be like, here’s the, super quick and like production ready way to do it. Like as a developer, will so take that.
Ram Iyengar (03:09)
You know, that’s one of the big wins of using buildpacks. So buildpacks comes both as a spec and as implementations. The buildpack spec is the CNCF buildpacks.io project, which is, you know, in my opinion, the big project in question. And
There’s implementations of these that are production ready and can get you up to speed and in no time, to be honest. they’re, they’re well-defined implementation. So Heroku has a family of buildpacks. Google has a family of buildpacks. There’s Paketo buildpacks, which the cloud foundry foundation owns, which are fully open source and know, production ready. So there’s a lot of ways to choose from and a lot of ways to get started. And this is by no means abstract or anything like that and fully functional implementations are readily available.
Kelly Fitzpatrick (04:01)
And to clarify, because this is a point that you just brought up, that there’s, so there’s like a buildpacks spec and that is, is that buildpacks.io? Is that the site for that? And because looking through that, I’m like, okay, the difference between that and what we find at Paketo buildpacks project at paketo.io. Can you talk a little bit about those different spaces and how people can navigate them?
Ram Iyengar (04:09)
Mm-hmm. absolutely. So to go through a bit of a history lesson, buildpacks are not a new concept. These were not invented inside the CNCF world or in a containers world to begin with. Buildpacks were pioneered by Heroku and buildpacks were also adopted by the Cloud Foundry community, which is popularly known as Pivotal.
back then and then both of these you know distinct communities took to buildpacks in their own way and optimized it for their very specific use cases. Now just like any good technology that has conflicting ways of thinking about it and developing standards that are orthogonal buildpacks also went through that evolution where two communities developed the same technology.
with the same end purpose very differently. So, the way the pivotal community thought about it versus the way the Heroku community thought about it and the way these communities implemented buildpacks except for the name not a lot was common to these two and so there was a fork in the road, but in a post Docker world in a world that started to discover the benefits of cloud native and wanted Kubernetes to be the
least common denominator for applications and things like that. It did not make a lot of sense to approach this in the kind of independent manner these communities are doing. And so they converge together. They created new specifications, new formats, adopted the OCI or the open container initiative as an underlying spec. And then they formed what is now known as the cloud native buildpacks project. So that open source project.
is the specification and the design that these two communities came up with and that is hosted at buildpacks.io. Now, buildpacks.io or the buildpack spec being the specification that it is, is obviously not ready for any kind of usage unless you implement what’s in the spec. One of the first implementations that was
you know, made available and made available open source for everyone is Paketo, which is available at paketo.io. Now Paketo was donated to the cloud foundry foundation many years ago, and it’s been, you know, the foundation has been the vendor neutral home for Paketo. We’re seeing a lot of different companies adopt it. One of the challenges of being open sources. You don’t know who’s adopting them.
But we’ve also seen a lot of other companies like Google, for example, and Heroku come back and make some of their buildpacks open source as well. So the entire Heroku family of buildpacks are now open source. And there’s a whole bunch of Google buildpacks that some of which are open source, some of which you can license. And what I’ve heard from the community is that
Licensing Google buildpacks is a very convenient way for making them available through their platform. Adopting, you know, Paketo buildpacks was a good way for a lot of people to build platforms. HashiCorp Waypoint and DigitalOceanApp platform and so many of these used open source Paketo buildpacks. And that’s the one available at paketo.io.
Kelly Fitzpatrick (07:49)
Yeah, thank you for that history and that kind of clarification of those different spaces and what you can kind of find where. One thing you mentioned was Docker. It’s like in a post-Docker world and, you know, a container world. When folks are looking at, say, know, Docker and all the different technologies there and see buildpacks and trying to get something done, what, when do you use this? When do you do that? And, you know, what would your advice be to people who are considering both of these?
Ram Iyengar (08:16)
I think that’s a very astute observation because it’s one of the biggest challenges that we have right now is people are so used to the old ways and we now introduce this new means towards containerization, which kind of trips people up and says, you know, Hey, this is what I’m used to when I do Docker builds and you how does that translate into a buildpacks thing? And the
The answer is challenging because in some cases you don’t have to do anything. In some cases there’s obviously some primitives and in a lot of cases the Docker way just doesn’t apply to the buildpacks way. So there’s a lot of difficulties there and one of the things that comes up in the very first stages of let’s say
the Node.js and the JavaScript crowd, right? So they have the notion of starting their apps depending on which package manager you use. So for example, there’s an npm start command, there’s a node start command, there’s some yarn based start commands, for example. And they’re all used to specifying this inside a Docker file, which is available in the root of the source repo.
With buildpacks, this necessity is eliminated. What buildpacks is capable of doing is detecting what the package manager is and assigning a start command based on that. So this is something that’s automated with the buildpacks flow. you know, it’s based on this fundamental way of how buildpacks operates. It really doesn’t need a meta file called
the Docker file and things like that. And so it eliminates a lot of toil for engineers where they don’t have to necessarily write a Docker file, maintain it, make sure it’s updated. And you know, this whole security hole where people just willy nilly copy files, know, copy a few lines into their Docker file from stack overflow and you know, just run. So all of that is eliminated again. So buildpacks
by virtue of automating a lot of these start commands and things like that, eliminate the need for a Docker file. it’s one of those things that comes up in every conversation within the first five minutes about, how do I specify the start command? What’s the entry point.sh for? So there’s a few notions about Docker that you have to discard as you step into buildpacks and Educating people about these is probably the biggest challenge we face as a community. So I really appreciate you bringing that up and asking me the question.
Kelly Fitzpatrick (10:52)
I think you’re right. That’s a question that is on a lot of people’s minds, when they’re, especially on like a green field project, something like brand new, or they’re just like, what do we do in 2025? Where do we start? And speaking of those projects, what you talked a bit about people using buildpacks for building platforms in previous conversations that I’ve had with you, you’ve used the term that people are using buildpacks for everything from Java Spring apps to LLMs. Can you talk a little about what you’re seeing people build?
Ram Iyengar (11:22)
So because of the current popularity of MLOps and machine learning platforms, we’re seeing a lot of companies adopt buildpacks for setting up these machine learning platforms which are then consumed by data scientists. So if you look at the number of personas at play here in general, so there’s the data scientist.
whose job it is to work with data, run their algorithms, stuff like that, and generate some, either some training sets or some data that’s clean, and they can then use for further training and things like that. And it’s not in their job description to be wrangling around with like Docker files and setting up these platforms and spinning up these containers or what have you. they come from…
you know, a Python or a more low level world where containers aren’t even a thing. So the cognitive overhead of getting a data scientist to set up the infrastructure and then, you know, go to work is a lot. It’s not something that’s desirable. And so that’s where we’re seeing a lot of value being added by buildpacks where people
And by people, I operators are able to set up data science platforms, which can then be very simply consumed as a platform and be set up very simply using like a single command deploy script as opposed to fairly complex deployments that, you know, Docker based deployments can get and get started on their algorithmic workflows that are downstream.
much quicker. So that’s one area where we’ve seen a lot of popularity for buildpacks. And the other is when you have like general purpose platforms that are required, you don’t build workflows for different applications depending on which language and family they’re using. You can have a very homogenous build experience across different languages and families. And that is thanks to
what buildpacks enables for these teams. The big example I often like to quote here is, Vercel and Netlify and all of these JavaScript platforms really made life easy for the hipsters. So, you know, if you’re on the JavaScript and TypeScript and whatever else these folks are using, they have a very distinct developer experience in terms of being able to
make a JavaScript application be available live in a very small number of steps. And the big promise that buildpacks helps deliver on is you can make that experience available irrespective of which language or family you’re using. Now, imagine the same kind of experience for Ruby and Java and PHP and all of these, you know, Python even then. because buildpacks are essentially maintained
and updated for every single language family and are capable of giving this very uniform and homogeneous experience. It’s very desirable for any platform operators or ops folks to pick up on buildpacks and provide that as the build experience for the teams.
Kelly Fitzpatrick (14:37)
I think I want to propose a potential tagline for buildpacks as bringing that hipster-like experience to all developers and also data scientists.
Ram Iyengar (14:46)
Absolutely.
Kelly Fitzpatrick (14:47)
And kind of, and so looking at the different personas that, you know, build paths can serve in different ways. You talked about operators and one thing that you talked about a little bit earlier that I’m going to come back to is security and compliance. Because this is something that, you know, folks have to care about as well. And this is also something from your conversation with James where when I re-listened to that, I was like, I need to talk to Ram about this. So in general, what are your thoughts in terms of…
Ram Iyengar (15:07)
Mm-hmm.
Kelly Fitzpatrick (15:12)
how Buildpack can help with security and compliance in general and supply chain security especially. I think we’re going to have to talk about SBOMS perhaps.
Ram Iyengar (15:18)
Mm-hmm. yeah, absolutely. Much like every other segment of this episode, I have a story to narrate here. I was playing around. So one of the sort of experiments I was doing a few years ago was to try and do SBOMs with Docker based builds.
Kelly Fitzpatrick (15:28)
Your stories are great, by the way, so bring it.
Ram Iyengar (15:42)
and it was not easy, it was not straightforward. There was a lot of like build kit and Mobi customization that I had to get into in order to actually be able to generate SBOMs, let alone like functional SBOMs that we can actually use. And this was around the start of the time when like maybe about 18 to 24 months ago when things were actually starting to pick up in the
software supply chain security space and SBOMs were starting to become a thing and because of this, you know, largely excruciatingly painful experience. lot of the developers I spoke to were not doing it either. They said, you know, it’s, you know, a lot of extra work. We don’t want to do it. then along come these buildpacks and you know, they offer the same path to containerization as Docker and they generate SBOMs by default and
that really blew my mind because here’s a feature that takes a lot of effort to realize and here’s a workflow that’s basically getting this, you know, to me for free. this, at that point, I was really sold on buildpacks as a technology because, forget about the things with multi-stage builds and things like that, which
people might evolve into eventually. Security is, again, in my very opinionated world, the part that everybody loves to hate. it’s often discarded to the very end of the application development life cycle when you want to deploy things.
no matter how much we’ve marketed it as, shift left and software supply chain security and the Log4js and the CrowdStrikes of the world have not created that big of a dent in developer culture to actually care about, hey, let me try and scan things as soon as I build them. Let me make sure that I don’t ship with CVEs in my images. Let me at least be aware of what CVEs I am shipping in my images.
You know, people largely don’t even seem to care what’s in the images. And that’s kind of a mixed bag for me in terms of, how developers should be working. If you look at developers as a community, they’re among the more sophisticated and modern sort of engineers in the world. And it’s kind of sad to see them picking up an attitude.
and you know, the nonchalance with which they approach, you know, security in general. So it was a big revelation to me at that point, how buildpacks were really putting security and compliance at the center of their ethos and how as a project, they’ve, always paid attention to these features since the beginning. So that’s the, that’s the big security story.
vis-a-vis buildpacks. And so as a consequence, what you see in terms of implementations are when you build a container using buildpacks, you have an SBOM that’s inside the container that’s always being shipped with the image. anything that is produced using buildpacks has a corresponding SBOM attached to it. And so people can download them, consume them, anybody who’s
using these SBOMs to make policy decisions, have that available. And I’ve used these features to demo stuff where I essentially pick up a container image and I try to ship it. And then I put in like a policy as a gatekeeper using Kiffin or OPA saying, let’s not ship if we don’t have an SBOM with this container. And so
it becomes very simple to realize those policies when you start building with buildpacks as your first step. So there’s a lot that the buildpacks community has really done in order to put security and compliance at the forefront of the buildpacks experience and I’m really grateful to the community for doing that.
Kelly Fitzpatrick (19:34)
Cool, so let’s say folks who are listening to this are kind of like sold on say, Paketo Buildpacks and they want to check it out, want to get started with it. Where would you suggest they go?
Ram Iyengar (19:44)
So paketo.io is the home for Paketo Buildpacks. Obviously the GitHub repos are the developer’s best friend. And so, I highly recommend, going straight to the GitHub repos, finding the buildpacks that you like. The path to consuming buildpacks is either through the pack CLI or through tools like kpack. So
As a developer or as somebody who’s into the business of containerizing your applications, I would suggest installing pack CLI and that’s obviously available through buildpacks.io or through the buildpacks GitHub repo. So get the pack CLI and just run some pack build against your source.
If you have any problems, there’s a buildpacks channel in the CNCF Slack. There’s an independent Paketo Slack. I know there’s a lot of overlap between the two. And so, you can get anything answered and any of your queries resolved on either of these two channels. yeah, I mean, GitHub is your best friend at this point and pack is probably the tool chain that will enable you to consume buildpacks the best and the quickest way.
Kelly Fitzpatrick (20:55)
We are about out of time, but before we go, how can folks hear more from you? Where are you on socials? Are you doing any speaking? I see that there’s a Cloud Foundry Day happening in October. Where can people find you?
Ram Iyengar (21:08)
Yeah, there is. So there’s two Cloud Foundry days that we host every year. Our first one this year is in North America in May and that’s happening in Palo Alto. There’s a second one that happens in Europe and that’s in October. So, just looking for Cloud Foundry Day will give you that information. And in order to reach me, I’m quite active on Twitter.
as Ram Iyengar, so just first name, last name. And also on a fair bit on LinkedIn, I guess. But you know, there’s the Cloud Foundry and Paketo and the CNCF Slack communities and you can reach me there, Ram Iyengar in most places. So yeah, don’t be a stranger, come say hi. Happy to help answer any questions and get you started on Buildpacks.
Kelly Fitzpatrick (21:54)
Well, many thanks again to you, Ram, for this great conversation. For folks out there, again, my name is Kelly Fitzpatrick with RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. And if you are watching us on YouTube, please like, subscribe, and engage with us in the comments.
No Comments