 So just before you bring the next guest up, I just want to take a moment to invite anyone here that isn't today already communicating with each other in some of the venues that we have for open source collaboration. You could join our mailing list. The key thing here is that if you have any interest in commenting on proposals, feature proposals, especially if you're an end user, join the mailing list, because that's where the major feature proposals show up. They truly want your feedback. They want you to think about it in the context of your organization. So I invite you to join the list. But I'd also say Slack. There's a lot of informal conversation happening. There are user groups that are sort of forming in the Slack team. It's easy to get to, easy to join. It's kind of fun. And to date, we've had over 1.3 million fun interactions. So come join us there if you're not already. All right, next up, we've got another doctor. We're going to invite Dr. Jules up. Let's give him a round of applause. Thanks for coming. So while you plug in, I'm going to ramble slightly. So one of the things that the Cloud Foundry community does constantly is think about ways that we can sort of innovate around the edges, use the platform in new ways. In Santa Clara, we had a hackathon. That was our last event. We had won this event, too. News on that coming. So Jules was on the team that won that hackathon in Santa Clara. The least effective one of the team, but the most talkative one. He had the best PowerPoint, and then his team built the product. So he's going to both talk and then show it to us. So why don't I hand this to you, and you prattle about serverless. That's exactly what I'm going to do. So I am going to talk about serverless. I know what you're all thinking, because it's written in really large letters behind me. For ones of you who aren't thinking I need more coffee, Cloud Foundry is a Paz. It's not serverless. Why are you talking about serverless at a Cloud Foundry conference? How many people have heard of this serverless thing? Yeah, a lot. So we've heard about Kubernetes and containers, heard about Paz. There's a missing piece in this, right? It's this serverless thing, this functions thing. So I'd like to talk a bit about what serverless is, why it's different from Cloud Foundry, why it's similar to Cloud Foundry, and then we have a demo that we built, which shows maybe a way that some of these things can come together. We can learn some lessons. So serverless and Paz. And the only way to think about this is to do science. So I'm going to draw a Venn diagram. Chip thinks this slide is ugly. I think it's science. And beauty doesn't matter when it's science. You said don't judge you, but I judge you. Judge Einstein. Every day. What is serverless? Lots of hands went up, but I'll just summarize it. Serverless lets you just push functions to the Cloud. And because they're stateless, small functions, the platform can scale it up and down. It can just bill you for what you used if something blows up, can spin up somewhere else. And it means that you don't have to think about servers and orchestration and things like that because you just push a stateless thing. What is Cloud Foundry? It's a Paz. We probably all know it. You push stateless web apps. We can scale them up and down. When something blows up, we can spin up somewhere else because it's just a stateless web app. We used a service catalog to do all the hard bits, the stateful bits. We pushed that into a service catalog. We used services. And that meant we could do all the nice things for you. You didn't have to think about those hard bits of managing state for your web app. A Venn diagram only works if there are three things. So MapReduce, you may have heard about MapReduce. MapReduce is really big in the data processing community. The idea is you write a series of stateless map jobs and stateless reduced jobs. We run the map jobs on all of your data on large numbers of machines. And then run the reduced jobs on the result of that to combine it all together. Again, because it's stateless, you don't need to know how to write a massive data parallel processing pipeline. You just supply some stateless map functions and stateless reduced functions, and the platform can do all the hard stuff. What do these all have in common? State is bad. State is bad, and we need to get rid of state. And if you just make the state someone else's problem, it doesn't have to be the developer's problem. So if state is bad, how can you say that's an ugly slide when it has that? And I don't know. There's no accounting for taste. So serverless is stateless functions, which means you don't have to worry about servers. But I think it's actually a few other things. It's not just serverless, right? It's also actually containerless. I just push code, and I don't have to worry about packaging that up. I can if I like. You can push a container if you like. But most of the time, you just push the code, and it's just going to work. It's actually schedulerless. I don't have to care about orchestrating that because I pushed a stateless function. So it's just going to scale it up and down and run it wherever it needs to run it. And I don't have to think about orchestrating that. It's just going to work. How many more fake words do you have? Five. OK, just check it. Numberless fake words, and it's disasterless, right? Like, if something blows up, you don't have to worry about residing. It's just going to work. It's great. Serverless. But what's interesting is that's also pass, right? All of those things are what we're doing with pass and what we've always been doing with pass and what the point of pass was. You just push code. You do the CF push. Here's my code, run it on the cloud for me, right? And we're going to worry about scheduling it and packaging it and recovering from failures and all those things. So why is serverless different then? Well, serverless is a few other words I made up earlier. It's also app-plus, right? Because serverless says, don't push this whole app. Just push these individual functions, right? Push all these little individual functions and we'll make an app out of those somehow, somewhere, right? And it is another thing. It's estimation-less. You don't have to worry about capacity planning. You don't have to worry about capacity planning because it's just going to scale up and down. It's going to auto-scale it to zero and it will bill you per second. So those two things are interesting. A way to write just your individual functions and a way to bill you per second for those functions because we can scale them to zero and up. So the demo we built says, OK, actually PaaS is what you want for a lot of the things you want from serverless. But how can we add just the additional bits that you need to do this serverless idea but give people a path from where they are today? They've got an application. It's a monolithic application or it's microservices. They want to be able to just push it to the platform but then maybe extract some functions and have just those functions scale up and down and not worry about it. So over time, they can get something that's more and more app-less, if you like. But you can start by just pushing your whole app and then move to this slowly with all the same stuff. And the way it works today, we've got this CF push. Just push my code. We have CF map routes. Here's when you should run my code when someone hits this URL. And CF bind service, here's how you should deal with all the hard bits, all the stateful bits. How does serverless work? Well, we still do CF push. Here's my code. We still do bind service. You've got this whole service catalog for all the stateful bits, so you're not locked in to one way of doing these stateful services. And then we add one new thing to the platform, which is CF map events. So instead of saying run this code when this URL gets hit, we're going to say run this code when this event happens. And then the platform is going to autoscale up and down based on just the number of messages in that queue as the first pass. So we'll be able to autoscale based on how many of those events are happening, how many instances we need to have. So that was too much talking. You need to now show people code. I would like to say, I would like to echo the fact that anything that goes wrong is chip fault. It is entirely not fault. Because you thought it would be funny to live on the edge and do a hack day project live. Absolutely. I mean, this is robust production level coding. We've already done the hardest bit, which is to get the new MacBook to plug in to the AV with the right dongle. So we're killing it here. So I've got a hack day function. This is my function. And a function that I've written in Go. But it's just a function, right? Just funk, handle, do this stuff. Simple enough. It does time.sleep to simulate being interesting. And it prints that it receives an event. Wow. It's going to print key value when it receives an event. I know. That's a great indication. We've done a little manifest. The manifest just says, here's how to push it. Here's the instances. And we all know how to push that. I push it. Let's hope this works. Yes. Internet. So now it's converting that into a container. It's doing the packaging stuff for me. It's, yeah, binary build pack. Good. It's working. So now what you do in Cloud Foundry, what you'd normally do now is you'd say bind map root. Here's how I should invoke you. And then if a root came in, it would execute your server. We're not going to do that. We told it in the manifest not to do a root. So we're going to say, instead, map event my function is now map that event. So now our messaging layer, I'll give it away. It's an in-memory map. You'd probably use something different for real. But our messaging layer now knows that that event should trigger this app. What's interesting is, if I ask CF what apps are running, I see currently, we've just got the controller running. And then my function has zero instances. It starts at zero because there's no messages on the queue. So if I can grab the logs of that event. So that's that event that the function prints whenever it gets triggered. And I'm going to create an event using the SpaceSafe technology of curl. I created an event. And what we should see is we see that one instance just spun up, right? That instance, and boom, we have our event, right? Do it again, just in case anyone blinks and missed it. We're at zero instances. Create, instance spins up, and we've got it, right? Now, you could cache that so that that instance keeps running and processes more and more events. Or we could say, let's go crazy. And let's create like a few events. So what if I run, what if I do 10 messages? 10 messages just happened. I'm going to run them all. And what I'm going to see is, actually, now we've got more messages. We're up to nine instances that all gets printed. They all chunk through them, and we're done. And we're back down to zero instances. Let's go super crazy. The power of computers. We're going to run a ton of them. And we're going to see that the instance count's going to spin up. We're going to get to about 20-ish instances. That's a steady state for the speed of events going in for it to process it as fast as it can in a steady state. I'm eventually going to stop causing load on this. And we'll see it just processes the remaining messages, takes it down to zero. And I'm not paying anymore, right? So I had the whole power of the Cloud Foundry Platform. I could have used the service catalog to do all the hard services stuff. I used all the same scheduling, state the stuff. And all I had to do was map events instead of map URL to get functions. So what did the team have to do to? So this actually has, this is all available online. You can find the URL. We'll tweet it out, I guess, because I didn't write it down. But it is a very simple piece of code to do this. Almost all of this is just what the platform already does today. We built a little CLI tool for map events, which tells, instead of telling a shared router in the go router that it needs to ping a web app, it instead says a shared message router. Here, this thing has happened. Please send a message to the right app. And the message to the right app is just a little library in the app that connects up to this shared message queue and says, tell me any messages that are destined for me. And that's all we needed to do. Super neat. That's a great example of a cool hackathon project. Thank you so much. And it works. And it works. And it works. And it works. So thank you, Jules.