Pack to the Future: Cloud-Native Buildpacks on k8s with Emily Casey

Episode 151 · 26:28 · SRT · archive.org · all Tanzu Talk

Welcome back. This week, we have another interview as part of our Women of SpringOne Platform series. I sat down with Emily Casey, who's an engineer on the Cloud Native Buildpack contributor team, who is a returning SpringOne Platform speaker. In the process, I got to learn a lot more about Buildpacks and how they've evolved, and of course, what this means for the Cloud Native Buildpack and many other things that have changed and come to market in the last year. So, I recommend checking out her talk in the upcoming SpringOne Platform conference. If you're not already attending and you'd like $200 off, you can use the discount code S1P200 underscore D-Drewitz. That's D-D-R-E-W-I-T as in tango, Z as in zebra. With that, enjoy the show. So, I'm here today with Emily Casey, who is presenting again at SpringOne Platform this year. I know you presented last year as well. Is this your second, or how many years have you actually been going to SpringOne? I've gone to SpringOne. The previous two years. This will be my second year presenting at SpringOne. Okay. Yeah. So, having a kind of veteran attendee and presenters will be great. Our last couple questions will be around some advice and tips you can have for the attendees this year. All right. So, Emily, why don't you start us off by just, you know, what's your basic intro on who you are? Like, if you're at one of those big family weddings and you're meeting those, like, people that are sort of your cousin and they're wondering, like, oh, who is this person? Like, how would you introduce yourself? I would say I work as a software engineer at Pivotal Cloud R&D.

I focus on a technology called BuildPacks, which turns a developer's source code into a container image that they can then run in a cloud platform like Kubernetes. If this was actually a family gathering, my cousins would not know what a container is or what Kubernetes is, and then we would continue to work backwards to some sort of shared understanding. But for this audience, I think that might do the trick. Yeah, we'll just assume that you're somehow, like, in a family of remotely software savvy folks. But, yeah, I hear you, you know, depending on how big this wedding is, like, you're going to have a few people in there who may have different associations with the word container. But, okay, so then let's just also kind of get to know you a little bit more. How did you get into tech in the first place? If I'm being honest, I sort of got into tech as an accident. So I studied physics for my undergraduate degree. For a while, I thought I would pursue a career in academic physics. But after a couple of years working in a lab, as much as I loved it, I didn't think that that career path was the right one for me in the long term. So I was sort of looking around for other options. One of the things I was considering was management consulting. I was planning to go to a career fair and talk to some consulting firms. And my mother had given me the wise advice to walk around to other booths and talk to companies I wasn't interested in first to practice my pitch. Ended up talking to a software consultancy. And that is actually how I began even thinking about software as a career, sort of, as an accident. Wow. That's a great story. The whole, like, I was just giving my practice pitch where I thought I wasn't going to care about it.

So what did you hear at this software consultancy that kind of got your attention? So I had learned a little bit of coding, like a little bit of C++, in order to analyze data and physics. But because I didn't have a CS degree, I didn't think that I was a candidate, sort of, for a software engineering job. But talking to these folks, they seemed open to the idea that someone without a traditional background could come in and learn. So they actually brought me into the office with a bunch of other, you know, folks that they met at this career fair. And they were going around asking everyone what position they were applying for. People either saying BA, QA, or dev. And I didn't know what any of those things were. I didn't know that dev was, like, short for developer. But I said dev because most people said dev. And I didn't want to admit that I didn't know what was going on in this conversation. And that's how I ended up applying for a software development job. So what have you kind of learned to love about it in the years that have passed since saying dev? Well, after I learned some more things very quickly in order to get through this long interview process. So I sort of taught myself Java for this interview process and, you know, did a lot of cramming so I could apply for this job. After I got the job offer, I actually took some computer science classes and very quickly realized that it was a very good fit for me, that I loved it. I saw myself, like, procrastinating a paper that was due the next day by doing CS homework that was due two weeks from then just because it was fun. So I think very quickly, once I started doing it, I realized that this is probably what I should have been doing all along. In some ways, I've always loved logic puzzles. And computer science gives you the opportunity to solve logic puzzles, but it also gives you an opportunity to be creative and collaborative and build things that real people will actually use.

So it sort of, like, scratches a lot of different itches. Yeah. Okay, so now let's, like, fast forward a bit. And we're in the D.C. area in September of 2018, which happens to be where SpringOne Platform was last year. And you gave a talk with Steve Levine about build packs and kind of the start of the cloud native build pack discussion. What, a lot's happened on that front in the last 12 months, everything from buildpacks.io and the cloud native build packs joining CNCF and Pivotal's announced a bunch of offerings around it, etc. But what would you say is what you've really learned in the last year? And to what extent has that changed your thinking? I think the project has matured a lot since the last time we were at SpringOne. We have, we always imagined that there were a variety of use cases for this technology. So part of the goal of this project is to take staging, which was a tightly coupled piece of the cloud foundry experience, and extract it in a way that, by defining open standards, becomes something that other platforms can implement and use. And a build pack can run, a build pack that adheres to the standards can run in a variety of situations. And, you know, the OCI images that we're generating as an artifact now, rather than a droplet, it can be deployed into, can fit flexibly into many different deployment scenarios.

So, you know, whether you're running it in Docker, or you're deploying it to Kubernetes, or you are deploying it to PaaS eventually. So we sort of had a vision for why this would be a good idea. I think over the last year, that vision has become a lot more of a reality. We're seeing other customers start to, other companies, not necessarily customers, because this is an open source project, the part that I'm talking about now, start to adopt our technology and use it in their platforms. And it's getting that, like, hard use by, like, real-world users who have a variety of different goals has really forced the tooling to mature. What are, you know, what's an example of something that, you know, as folks are really kicking the tires on it, have exposed that the team has had to go back and work on? I think one example was we recently sort of retooled the idea of what the build plan looks like inside the Buildpack API. So we have, I don't know how familiar you are with, like, the different phases of the Buildpack API, but, like, one of the phases that runs during a build is detection. And during detection, a group of Buildpacks work together to figure out which ones are going to run to actually build the application. And we have a concept of a build plan where Buildpacks could, you know, provide information to that build plan that would help other Buildpacks figure out if they wanted to run and how they wanted to run. And we realized that that format was, like, very open-ended when we first designed the API. It was like a whiteboard. And what happened is that groups of Buildpacks that were sort of designed to work together,

sort of developing their own sort of domain-specific language for doing a negotiation about whether to run together using the build plan. And we recently changed that to create something a little bit stricter where every Buildpack should say what it provides and what it requires. And by creating more structure around that part of detection, now Buildpacks are more likely to be interoperable with each other. So you can use a Cloud Foundry Buildpack with a Heroku Buildpack because the structure provided by the build plan makes it easier to define a contract that will allow them to communicate rather than each set of Buildpacks sort of deciding what that contract means between themselves. That seems really useful. And maybe we should go back a little bit for folks to walk through what those phases are. For example, you mentioned this is all what's going on in the detection phase. But if I recall, there's four phases in the sort of what the Buildpacks are doing. Can you give us a quick sort of high-level intro? What are those phases just so people can orient what this particular problem, where it fits in? Sure, sure. When I talk about phases, I'm talking about the phases of the Cloud Native Buildpack lifecycle, which is the primary component that my team helps to build. And the lifecycle defines two contracts. One of those contracts is a contract with the Buildpacks that it invokes, and the other is a contract with a platform that runs the lifecycle. So the lifecycle is broken up into phases. The main phases are detect. And when the detect phase runs, the lifecycle is figuring out which Buildpacks will execute the build.

The next phase is analyze. And during analyze, the lifecycle will look at the previous version of the image that it built, if there was one, and pull down metadata about layers in the built image. And this is important because it will allow the Buildpacks at build time, if they don't need to recreate a specific layer, for example, because the previous image already has the exact dependency it needs to avoid doing rework. So during build, all of the Buildpacks will write layers, adding dependencies to the final image. They may make changes to the application layer itself as well and provide other types of configuration. Finally, there's the export step, where the lifecycle takes all the information that the Buildpacks generated and turns that into an image as efficiently as possible. So getting back to, like, our layer reuse example that we brought up from Analyze, if a Buildpack runs and sees in the metadata that it doesn't need to rebuild a layer, the exporter will know it can just tell the registry to reuse a layer from the previous image. So we get a lot of efficiencies by breaking up the image we're generating into structured layers with, like, well-known contents. So we can build only exactly as much as we need to on each build to be as fast as possible. Okay. Yeah. So those are the phases that you go from, like, a group of Buildpacks to an image. There are two more phases that are around, like, local caching, called the restorer and the cacher, but those are optional. And what they do is allow you to cache certain types of layers that you will want to use during build close to where you do the build. So you can, without having to re-download from the registry,

sort of get at that information as quickly as possible. Okay. So those can be used for sort of further tuning the performance dial on the whole process. Yeah. Okay. Okay. So that is really helpful and kind of lays out, you know, this whole life cycle. And so now, as we, you know, the example you gave in Detect, just to dive in, because I find this interesting, you know, it detects, you mentioned finding which build packs are needed. And then also this particular kind of work that you've been, one of the examples that you gave was around how you got a lot more prescriptive and specific about, hey, this is, this is what is needed so that different build packs could be in rumble. So this kind of raises this thing that I think might not be really obvious to folks, which is that multiple build packs are in play for a given application. So I think, you know, when first learning about cloud foundry, I remember learning about build packs, but it was like, oh yeah, you need it for this language. And it's like, well, obviously there's only one language. So per application, so that's the build pack. But now I've learned there's like, oh no, there's all these other things that can be built as build packs that are just really part of what needs to go into this application, what needs to be built. So this kind of raises that build pack interoperability and I mean, in some ways, build pack management question, which is what the, this particular challenge was, was getting at. I'm just kind of curious, like what, as this particular model for how software gets built, as that grows, are you seeing the, the complexity in terms of the number of build packs that people have to use?

Is that increasing as a factor of, this is just as the technology gets adopted, you're going to start to see more of this or what, or is this something that's always been kind of well known? That's a really good point you bring up. I feel like, so with the previous version of build packs, let's say you had a Java application, you might run the Java build pack. Using the new cloud native build packs model, the Java build pack has become, I think at this point, 40 or more. Someone would have to ask Ben Hale, individual modular Java build packs. And this is part of the design of the model because it's so modular. It allows people to customize small parts of the build in a really convenient way. So let's say you wanted, you know, everything that came standard in a Java build, but you wanted to replace open JDK, you know, with a Oracle JDK to have a license for something like that. You can replace just that one modular build pack with a different modular build pack without having to like fork the entire monolithic Java build pack that used to exist and then maintain that fork. Okay. So it makes it really easy for people to plug in and replace specific components that they want to tune or add in small build packs that, you know, they want to add an agent that's specific to their organization and they have a build pack for it, stuff like that. And then, obviously, when your one build pack becomes 40 build packs, you don't want people to have to think about 40 build packs because that is not particularly, you know, increases the cognitive overhead.

So another part of what we've been doing over the last year is thinking about build pack distribution and how we can create a build pack that really is an ordered list of other build packs and allow people to think at whatever layer of detail they need to. So it's sort of like progressive complexity. If all you want to do is run Java based on the existing opinions, you just have to think Java build pack. But if you need a different level of detail to, you know, as a super user achieve a more complicated goal, you can then break down to the next level and swap out the individual components. Okay. Okay. This makes a lot more sense with just everything having been sort of going to this more decoupled, modular approach. How then thinking about how to keep things interoperable as all these potential changes are happening makes a lot more sense. So that's hugely interesting and I can see how anyone who's trying to get up to speed on what's happened in the last year is definitely going to want to come to your talk, which brings me to let's talk a little bit about what you're getting into this year focusing on build packs and Kubernetes. Yes, that's a good segue. So I think from this talk is going to be particularly developer centric, I believe this year. So hopefully a lot of the complexity we were just talking about will be somewhat transparent to the end users. So folks who write an app and they want to turn their app into an image and they want to run it in Kubernetes. They don't want to have to think about all the nuances of the build pack API, maybe operators at their organization.

Do you want to make some customizations and then care about that level of detail? But this talk is going to be mostly focused on the developer experience. So we're going to be demoing how to use the pack CLI to generate an image, deploy that image to Kubernetes. How you can very easily then use the pack CLI to rebase that image. Say in the instance that there was a vulnerability in one of your operating system packages and then update your deployment. And then we're going to be demoing KPAC, which is a new platform that was recently open sourced by Pivotal that runs the cloud native build packs life cycle for you in Kubernetes and provides a more Kate's native experience. So it employs a declarative model. We'll show how you can define sort of the configuration for your image. And then as your platform gets build pack updates or base image updates, KPAC will just create new images for you and keep a tag in the registry up to date. What's the one thing that you hope folks take away from your talk this year? I think it would be that Docker is not the same thing as Docker files. So a lot of people love Docker and a lot of people love Kubernetes because of the myriad benefits of containerization. Well, I can run something locally. I can port it to the cloud. It looks exactly the same. All of these great benefits. But I think a lot of people assume that in order to generate a container image within they can run Kubernetes, they have to use a Docker file to build it. We want to present an alternative model that has different benefits that I think are more appealing for particular types of users and use cases.

So sort of break the assumption in people's minds that to get an image, you have to start with a Docker file and present a competing model. This is your second year speaking at Springland Platform. What was your favorite thing about last year that you're looking forward to again this year? Obviously, the talks are going to be different years gone by, but what did you sort of just generally like about the show that you're like, oh, yeah, I'm looking forward to sort of that aspect again? I mean, the talks are obviously great. I always enjoy catching up on the cutting edge of fields that maybe I haven't been paying attention to since the last year I went to SpringOne. But I would have to say my favorite part of SpringOne is the opportunity to talk face-to-face with folks that are using our product and, like, get their feedback in a way that I think sometimes allows for a longer, more interesting discussion that might happen in a GitHub issue. You can really start to empathize with people a bit more and understand how and why they use your product rather than just hearing about the one specific thing that they would like tweaked. That's what I'm really looking forward to. Okay. And so, obviously, folks who have been playing around with or using in any capacity should go to your session, and then they can find you and ask questions. And then, hopefully, that can lead to those broader conversations that give you that sort of well-rounded feedback. Yes, please come find me. We're very friendly, and we want to hear about your use cases, even if you're only just curious about Cloud Native Build Packs. Okay. All right. So, what would you say to someone who is still on the fence about whether or not to come to SpringOne platform and why you think that they should attend, including, like, you know, it's, hey, if you're trying to answer these types of questions

or you're working in this type of role, like, here's why. I think we, in the tech industry, know that tech moves fast, and there are a lot of important questions right now, especially in the Kubernetes track that will be happening at SpringOne, about how people can take this technology that we're all very excited about, but use it in a mature organization in a way that meets security requirements, meets performance requirements. So, I think there's going to be some really interesting conversations happening there. I feel like SpringOne, in general, is a good place to get an overview of current best practices, but also to get a preview of what technologies might shake up the landscape in the future. Mm-hmm. Okay. Yeah, there's, like, kind of a Kubernetes for grown-ups sort of theme going on. That's a theme that's interesting to me. There are, obviously, many other themes that will be explored to SpringOne besides that. Okay. Well, great. Any last parting thoughts for our listeners, where they can find you or follow what you've been working on? Feel free to check out our project at buildpacks.io. We're very available on GitHub and on Slack. Okay. Feel free to reach out. Awesome. All right. Well, thanks, Emily. Look forward to seeing you in Austin, Texas. Thank you very much.

Tanzu Talk · 🍕 Get more pizza.