 OK. I think I'm going to get started. I am aware that this is the last talk before lunch, but if it helps, I'm doing three talks at this conference, and this is my favourite one that I'm giving before lunch today. So get ready. It's going to go quick. There are a lot of slides, and I'm going to go really, really fast. In my head, if I apologise, then that makes it OK. We'll see what happens. So I want to talk about basically three things. I want to talk about simplicity and abstractions. That's going to count as one thing. I want to talk about PAS versus containers versus serverless. That also counts as one thing. And then I want to talk about what I call containerless development, right? Like a way of actually understanding these ideas together that I'm going to argue is actually the direction that things should go. So basically, though, what it all comes down to is state, right? State is bad, right? That's what this talk is going to be about. And there are various ways of dealing. I love anything with a political joke. There's no more politics in this talk. So state is bad. Most of the problems that we have with distributed systems, most of the times when it becomes difficult, is when we have states. And most of the successful ways we've had for making things easy come down to removing states. Whether it's serverless or map-produce or cloud foundry, the trick is getting rid of states. But there is another way of dealing with it that we should talk about as well, right? It's what I call trying to make states great again, right? And the idea is maybe we can have some tooling that's so good at managing really complex distributed systems that we can still make everything really complex, but make that easy enough that it will be a good idea. I don't actually think that's a good idea, right? I actually think we need to focus on CF push, right? We need to focus on just push code, right? Simplicity, abstractions, things that make it easy for me to just push code to the cloud and have it work. Because I don't want to care about patching and packaging and building and orchestrating and all of those things. I want the platform to take care of that so I can focus on just the things that I care about. And getting rid of states is what lets me do these things. The simpler system is the one where there are the minimum levers, right? The minimum things for me to control makes the simpler system. And that's actually the most operable system. Because actually if I know that every application in my system is pushed the same way, that new versions have rolled out the same way, that when they break I fix them the same way, that's how I can build something that actually scales. The analogy for me is a driverless car, right? The point of a driverless car isn't to make driving easier, right? The point is I don't want to drive, I want to be places. That's what we're trying to build, right? But can't we just build it ourselves? Maybe we can just build the driverless car from parts, right? We'll just create some tools that make it really good to build a driverless car, and then we'll just all build our own specific custom driverless cars, right? Who here uses Java as a programming language? Go as a programming language? JavaScript or Node? Okay, who wants to replace that programming language with a custom programming language that you design just for yourself and your company is going to be perfectly tailored to your needs? All right, we've got three, and I taught three, and I knew one of you would say that. Why don't we do that? Firstly because it's actually... Why don't we do that? Firstly because it's really difficult to design a really good programming language and a really good platform, right? There's actually lots of hurdles in getting it right, but it's actually more than that. It's also that even if you build the perfect custom programming language, it will be a custom programming language. What we want is something that looks like a Macbook, right? We want something where good choices have been made, and when I go to it, it will be the same choices each time, right? If I'm developing for the Mac, it's the same each time in a way that if you build your own computer from scratch, even with brilliant components, right, it won't be a Mac or Windows, like that sort of thing, right? Generic things aren't simple, right? There can sometimes be an elegance to generic things, right? There can be an elegance, but genericness and simplicity are often in conflict, right? Because standardisation makes things simpler. So CF push, it's about I don't want to drive, I want to be places, right? But there's an elephant in the room that we have to talk about, right? Because we've had this conversation about CF push, we've had this conversation about just push code, and people might remember how it goes, right? Containers, and I probably don't mean containers, right? Let's be honest, I mean Docker, right? Docker has popularised this other model of containers and building your own platforms on top of them, right? And it looks really good, right? Docker build, Docker run. This is a really great abstraction. So it looks like this, right? This is how it would be architecturally, right? You see you've got code, you've got this Docker file that converts it into an image which you can put in a registry. Now you've got that image in a registry, you can put it to all sorts of platforms and tell them how to orchestrate it and wire it together and do all that stuff. This is actually a really good way of writing a platform, right? This is a good architecture. I mean, Cloud Foundry looks like this for what it's worth, right? You've got code that has a build pack instead and it converts that into a dropler which scales up and down. I'll be honest, I think the Docker model might be better, right? It's simpler, there's a nice elegance to it. But I don't think it's important because this is what a user sees, right? This is the Cloud Foundry model, right? It's code to cloud, right? In Onzi's words, here's my code, run out on the cloud for me and I don't care how, right? We might well want to iterate how some of those things work in the platform and you can come to my talk at 2.30 to hear about some of those things, right? But that should be hidden from a user. It doesn't matter to a user. Users should just be able to push and have it work. So just push code, right? But what do people say next? Containers, right? And we would say, okay, but can't I just push code, right? And you might remember how that conversation goes next, right? Containers, a bit louder. And we would be like, okay, but can't I just push code? That sounds nice. And then containers but really loud, right? Containers are cool, right? I really would like to just push code. And that's where the conversation was for a second. Does anyone remember what happened next in that ongoing industry conversation, right? Serverless, right? Remember, just push code, right? No servers. It's great. What, but, right? It isn't that what we were. Okay, so serverless. Let's talk about servers, right? Serverless, here's my function. Run it on the cloud. I don't care how. And we can invoke some more functions, right? That's what it looks like basically, right? Invoke a function. Cloud's going to scale it up and down. Can invoke more functions, right? Going to scale those functions up and down. There's quite a lot like PaaS, right? So far so good, right? This is great. There's always a but, right? Because we're at a Cloud Foundry conference and I like Cloud Foundry. Aren't most things apps not functions, right? Most of the things we actually build aren't functions. They might have functions. We might have apps that have functions, but actually aren't most things apps. Can't we do the same trick for most of this stuff? Let's come back to CF push. So wouldn't it be nice if we could say not just here is my code and not just here is my function, but here is my whatever. Run it on the cloud for me. I don't care how. How would that work, right? I don't care how. Here's how, right? So how? Abstractions. It's all about well-chosen abstractions. And abstractions are all about states, right? State is bad. Why is state bad, right? Because as soon as I've got states, it's hard to scale, it's hard to upgrade, it's hard to patch, it's hard to deploy, right? All of those things are because of states. What's the answer? Stateless apps, right? Things that are stateless. What do they look like? I can scale them by replicating them. The hard bits, the persistence of states, happens by services. I can expose my services, they have confidence in their rhyme, and that means I can scale them up and down in response to triggers, right? So I know how to create new instances and when to create new instances in the platform with isolated dependencies, right? It looks a lot like 12-factor, but it's not quite 12-factor. But it's the core idea that's at the heart of 12-factor and serverless and all of these things. It's about abstractions and good abstractions are actually specific, right? They don't try to solve all problems, right? Why is MapReduce a good abstraction? It's because it doesn't solve every data parallel problem, but it gives you a simple surface area where you give me the maps, you give me the reduces, and I will scale your code. I think most of these abstractions that we're talking about in distributed systems look a bit like this. They're a stateless piece of code, they're a way to trigger that code, and they're a way to know when to scale that code and how to scale that code. I'll give you some examples, right? Here are some abstractions that have been quite successful. Apps, functions, MapReduce. Let's be more generic and call functions events and MapReduce batch, right? And let's think about what these mean, right? So apps, apps are stateless, right? That's the whole trick, right? Cloud Foundry can throw away one instance of your app, start up another, it never has to worry about it. That's how we can patch it and roll it and upgrade it. It's bound to a web URL. We know how to trigger it, right? We know how to invoke that piece of code. We know how to scale it up, right? We can scale it by response time or CPU usage. We know how to build for it. So functions, are they very different from this? I'd argue they're not. It's really the same thing. Functions are stateless pieces of code. They're triggered by messages on a queue instead of by routes in a router. And we can auto scale them by queue length, right? And we have a way to build for them. Batch is the same, right? Schedule or time or data, right? But you're going to give me status code. Services. Services are not like the others, right? The things that we bind to our apps, they're not stateless, right? They're not something that we can auto scale. I have to do custom things to make these work. If I want a platform that can run Mongo, it's going to have to do all sorts of stuff to manage that, to roll out a new instance. It's not going to act like all of these other things. And it turns out that's fine, right? And I'll argue why that's fine in a second. So the abstractions really look like this. CF push, right? And I just bind a route, right? Here's the stateless code. Here's how to trigger it. So what would events look like? It's the same thing, right? CF push, but now bind an event instead, right? Bind the way to trigger it. Batch is the same. It can be bind, schedule, bind, whatever. Services are not, right? Services aren't a push. Don't push services. Bind services, because services are the hard bit, but there's not that many of them. And this is the aside that I want to talk about. Pushing services is a lie, right? Every time you see one of these demos, a Docker demo or a Kubernetes demo, you see there's this composite app, and it's got a web app and a Redis and a Mongo in it, right? Don't do that. Who is doing this? Stop, right? Do not push Mongo to the cloud. Don't push Mongo to the cloud, right? Services aren't pushing there for binding. If you've got a Mongo, you want to bind it. One team wants to maintain that. You want to make it highly available. It's a hard problem, right? Do not push Mongo to the cloud, right? If you do push it, it's not going to be the same Mongo that you run locally, right? It's, oh, I've got my composite app, and it works the same locally as remotely. No, right? You don't have a highly available Mongo locally on your machine, right? It's a different Mongo. It must be a different Mongo, right? So don't push Mongo, right? Friends don't let friends, right? So, containerless, right? What are we talking about? There are some good problems that you want to focus on that we should be letting people focus on, right? Your user experience, that's a good problem, right? Your actual functionality, how it works, making it work fast and slick and smooth, that's a good problem. How do you get someone to sign up and start using your app, right? The sign-up flow of your app, that's a good problem. Brosing lots of data, that's a good problem, right? Doing DSP and all sorts of that. That's a brilliant problem, right? Bad problems. Backing up Mongo, right? Quorum, OSs, patching, right? Service discovery, all of these aren't good problems, right? If we are still worrying about operating systems and patching at orchestration and containers in five years, we will have failed, right? That's what I would call the containerless manifesto, right? That's what we should be trying to do. So, containerless, I think past stop meaning just push code and it should be about meaning just push code. Containers revolutionise a lot of things. They're an amazing tool to use to build these systems, but they're not a UX, right? They're not a high-level abstraction. We need to build those high-level abstractions. Serverless proves that we can actually do that in a way that makes sense and it's proved it for functions. We should prove that for apps as well. So maybe we need a new word and I've joked that it should be containerless, right? Like, I never want to see the container. In the same way as serverless, there's servers everywhere. Containerless, there's containers everywhere. They're incredibly important technology and I don't want to be out of a job, right? My other job is running the container team for Cloud Foundry. So I really think containers are great, right? I just don't think there are UX. So we need a new word. I think it's containerless. And the idea is I just want to push apps and code and functions, right, and batch jobs, but not Mongo, right? Never Mongo. And I would actually like a consistent UX for all of it, right? I actually think there's something we can do with Cloud Foundry and that would give us a consistent user experience for all of these things that we want, right? Which is important, right? We want one good end-to-end experience where my log-streaming works the same way. Or if I need a persistent service, I can bind it in the same way, right? Where my workflow is the same, whether I'm pushing an app or whether I'm pushing a function. And we have a demo of this. We did it at Hackday yesterday. We did a demo of this based on this talk. You can CF map events in the same way that is CF map routes. Your app will get scaled up and scaled down and process the messages. I think it's really interesting. You should check it out. So basically have 99 good problems. Don't let containers be one. And with that, it's question time and then lunch time. So you can all feel free to go to lunch and come see me after if you want to discuss anything.