 Okay, so people are trickling in, but first I want to disappoint you. If you just saw me on the main stage, it's still just me. The person I referred to as the illustrious Stephen Levine is illustriously sick in bed. So while this talk that we do usually runs probably about 15 minutes generously, let's see how it goes when I'm doing 50% slides I have not prepared. What that means for you is you get the opportunity to pepper me with all sorts of build pack questions which presumably you will have many of, even if I occasionally respond, I have no idea. Cool, so with that, yeah, multi-build pack support. This is the in-depth conversation about the just-on-the-key-note stage presentation. And I like to start it with explaining what a build pack is, because from my experience, of the questions that you all ask on our Slack channel, none of you have any idea what a build pack does. But you might think we're responsible for literally everything that goes wrong with Cloud Foundry, which is fun. So I'm going to first give you an idea of what we are actually responsible for and everything else, complain to Cappy or Diego or something. So also, this is probably the fifth time you've heard this haiku, sorry about that. But for those of you who are not yet familiar with the on-see haiku, here is my source code, run it on the cloud for me, I do not care how. And I really like that, because it sums up what all of us do on Cloud Foundry, but especially the build packs team, because some of the stuff we're doing for you, you could easily do for yourself, really easily. We're figuring out what language your build pack uses, we're figuring out what your environment variable should be. And we're just making it as seamless as possible, so you don't have to think about it or mess it up. And the three original scripts that we use to do this are bin detect, bin compile, and bin release. So bin detect, really basic. It's a Boolean, is this app a fill-in-the-blank language app? So to give you an idea of how basic it is, Ruby. Is there a gem file? Yes, it is a Ruby app. And then it will exit, yes, this is Ruby app, and continue on to compile without running the other detect scripts. However, if you elect to specify your build pack, the detect script doesn't run, which will speed things up. The bin compile is where all the meat of it is. The bin compile is where we determine what your dependencies are, we retrieve them from the cache. If they're cached, we make things executable, we put them on the path. Actually, that's a whole lot of it, when sometimes when people ask me what my job is and I'm feeling cheeky, I make things executable and I put them on the path. But that sounds depressing, so it's a little more, but it's kind of that. So yeah, compile just sets up your environment, and then bin release is very, very straightforward. Bin release essentially just takes the default start command and provides it to the droplet, and that's it. So anything that you're thinking about is in a build pack, is in compile, or at least until recently was in compile. And the magic of this system is that you could take your app bits, you could take the build pack, and you could stage it into a droplet, and you could take that droplet and you can add it to your root FS, and you can launch an app. The cool part though is let's say you need a new root FS. Let's say that there are patches or upgrades. Let's say that you upgraded the stem cell for your system. You can upgrade the root FS under the droplet, and in fact, we'll never even see downtime on your app. So that's a really nice perk for the build pack system, and it pushes forward something that Cloud Foundry believes in heavily about always trying to have the latest things, always trying to have the most up-to-date secure option, and also not making you think about it because you won't do it yourselves. So yeah, the app abides. It's the closest thing I'm going to be able to do with a joke in this scenario, rather than maybe making fun of Chip again. So multi-build packs. Multi-build packs changed up those particular three scripts. Hey, Yui. Now, instead of compile, we've swapped in supply and finalize. So again, sorry if it's repetitive for those of you who just saw me on the big stage, but we're going to have a good example of a terrible app you should never build. You're going to build an app that includes Ruby and Go and Python. There's like a Python, NLT, key, K, corpora language thing you want. And then you also want to shell out to go to make something be more performant. And then you really still want to write in Ruby because you love Ruby, and it speaks to your poet soul. Please never build an app like this ever. But if you did, if you had those three build packs, you would have the supply from one of the supply build packs run, be it Python or Go. Then you'd have the next one run. And then you'd have the finalize build pack supply script run. And at that point, you'd have all of your dependencies in three different dependency directories. And then the finalize script for the final build pack pulls everything together, makes it accessible in the build. There connects up your lib, connects up your bin, and gets things ready to go to be packaged up into a droplet. Then that droplet is added at the root of s. And it's made into an app. So not that much has changed. Just some splitting out of logic so that you didn't end up reproducing things running them all back to back. This is another way of seeing it. This is a crappier version of the slide that you, again, saw on the main stage, the folks at Cloud Foundry Foundation gussied it up and gave it better shading. But these are the depth stirs adjacent to the app door. You end up just adding depths for Python, depths for Go, and then pulling them all in with a bunch of sim links. And this may seem complicated, especially if you're familiar with the Heroku way of doing it. The Heroku way of doing it is just run them all in order and kind of hope for the best. And honestly, I'm not dissing that. That was how we wanted to do it initially. But we got some pushback from our enterprise users. And we got some pushback from the Java build pack team. And we put some thought into making something that's a little more complicated, to get some great additional benefits out of it. You have fewer edge cases, same use cases. If Stephen were here, he'd be saying, had we just made them all run in order, there would be a combinatorial explosion of possible edge cases. And we have avoided that, because we don't accidentally run things differently. And there's not kind of a, eh, run them in some order and see how it happens. It's very, very important that your final build pack be the core language of the app. And then this also makes it really easy for partners to write extension build packs, which I'm going to get to later. It's my favorite part of it. But as with all those opportunities, where you iterate on something and think that, oh, why are we doing this? I like the original plan. We got some really great stuff out of it in the end. So compatibility. It is 100% compatible in all directions. Old build packs still work by themselves, and will continue to work by themselves. Core build packs remain compatible with old foundations. And I definitely thought that there was a fourth bullet point there. There should have been. And yeah, basically, fourth bullet point, making it up right now. You could use either the Heroku Shim multi-build pack build pack, or the Cloud Foundry Shim multi-build pack build pack. And either way, it'll work on old foundations, on new foundations. You're not going to have a problem. And then we get back into the slides that would have been mine. We should care. So this should be really exciting news for developers of apps that were previously incompatible with the build packs model. And I imagine that might be many of you in this room. We asked in the last presentation, who here is forked to build pack? That is not true. More of you have forked to build pack than that. I know, because I've seen all the forks. There's a really big problem with that, because it means you don't get to benefit from the whole build pack structure. You don't get to benefit from our upgrades. You don't get to benefit from the security patches. And you don't get to benefit from the improvements we have. So just because you need a mixture of other libraries or you need a mixture of other tech, it's a shame that that requires you to fork or to push an image. And now you don't have to. Also, build packs maintainers, the operators who used to have to support the forked build packs, are happy, as well as the build pack maintainers of the system build packs, i.e. me and my team. Right now, we have to spend a lot of time making each build pack work for all of the possible use cases for that language that we can conceivably support. And that includes things like, for instance, Node is in the Ruby build pack. It's also in the .NET Core build pack. These seemed really, these were necessary for the ways that people wanted to use these things. But we had to focus on all of those edge cases, and we couldn't focus on something that I cannot promise we'll do, but like, arrest build pack or something cool like that that people reach out and ask us about. And we have to be like, no, we have a lot of other things we need to do at your PHP libraries. Cloud Foundry partners also really, really benefit from this. So right now, external vendors, like APM vendors, have to make a PR to every build pack they want to have a process running in. So let's say that you are a metrics company or a security company. You're making a PR to every single build pack and dealing with the fact that we can get back to you and say this needs test coverage. And then we get into a whole thing over a course of months and months. So now, instead, as one of these vendors, you can create your vendor supply build pack. And it will work with any of the build packs. And you don't need to do those PRs. And you don't need to worry about integrating it, although please still do test it. Test coverage is good. Additionally, I alluded to this earlier, people who were forking the build packs and having to maintain them. I've heard of companies that have upwards of 12 versions of a single language build pack. We like to remove that problem from your hands. There are other things you could be focusing on. And as far as automation being a benefit of the system, it starts to kind of degrade when you're having to maintain so many of your own versions. So these are some examples. Python and static file and other build packs might benefit from using NPM to compile assets. As I said before, we only currently package NPM with Ruby and .NET Core. Now that's up to you. That's not up to our discretion. We don't have to worry about build pack bloat, and you can decide what you want to use NPM for. Also, proprietary database drivers. This is a big one that we see people forking build packs for, or occasionally using specifically the Python build pack as pre- and post-compile scripts that are used for this. But you have this proprietary database driver. You need it to be included. Now you can just make your own supply build pack that doesn't work on its own. All it does is add this driver, and you don't have to worry about fork build packs. I complained before about adding PHP modules. I don't want to do that anymore. I don't want to do it every time. There's a cool new thing people want. So now you can bring your own PHP modules or other dependencies, and I don't have to think about it. And then additionally, a very specific use case. But there are some Ruby gems that use the JVM. And the people who use those gems have been sad that they have not been able to use them without forking the build pack. So that brings us to, can I try it without upgrading? The answer is, yes, yes, you can. You can try it using the exact same means that we use to develop it. So the way that we developed the multiple build pack paradigm was by creating a build pack called the multi-build pack build pack. And then once that was working, moving all of the chunks of code into the build pack app lifecycle bit by bit. So it's the exact same code. It's just in a different location. And all you have to do is add a multi-build pack YAML that lists which build packs you want to use, and it'll work functionally the same without you waiting for your system, like your platform, to be upgraded. Or for the new version of the CLI, though, I still recommend you upgrade that. It's compatible with current CF versions, has the same code, allowed us to transition, and it lets you try it out right now. That's actually kind of an old bullet point. That's from when we hadn't rolled it out yet. You can try out either right now, but you can definitely try this out right now without upgrading. And then the future. Future is my favorite, favorite part. The future are build pack groups. The idea here is that you can have operator-specified groups of build packs that look like a single build pack to the developer, but are actually running a series of build packs. So it allows operators to guarantee that certain combinations will always be run together, and it provides similar functionality to two different ideas you might have heard floating around depending on how much you're paying attention to the CFN mailing list. Staging policies were a previous proposal to the foundation, and then more recently we were talking up mandatory build packs as a concept. But this is more flexible overall, and facilitates the same outcome. So that outcome is the operators, the businesses, they wanna make sure that you run, let's say, security review tool before you push. They wanna make sure that you don't have any known vulnerabilities in your app code. They also don't want to have, you have a list of things that you have to use when you push. So that will just automatically run. Same things with maybe, let's say there'd be a build pack to check whether all of the licenses on your dependencies are still ones that your company can use. These are all of these little things that developers shouldn't have to care about, and with this it'd just be your bundled version of the Java build pack or of the Python build pack would include all of those out of the gate. And that is the end when I'm the one doing it myself. Thanks. But are there any questions? Because there are usually questions. I'm here. They can't hear you. The question I had was, is it, would it be possible to add like a custom build pack through the CFCLI when I'm doing a deploy of the app itself? Yeah, absolutely. You can still add a custom build pack. You can do it with a URL, which you already could, and it's nice to keep that functionality. It used to be something that was mostly nice for the PMs, but provided that your foundation supports it, you should still be able to provide your own custom build pack that way. So that way you could add more supply ones as part of your CLI and could still rely on the system build pack as... Ah, yeah, exactly, exactly. So you can mix and match that. I mean, we'd prefer you to use the system build packs. We've spent so much time and effort on, but a lot of the opportunities for these modular supply build packs will be very personal to you in your use cases. Anybody else? Sweet. All right, you get out of this way early in that case. Have a good day.