 OK. We're going to talk about using Cloud Native Buildpacks to manage your container images at scale. And when I say scale, I'm talking about how companies like Google, and Heroku, and VMware manage tens of millions of images using Buildpacks. I'm Joe Kuttner, and I just flew into Paris three hours ago. So I am less awake than you are. I'm one of the founders of the Cloud Native Buildpacks project, and with me is Terence Lee. If I didn't say I work at Salesforce, Terence also works at Salesforce for Heroku. So what are Buildpacks? Buildpacks, very simply, are tools that transform your source code into container images without using a Docker file. What you get is a Docker image that contains layers that map logically to your image components. And it's well-structured because the Buildpacks are shareable, right? So once someone has written a Buildpack, you can take advantage of all the things that they've put into it without having to handcraft or artisanally copy-paste your Docker file to get just what you wanted. So the Buildpacks themselves are actually modular units that encapsulate all the concerns associated with a particular technology, like Java, or Go, or Maven. And then these Buildpacks are composed together and executed by a Buildpack platform. And we'll talk about how to run one of those in a second. So you can use Docker file with Buildpacks as an extension, but it's not required. And in fact, most Buildpack users don't use Docker file at all. So why use Buildpacks? Well, I can answer this by asking you a question. How many of you have made a seemingly trivial change to your Docker file and then realize that, oh, oh, you've busted every one of your cached layers and you have to rebuild from scratch? And wait minutes are maybe longer. Cool. Now do that 10 million times. It's not really efficient. And that efficiency at scale is really where Buildpacks came from. Platforms that are managing that large of a set of container images need a mechanism that isn't so rigid the way that Docker file is. So even if you're not managing tens of millions of images, let's say you have 500 images, 500 Java images, or something like that, everything's coming along fine, you're building with Docker file, you make commits, and it rebuilds. And then along comes a CVE, and every one of those images is now vulnerable, and you have to patch it and update it. Well, to do that with Docker file means, especially if it's something changed to the operating system, means rebuilding every one of those images, even if you didn't need to recompile the Java code or do anything else in the higher level layers. Buildpacks get around this sort of restrictive, linear layer caching mechanism that Docker has by introducing more advanced caching mechanisms. They can cache parts of your applications like its dependencies and not bust that cache unless absolutely necessary. And the Buildpacks themselves know when to do that. More importantly, though, is a mechanism that we call rebase. And this allows you to update the operating system or even other parts of your image without doing a rebuild at all. You're literally manipulating a JSON file. This process takes the top layers of a container image and then rebases them onto a new operating system without ever running a build. And this is by virtue of the ABI compatibility that's offered by operating system vendors like Canonical and Red Hat. So when you get that vulnerability in the base image, you can take your Java layers, your JDK, your application, your dependencies, and essentially lift and shift them onto the new operating system. Cool. So now, how to run Buildpacks. Thanks, Joe. So getting started with Buildpacks is actually pretty simple. As part of the upstream project, we maintain a tool we call PAC. It's a local command line interface that is basically a local build PAC platform, as we like to call it, and interfaces with a local container runtime like Docker or Podman or something like that. We have different ways to install it, but probably the easiest way is to go through brew. So if you add using the brew tap, the build PAC thing, you can brew install PAC, and you just get this local binary. It's built and go. And it's as easy as running PAC build and then the image name. And so we have a set of, Joe didn't touch on builders, but there's a set of basically OCI images that have a base image and a set of build PACs. And we have a few suggested build PACs maintained by some vendors like Broadcom and Heroku and Google that you can use to just get off the ground running and get started with a simple PAC build. So you can take an app built in almost any kind of language you can think of that is pretty common and then build it and kind of get this up and running. And once you have that, you can do a Docker run with that. You can push it to registry. It is just an OCI image like Joe was talking about at the end of the day. And that's all we had for content, but we're here all week. So we have, we're in the project building like all the other projects. Come find us. We'd be happy to chat and talk more about build PACs and how we can help solve any of your image building and scaling problems. Tomorrow we have a ContribFest session if you're interested in kind of contributing and getting your hands dirty with PAC and working on the project. So that's like a 90 minute session tomorrow. And then on Thursday we have two other maintainers giving a talk on the stuff we're talking about, but at scale and with kind of real world use cases instead of this kind of high level view. So please come say hi. We'd love to talk to you and learn about your problems. And if you're ready using Build PACs in the wild, also love to talk to you about that too. Thank you all.