Relicans host, Aaron Bassett talks to Developer Advocate at Cloud Foundry Foundation, Ram Iyengar, about Buildpacks, which transform your application source code into images that can run on any cloud.

The Paketo project provides production-ready buildpacks for the most popular languages and frameworks.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Aaron Bassett: Hello, everyone. Welcome to another episode of the Polyglot Podcast. On this episode, I'm joined by Ram. Ram is a Developer Advocate with Cloud Foundry, an open-source Multi-cloud application Platform-as-a-Service. Ram is a big fan of Buildpacks. And judging by your Twitter, Ram, you're also a fan of Liverpool Football Club. So hello and welcome to the show, Ram.

Ram Iyengar: Thanks, Aaron. Thanks for having me. Hello, everyone.

Aaron: Thanks for being on. I don't know which one to get started with here. Should we start with Buildpacks, or should we start with Liverpool Football Club? Like, what is your bigger passion? [laughter]

Ram: Well, I think more Buildpacks and less football.

Aaron: More Buildpacks. [laughs]

Ram: Then I'll feel guilty of not exercising in the past two years or something.

Aaron: We all have COVID to thank for that. So we all have that excuse built-in now. I'm glad you picked Buildpacks because I know so little about soccer [laughs], so that really helps there for me. You were going to embarrass me with my lack of knowledge of what is supposedly my nation's forte. So let's move straight into Buildpacks, then. So do you want to give our audiences a little synopsis on what Buildpacks are?

Ram: Sure. Buildpacks is a tool that is meant to ease the developer experience for those wanting to go through the build and generate a binary process. So Buildpack came into existence with Heroku. So if folks can recall the Git push Heroku master magic, it's Buildpacks that were sort of doing all of the heavy lifting underneath that. It made it possible for folks to deploy in one command.

Buildpacks, like I mentioned, have been around for like ten years now. And they've really had an impact, according to me, in like two distinct waves one is with Heroku and Heroku-like technology. And the other is the present wave, where we're seeing a lot of adoption at Google Cloud with DigitalOcean App Platform.

Aaron: So Buildpacks are not just something you can use on Heroku. You can use them on different platforms now.

Ram: Absolutely. Absolutely everybody that aims to offer a PaaS offering is supporting Buildpacks these days.

Aaron: Oh, wow.

Ram: So it's starting to come up everywhere, and every infrastructure provider has a PaaS flavor of their own infrastructure underneath, and they're putting Buildpacks bang in the middle of their entire strategy. And it's fantastic to see that.

Aaron: Okay. Are they platform agnostic? Like, if I refer to Buildpack I'm deploying to Heroku, could I then take that Buildpack and deploy it to a different service like to Google Cloud hosting or to Azure? Is it a set standard across the board, or is it I'm going to have to fiddle with them for each service?

Ram: Yeah. I'm glad you asked that question because, like I mentioned, there are like two peaks to the Buildpacks adoption sort of curve. In the first version or first avatar of Buildpacks, they weren't very agile in terms of the platform, the end platform that they would deploy to. So Heroku started off with this. I think they open-sourced a lot of the internals. And then Cloud Foundry, which was Pivotal back in the day, had their own version of Buildpacks with their own version of the life cycle and everything. And so, it was very distinct in terms of what the target platform was for the Buildpacks to go out and make a deployment. Between the first and the second sort of peaks, Docker, or rather the popularity of containers, really took off. So Docker happened. I am just using Docker and containers very interchangeably, so; please forgive me for that.

Aaron: [laughs] Yeah.

Ram: So after Docker happened, nobody was deploying binaries that were specific to languages anymore. Everybody was just deploying containers. And so the whole Buildpack strategy, which sort of diverged between the two main platforms of the day, which is Heroku and Cloud Foundry, then converged.

And so now we're seeing OCI-compatible images as the exported artifact from a Buildpack build process. So that makes it very convenient to deploy it on any container runtime, which is essentially what is embedded inside any platform. So today's Buildpacks are fully capable of deploying platform agnostically. So it doesn't matter what infrastructure you're using or which one of these providers you're using. Your build process can remain homogenous, which brings a lot of convenience if you think about it. So there's no "I built it this way on my local, our production builds go this way. I used a bunch of scripts here, make install over there something else.” So none of those conversations need to ever take place and have people grabbing at their hair. [laughs]

Aaron: But what excuse are developers going to come up with now if we can't use "It works on my machine." What are we going to use instead? [laughs]

Ram: They're definitely going to have to come up with something else.

Aaron: So you've touched on something there that I did want to ask you about. It sounds then that the Buildpacks they're not a replacement for containers. They would run in the container themselves. Have I picked that up correctly or?

Ram: So they're definitely not a replacement for containers. If you want to think of it in terms of something replacing something, Buildpacks replace Docker files, and that's where it ends. The starting point for Buildpacks is your application source code. The endpoint of all the build process is a container image. And what Buildpacks allow developers to do is fully transform this middle experience where you don't have to go and find Docker files, or you don't have to write up your own multi-stage Docker files and things like that.

Buildpacks go in a lifecycle, which I'll just talk about in a bit, I guess. They'll go through their life cycle, the first part of which is the detect phase. And so this detect phase is fully capable of creating a build manifest. All of it subsumes this process of creating a Docker file, maintaining it, communicating it to the rest of the team, and making sure that bills are uniform and things like that. So it's very self-contained, and the abstraction is quite powerful. So that's what it replaces. So in terms of thinking about an X replaces Y, it replaces Docker files. It's not a replacement for containers. It is another way to create containers; that’s it.

Aaron: Sure. I know there's the buildpacks.io which I'm assuming is like the...would that be like the main entry point for Buildpacks, and if you wanted to learn more about them? Would that be right?

Ram: That's right. So buildpacks.io is a Cloud Native Computing Foundation-owned project. And they provide the specification for what a cloud-native Buildpack should be. And one of the most popular implementations of the buildpacks.io specification is Paketo. So if you look for paketo.io, it's an open-source implementation of the Buildpack specification. That's owned by the Cloud Foundry Foundation. And so that's really what got me started into making use of Buildpacks and learning more about them.

Aaron: And for anybody listening, Paketo is P-A-K-E-T-O.io. We'll try and make sure the link to that is in the show description as well. So the Buildpack is like a specification, and then Paketo is an implementation of that specification. Am I picking this up right?

Ram: Yep. That's a perfect summation of what it is.

Aaron: Great. I take it there's already a bunch of open-source pre-created Buildpacks that people could go and use. Would that be fair to say?

Ram: Yep. That's right. So the most common implementations are Paketo implementations, Heroku implementations, and a bunch of Google Cloud implementations in that order for buildpacks.io. All of these, as far as I've seen, are open source and available for folks to just get started with or customize here and there if needed.

Aaron: So on buildpacks.io, there is a registry where you can view a lot of these pre-created Buildpacks. I'm looking at the Paketo ones. There are like 91 Buildpacks. So yeah, for most of the main languages that people could want to work with, I can see a lot of Java, and a lot of Ruby, and some Python, and some PHP. And yeah, there are a lot of pre-configured ones that I'm assuming that people would use as a starting point for creating their customized Buildpack.

Ram: So the Buildpacks registry is a slightly more recent thing from the Buildpacks Community. So they've actually collected all of the different Buildpacks that are available. And as you can see, Paketo and Heroku sort of lead the way. But there are a lot of other folks who are coming in and contributing their own Buildpacks and things like that, which is fantastic. So just to shout out here to the Buildpack Community for all that they've done so far. And I think they're always on the lookout for more contributors and more people who can come and generally start adopting and using Buildpacks and providing feedback.

Aaron: I have to admit that I did take a look there for a Django Buildpack, and there wasn't one.

Ram: [laughs]

Aaron: So I'm the Vice President of the Django Foundation.

Ram: That's good.

Aaron: So I'm a little bit biased. I'm always looking for Django everywhere I go. [laughs] But I did see there is a Python one. So I'm assuming then, as a Django fan, that I would be able to go in and modify, say, the Python stack Buildpack to then create a Django-specific one. Is that normally what people would do?

Ram: Yeah, I think that's a fantastic starting point. My guess is the Python Buildpack should accommodate the Django one itself. Because I remember deploying an app just like a test app some time ago, and I was able to deploy it.

Aaron: [laughs]

Ram: So, I think the Python Buildpack is made use of to deploy Django apps. But like I said, there's obviously definitely some scope for expanding what the Buildpacks can do right now. And if there are probably Django-specific quirks that, you know, 15 Django ... make use of. There's definitely scope for including stuff like that for the Buildpack itself. So always looking for contributions and suggestions on how to improve the coverage that Buildpacks can provide.

Aaron: Great. And how did you get started with the whole Buildpacks? You mentioned that you came in via Paketo. Is that correct?

Ram: Yeah, that's right. So I am a developer advocate at the Cloud Foundry Foundation. And Cloud Foundry has been a user of the Buildpacks architecture for about ten years now. More recently, Cloud Foundry pivoted to this approach, where they started doing the Cloud Foundry developer experience on Kubernetes.

So just to sort of go tangential here for a bit, Cloud Foundry defines developer experience that mimics the Heroku one, so like we had Git push Heroku master or something like that. Cloud Foundry makes use of cf push. And as long as you provide the path to the source code, the Cf push command itself is aware about what language your source code is in and what needs to be the build process. And the output was a binary that was deployed to a virtual machine back in the day. So the popularity of that was quite huge, so a lot of enterprise-grade users as well as a lot of medium teams, a lot of small teams. So Cloud Foundry has a pretty big user base as a PaaS. And the same experience was translated to a Kubernetes cluster. And this was about a little over a year ago. They made the first announcement. So the project is CF For K8 so which is again the same sort of convenient developer-friendly past experience. But only now it will export a container image instead of a binary, and it will deploy to a Kubernetes cluster instead of a bunch of VMs.

So the Buildpacks obviously also needed to change, and the buildpacks.io or the cloud-native Buildpacks approach was a perfect complement to what Cloud Foundry actually needed. So the implementation started to be known as Paketo. And Paketo, like I mentioned, is owned by the Cloud Foundry Foundation. It's open-source as well. There's a bunch of different contributors, chiefly from VMware. And they implement all of the cloud-native specific things for the Buildpack experience overall. So because Paketo is also owned by the Cloud Foundry Foundation, and so is Cloud Foundry, and I'm part of the foundation, it's my job to also evangelize Paketo as much as possible. So that was my first introduction to Buildpacks. And obviously, I've had to go back and learn a lot of the historic stuff and other things. That's where I first came across it.

Aaron: Yeah, I do remember Buildpacks from way back in the day on Heroku and having to specify the right Buildpacks. Because I know Heroku would have…I don't know, my knowledge here might be outdated now, but I know it would try and detect what your application was built in based on certain things. Like if it saw a package.json, it would assume it was a Node application. If it saw a requirements.txt, it would assume it was a Python application. And then, it would try to automatically include the correct Buildpack for that. Or you could specify your own Buildpack, I think, in a procfile. Does that sound about right? I'm going way back on my knowledge here. [laughs]

Ram: I think a lot of those pieces of the statement are correct. Like I promised before, I think it's time to break down the Buildpack life cycle.

Aaron: Sure. Yeah. That is useful.

Ram: Essentially, the Buildpacks lifecycle consists of four very distinct phases. So there's the detect phase where you pointed out the Buildpack will actually go in and detect the language or the framework that is used. And internally, it will create what is known as a Build Plan in the next phase. So in that phase, it'll basically choose all of the different actual build pieces that it needs to create that final image. For example, do you need Node.js? Do you need some other sort of JavaScript things to be built? Sometimes you'll make use of an NPM, sometimes a Yarn, sometimes whatever other hipster stuff that comes out.

Aaron: So it sounds like Buildpacks aren't targeted to a particular language or framework. Like a Buildpack could be kind of almost agnostic then. It uses discovery stage to figure out what components it requires.

Ram: That's precisely what it is. So what I like to think of is it's a very sane default. You more or less cannot go wrong if you choose the right Buildpack, I guess. [chuckles] But as long as you're building a JavaScript app, you make use of the Node.js Buildpacks, and you should be fine. That's really what I like about it. And then internally, each of these different life cycle phases that I'm describing are a bunch of Go programs. And so, if you wanted a specific approach or if you wanted to tailor the Buildpack approach, obviously, it's available to customize fully. There are no restrictions pretty much as long as you adhere to these different lifecycle stages, and you give the Buildpack the different pieces it needs to put the image together.

Aaron: And a Buildpack is always written in Go.

Ram: So formerly, they were written in Ruby. The Heroku backs were all written in Ruby. The CF Buildpacks had a heavy Java flavor that got added. But then the present Paketo Buildpacks are a bunch of Go programs. And I think the Heroku ones that are open source are Go as well. And we're seeing a heavy shift to go from the former Rust and the Ruby and the other things that they were written in.

Aaron: Okay. So you're not stuck just using Go there. You can use different languages for Buildpacks. But Go is the defacto new standard.

Ram: At the moment, that seems to be the one. [laughs]

Aaron: But for me as a Python developer, can I write them in Python, or is it going to be like, no, you're going to have to use Ruby or Go?

Ram: I haven't seen folks use anything other than these two. And I haven't tried it either, so I'm really guilty of [laughs] not knowing the exact answer to your question. But like I said, as long as you're able to adhere to these phases and you throw the right events and stuff, I don't see why not.

Aaron: So the first phrase is the detect, and that's going to decide what components we need. What's the next phase, then?

Ram: The next one is what is called the analyze phase. So in the analyze phase, the Buildpack will create what is known as a Build Plan. It will know, exactly like I mentioned, what pieces to use for building this application. And then, it will go ahead and start to kick the build process off. So detect it, create the Build Plan, and then kick off the actual build.

So the third part is the build phase itself, and that's where the source code is actually turned into an artifact that is packaged as a container. And then finally, the container is actually exported. So that's the image that gets run on the infrastructure. So that's the final image that's made use of, so to say.

Aaron: Sure. So I'm assuming that you could have this all as part of your deployment process like your CI/CD kind of pipeline, have this all included in there.

Ram: Yeah, that's right. So, whatever sort of workflow that folks have in order to build and deploy to a remote staging instance, Buildpacks are a part of that pipeline itself. And one of the other cool things about Buildpacks, obviously, is they have a very strong caching mechanism. All the images that are created are layered. Much like Docker images, they are layers, and the Buildpack build process will first look for any layers that it can reuse. So it will reuse as many of the different layers that it can. And so obviously, subsequent build processes are much faster, but it's also got this ability to rebase. So what happens with rebasing is you essentially only pick layers that have like a delta from the original image. And this is even when updating like images on production.

So one of the differences or deviations from the Docker strategy that Buildpacks can provide is the ability to replace layers inside a container registry from where the deployments will happen. So overall, the ability to update an app image goes from, let's say, if you have like 1,000 containers that are running, you don't have to replace every single container but just pick and choose the layers that have to be updated.

And this rebasing strategy is very effective at reducing the amount of time it takes to make an update. And this was particularly highlighted a few years ago when the Heartbleed SSL vulnerability was caught. And so a lot of folks who were using Buildpacks were able to roll out the error and mitigate this sort of problem in a matter of minutes and hours as opposed to days and weeks where it took to update every single container, replace them, and then restart them and stuff like that. So I think that was like a very turnkey moment for the whole Buildpacks Community. They demonstrated the ability to change something very fast thanks to their particularly powerful caching and rebasing mechanism.

So those are really four distinct phases with a bunch of different things in the middle. So a detect phase, an analyze phase, a build phase, and an export phase with a bunch of rebasing and caching between like a minor lifecycle phase.

Aaron: So what would you see like the kind of development process being with Buildpacks in it? Would you expect developers to also use the Buildpacks locally during development, or are they really only for production or?

Ram: No. Everywhere, Aaron. So one of the big benefits that I see of making use of Buildpacks like I was saying before, is the homogeneity, one build process irrespective of where you're staging the app. It can be local; it can be some testing queue. It can be like a pre-production qualification server. It can be, I don’t know, something to show for your BA teams. It can be production. All of them are treated the exact same way. So that introduces so much parity, and it leaves so few gaps between different builds and how they look, so to say.

Aaron: I have to admit I'm not very good at having that parity to my development and production at the moment.

Ram: [laughs]

Aaron: And everybody is always telling me I should just be using containers. I don't need to run Postgres locally on my machine, and I could just have it in the container. But I do very well in keeping my Python environments separate. I do use virtual environments there. But yeah, I guess being a developer advocate, you probably come across it yourself as well. We're very often working on a team of one on a project. [laughs] So it's very easy to skip through best practices. So anything that can make it easier for me to have a nice local dev environment, I'm all for it. So as well as the Buildpacks then, tell me a little bit more about your work at Cloud Foundry. So you're not just like a Buildpack advocate. You're an advocate for Cloud Foundry itself. Is that correct?

Ram: That's true.

Aaron: What are your other projects there, or is Buildpacks your focus?

Ram: Yes. So the central project is obviously Cloud Foundry. Just like I mentioned before, Cloud Foundry was very successful at providing a very convenient developer experience over VMs. When VM-based deployments were very difficult, Cloud Foundry came along and solved a very crucial problem for the industry. And we're seeing the same patterns repeat with Kubernetes. Kubernetes deployments are obviously not the easiest things to tackle. And it's sort of a history repeat itself kind of thing where the Cloud Foundry community now starts to attempt to solve the deployment problems that developers are having with Kubernetes. So it doesn't matter if you are a small team, doesn't matter if you're a big team. It doesn't matter if you're deploying locally. It doesn't matter if you're deploying to production. Providing that Cloud Foundry interface makes sure that everything is uniform in terms of the way it gets built and the way it gets deployed. So there are that many fewer deltas between different instances.

So Cloud Foundry is the mainstay project at the foundation that I'm responsible for. And I work with a bunch of great folks who help out with different marketing initiatives and other things at the foundation. So the primary work that the foundation does is governance. And we have contributors from pretty much everywhere in the world. And different commercial implementations of Cloud Foundry are available. And so we are the neutral body that sits in between all of the circus that goes on around. [chuckles]

Aaron: Yeah, because the Cloud Foundry Foundation it's a nonprofit, isn't it?

Ram: That is correct.

Aaron: The history of it is quite interesting because it was like Cloud Foundry was VMware, to begin with. And then did it go to...was it Pivotal?

Ram: Yeah. So Cloud Foundry was a VMware project. It was called B29 the day it started. Why it was called that, I have no idea. [laughs]

Aaron: There's something about developers. We are so bad at branding, like so so bad at branding.

Ram: And the Cloud Foundry project itself received a brand called Pivotal, and so it was attached to Pivotal. And it was spun off for a while where it was Pivotal Cloud Foundry. And so they started to slowly open-source a lot of the components. After a few years down that path, it only made sense to have it completely open sourced and stay vendor-neutral. So all of the Pivotal folks at that time, and this is like 2015, 2016, were all absorbed by VMware once again. They became VMware employees except for a handful of folks who took the open-source path. So those folks were spun off as the Cloud Foundry Foundation. And so within the foundation, there was a couple of marketing functions, a couple of engineering functions, a couple of executive functions. And then they had like PRs and analysts who were contractual.

And then, along the way, Cloud Foundry Foundation decided to become part of the Linux Foundation. So this was last year. So in 2020, it was decided that the CFF become part of the Linux Foundation itself and be like one among the several different foundations that are a part of the LF. So the CNCF or the Cloud Native Computing Foundation is also a part of the Linux Foundation so is the CD Foundation. So Cloud Foundry has a home amidst all of this open-source goodness that's coming out of the LF. So that's really sort of a 10-year history of the foundation.

Aaron: [laughs] It's interesting to hear because I'm part of the Django Software Foundation. And everybody, judging by the emails we get, people will assume it's this large body as well. And we're like, no, there's like six of us. We meet once a month. [laughter] And just to see from an actual larger body how it all comes together, but yeah. So you said part of your role then as well is in between this financial or commercial implementation of Cloud Foundry. Does the foundation have its own one then, and is that how it's financed? Or how does that work?

Ram: So the foundation is financed fully by members. So member organizations make contributions. And we have no commercial implementation at all. So the commercial implementations are by companies and organizations that are members of the CFF. At times, they're part of the governing board and other things as well. So right now, we have a Technical Oversight Committee as well who oversee all of the main sorts of things. So to give you an example, organizing all of these different pieces in terms of who's responsible for the Paketo stuff, who's responsible for the CF API stuff, and things like that.

So it's a toss-up between the systems interest group that the Kubernetes projects have versus project groups and project teams that we used to have before. So it's kind of a mix between those two, and they're headed by their TOC. And then, the TOC come from different members who do a lot of the contribution and who are member organizations of the CFF. They report to a board. So they all have different full-time jobs, but part of their responsibility is to be on the CFF TOC.

And then there's the board that is also comprised of people from different member organizations. And they sort of set the non-technical goals, so it's more of non-technical goals, so to say, for the CFF. And the TOC takes care largely of the technical goals and makes sure that we're delivering what we need to deliver in order to stay relevant.

Aaron: [laughs] So do you think having a commercial arm…does that make you more independent, or you're free to really focus on what's best for the open-source project without having to think about what's best commercially? Or is it the opposite? Is having so many member organizations on the board…does that kind of muddy your focus? What do you think the balance is there?

Ram: I think it's very convenient right now in order to focus on open-source Cloud Foundry, like the core itself, not worry about commercial implications, not worry about evangelizing and putting marketing dollars behind a particular implementation. The idea is to make sure that the open-source core Cloud Foundry experience is stable, is reliable, and will work the same no matter which provider you pick up. And so, having a handful of providers gives us a lot of flexibility in terms of pointing to different folks that are strong at other capabilities as well.

So if we, let's say, have a very small to mid-size company that's looking for a simple Kubernetes experience, don't want to deal with the likes of big three-letter acronym-filled company names who I don't want to call out. [laughter] But you see what I mean. So it gives us a lot of power to say, "Hey, why don't you talk to these folks? Hey, why don't you talk to those folks? These guys are really good with Kubernetes implementations. These guys are local to your area. And so you can have a conversation with them and speak to them a little." Also, it gives us a lot of flexibility in terms of being able to wave arms and keep the traffic circulating and going.

Aaron: [laughs]

Ram: However, the flip side is, especially as developer advocates, it's very hard to measure and stay focused on what you're trying to do, even inside a commercial company. And without a commercial product to back, a lot of these things that I'm talking about, it becomes all that harder to navigate the space and point out specifically to saying, "Hey, this is growth that we've achieved, and this is what we've been able to do for the product."

Aaron: Absolutely.

Ram: So those parts are harder with the way we're working right now.

Aaron: Yeah. I've been a developer advocate for a number of years now, and I've been lucky enough to attend some of the developer relations conferences. So normally, when I'm attending conferences, I'm attending it as an attendee or to speak. But there are actually conferences out there for developer advocates about developer relations. And every one of those I've attended, the biggest question every time that everybody wants to talk about and nobody has solved yet is how do you measure developer relations?

Ram: Exactly.

Aaron: And if you don't have any kind of commercial metrics to point out, you don't have your signups or your revenue or whatever else, that's going to add an extra layer of difficulty there. Also, I used to work for a particular database company that does have an open-source community edition but also has their own cloud-managed version that's commercial, and that was very weird because some providers would be our partners but also our competition.

Ram: [laughs]

Aaron: It's an odd juxtaposition there. So that's interesting that everybody is just essentially your partner, then you don't really have a commercial interest.

Ram: Yeah, that's true. It's very convenient to stay true to the core of what the foundation is about and focus on the open-source version as much as possible.

Aaron: Can you give us any sneak peeks as to what's on the roadmap and what's coming up next from Cloud Foundry or Buildpacks?

Ram: In terms of the Buildpacks folks itself, one of the contributors, Joe Kutner, I think had blogged about what the roadmap is. And in terms of the non-technical goals, we want a bunch of case studies and other things from users who are using this in production. In terms of the technical goals, we want to sort of make the API much cleaner, integrate a lot of Kubernetes-native and Kubernetes specific components into the CF experience as much as possible, and just make it more Kube idiomatic, so to say, for the future.

Aaron: So for these case studies, then of people using in production, if anybody out there listening at the moment is using Buildpacks in production and wants to get in touch with you or with the foundation, what's the best way for them to reach out?

Ram: So, the Cloud Foundry social handles on Twitter and LinkedIn are fairly active. I'm always listening. So that's the best path. You can reach out on my personal Twitter as well. I'm sure it's going to be linked somewhere. And I'll probably also leave my email in the link, and folks can just get in touch if they want to chat about anything interesting, especially if it pertains to Buildpacks or PaaS.

Aaron: Or Liverpool FC.

Ram: Sure. [laughter] That's the first priority.

Aaron: As long as they're not Man-United United fans, you're happy to hear from them. [laughs]

Ram: Yeah. I mean, it's very interesting you say that because a colleague of mine is a big Man U fan. And then every meeting had to start with a bit of bashing.

Aaron: [laughs]

Ram: And then, oh, well, it's not like we're going to see a game anytime soon now. Let's get down to work.

Aaron: [laughs] So even I know so little about football, so little about soccer, and I still know about that rivalry. [laughs] Well, unfortunately, we're coming up on time. So I just wanted to give you these last couple of minutes then. So you've mentioned there your Twitter, and that will be in the show notes. We'll try and get your other contact details in there as well. So we've talked about buildpacks.io and also the paketo.io as well.

Interestingly, I only just found out today that Paketo, I think, it's Esperanto for packet or parcel, so that kind of makes sense. So that's why they've called it that. But yeah, we got paketo.io. And then are there any other links or socials or things you want to give a shout out to in this last couple of minutes?

Ram: Not really. If you folks are interested about Cloud Foundry news and other things, then you're more than welcome to follow us on Twitter, and that's where we keep everything posted. And just reach out if there's anything.

Aaron: Great. Okay. We'll make sure all of your socials for Cloud Foundry are in the description as well. So if anybody does want to keep up to date with the latest announcements and releases from there, please do go give their socials a follow. Thank you so much for joining us this episode around. That was really interesting. I feel now that I can go forth and tidy up my local dev environment, [laughs] which should be useful at least, maybe try and get a Django Buildpack in there.

Ram: Sure.

Aaron: It's been a great conversation. Thank you again for joining us. And I look forward to seeing what comes out from Buildpacks next.

Ram: Sure, Aaron. Thank you for having me.

Aaron: And we'll see everybody next time. Bye.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.