 This is a fun end of day talk. Do not be worried there is no content, just jokes. This talk is called 99 problems, but a container ain't one. Oh, this is how to escape. Legally obliged to how you had to escape my talks. Frankly surprising that more cities don't have that rule. I'm Dr Jules. I work for IBM. It's sort of the first dojoa, depending on, I mean, it's easy to find ways to disqualify Colin Humphreys who is factually the first dojoa. First dojoa after him, and I work on Garden and Autoscaler. You may know that Garden is Cloud Foundry's container engine, so it's a bit weird. I want you not to worry about containers, but then you won't care about my bugs. So this is a story about how we solve good problems and avoid working on stuff that's boring. It's a story about focusing on the stuff that actually is worth focusing on that's fun and makes us go fast and avoiding the stuff at the bottom of the iceberg that's boring and that I wish we'd stop doing. It's in three parts. First we're going to talk about the goal, then we're going to talk about the problem that's stopping us achieving the goal, and then we're going to talk about the solution to the goal, or in the words of the Buddha, suffering exists. This is the nature of suffering. This is the path to end suffering. And if you're wondering why the Buddha was talking about containers, then you haven't been part of the container conversation as long as I have. So suffering exists. What is suffering? What is a good problem? What's the goal here? What are we actually trying to achieve? Here's a picture of a goal. What are we trying to solve? What do we actually want to do with these systems? We want to... I mean, this is standard, but we want to iterate fast. We want to build good stuff, spend time building good stuff. We do want to keep it running. We don't just want to push it and forget it, and we want to do it cheap. This shouldn't be controversial, but it seems to me that it's almost becoming controversial because we seem to keep building systems that don't focus on these four things. Iterating fast, spending most of our time building good stuff, keeping it running, and doing it cheaply. So it didn't cloud solve this. Wasn't this what cloud solved? It was going to let us work on this stuff. Well, in order to answer that, we have to go back in time to 2005, which apparently is a long time ago now. And if you remember what we used to do, actually, at the start of cloud, it was pretty terrible. If you remember when you had a great idea for a project, and you see your provision of server, you installed an OS after spending a lot of time worrying about an OS because that was very important, I actually remember getting the CD out and like putting it in to the server, right, and installing it. It would take an hour and you'd do it for all of the servers in your data centre. We actually used to do that. Install some middleware. For a short time, I was a consultant on WebSphere portal, helping people install portal because you used to need consultants to install middleware for you. That was the thing that you had to do when you were starting a project. Obviously, you would do all that again for your DR environment that would live somewhere else and be turned off. You would install your jar file which I call a ghetto container, containers before they were containers. Oh, my God, we can ship it around. It runs everywhere. You'd figure out clustering, which again you would probably need a consultant like me in order to do. So I was doing well. Obviously then it wouldn't work. Something would blow up and you would realise, as everyone has realised, that your DR didn't work. So you'd start again. But even when you'd done all of that basic stuff, even when you got it running, you still had to keep stuff patched and scale it and monitor it and all this stuff, right? All the stuff that we have to do. So in 2005, we had this brilliant idea called Cloud. It would be played by Spider-Man in the rest of this presentation. I googled Cloud, but I mean, and the Cloud said, you know what? Forget about that provisioning service and forget about that installing OSs. You don't have to do that anymore. Actually, that worked. I can't remember the last time I had to put a CD in on a server and wait. That's pretty great. You don't even really need to install middleware if you do Cloud Right at the moment. That's mostly soft. But we did still have quite a lot of the other stuff that we hadn't quite solved. Fine. But let's just take a moment and say, you know what? That Cloud stuff is pretty good. Why was it good? Why was that Cloud stuff good? Why did it actually work? Why did we all like it? Because it let us iterate faster. We weren't spending time waiting for machines and installing operating systems. We were spending more time actually working on stuff that delivered value. I don't think many people are really worried these days about the lack of flexibility in putting CDs into machines, right? That's quite good. And actually, it was better. It kept running better because we didn't have these different DR environments. If we did, it was much easier to create them and replicate them. And it turns out people like to rent stuff. The different economic model was a big part of it. Yay. So, the obvious question is, what about the rest of this stuff? What do we do about all this stuff? And since you're at a Cloud Foundry conference, I hope you know the answer. Boom, CF push. CF push is great. Here's my code, run in the Cloud. I can't not put the haiku in there somewhere. And it's all about this stuff, right? It's all about iterating faster, building good stuff, keeping it running, and actually being cheap, right? It's multi-tenant. This is great. So, what happened then, right? Why didn't CF push end the conversation and that was the end of the story? Why don't I leave the stage now? Don't say that loudly. But why isn't that the end of the story? Sorry. Firstly, why did that work? State is bad, right? How does CF work? This is important to say. Why did CF work? How did it solve the problems? Because state is bad. Databases, messages, all this stuff, servers and orchestration. And what it does is just hide it behind an abstraction, right? And the reason that's good is then all your apps live in the good place here, right? Like they don't have to worry about that stuff. This is actually amazing, right? This is incredibly good. Why is it good? Because state is the magic trick that turns cattle into pets, right? You want cattle. You want a herd. You want everything to be easy to manage. And as soon as you add states of stuff, it's a pet. It's hard. Databases are hard. You have to back them up and maintain them. Apps aren't hard. Apps are great. So, keep these two things separate. Keep your pets in one place. Keep your cattle in the other place. Have a status abstraction. And everything was great containers, right? That's why it's not the end of the conversation. Because suddenly containers came along and people were like, we want containers for an orchestration. So, okay, we have to ask, what are these container things? What's this container stuff that's suddenly changed everyone's mind about whether the problem was solved? So, we have to go back to the past. Some people have seen these slides before. They're different. So, we have to go back to past. How did this start? There were jar files right once or anywhere. Didn't quite work, because we needed isolation. We wanted stuff that worked for multiple languages, where you weren't subject to dependencies and stuff, so we were like, okay, hey, Linus, why don't you give us some of this namespace stuff, C group stuff. Linus was like, okay, by the way, I know that this wasn't actually Linus. It was some other smart people. Linus is a metaphor. But Linus was metaphorically like, here you go, right? Here are the namespaces stuff. So, you now had this isolation primitive in the Linus kernel. It was like, here's your C group stuff. So, you can now share resources between your containers. They don't keep taking as much resources as other things, and everything's going to be managed nicely. We built this warden thing, and then this garden thing, and then we had this CF push abstraction, and we need push code, and we create these linus containers, and everything was good. Except it wasn't good, right, because containers, right? That's containers. We had containers, but what happened? Well, Docker, right? There was this new thing called Docker, a disturbance in the force. So, what did Docker do that was different, right? What was this new thing above this Linus container stuff, which actually we already had? It actually did two things, which I think are really important. The first one, and this is this containers idea that became containers as opposed to Linus containers, was encapsulation. It was this idea that we could take the whole OS, put it in a box, and ship it around. That's not something that we had in that CF push model. And the second thing, of course, was marketing. The second thing, of course, was user experience. They created this amazing UX around containers. They created this amazing UX around containers that made it so easy to work with containers that people were like, you know, I can manage these containers myself. I can deal with these containers myself. And a lot of people wanted to do that. This was this really cool thing. I could use these containers. Why do I need to push code? I can just use containers. I think we got a bit confused about that. So quite a lot of people really wanted containers. And quite a few of other people were like, can't we just push code? This was the conversation for a little while, right? We in the CF community, in the past community, were like, just let me push some code. It's fine. I don't want to deal with all that container stuff. Container people were like, no, give me containers. We were like, you sure you don't want to just push some code? It's really great. And they were like containers, but louder. They're much louder. And we were like, push code, so we compromised. And we said, well, you push containers, we'll push code and everything will be fine. And of course, we all lived happily ever after, right? That was the end of the story then. Except it wasn't quite the end of the story. Does anyone know what came next in the story? Serverless. Just push code. It's great. So what's going on, right? There's something wrong. There's something going on. I think we've got confused about whether the difference is really code and containers. I think it's something else. And of course, that's something else. It's state. State was where we started with all of this. State is bad. Why is state bad? Let's go back and ask why it's so important to get rid of states. Why was that such a big part of what we were doing? And frankly, a bigger part than just code versus containers. It's because of the state for late. Oh, no, credit war martin. I was supposed to write credit war martin on this slide because he came up with that stupid word, stupid phrase. It's such a coincidence that they turned out to be eight problems with states just after we came up with that funny pun. So the problem with state is as soon as you add state, stuff gets hard to scale and upgrade, hard to recover from problems. You can't just throw one away and create a new one. You can't just add one on the end. It's hard to A, B test and roll back and all of these things. By the way, it's just a little aside. Think about this thing again. I think about the apps and the stateful stuff and everything was good. Every time you see one of these Docker or Kubernetes demos or these container demos, you see this. This is the simplest one I can find. I'm not picking on it. This is a relatively simple one. What's wrong with this? What's wrong with this image? Anyone? What's wrong with this image? It's your code. Node and Mongo. It's pushing. No. You don't just push Mongo. Services are for pushing. Code is for pushing. Services are for binding. You don't want every single app developer pushing a MongoDB. They have to worry about backing that up, about monitoring that. They just want to push code. Friends don't let friends. Why? Because of stateful A. Once you do this stuff, stuff gets hard to scale and you don't want to be paying that penalty for every single one of your apps. What is cloud for? It's about iterating fast. It's about delivering value. Where do you need to do that? I would argue it's probably your application. It's probably your code. It's unlikely to be your redis. You don't need to iterate your redis quickly. Your redis is a pretty solved problem. Where you need the benefits of this stuff is your code. That was a nice model. Stateless is greatness. Why is state good? It's for the exact opposite reasons. Once you don't have state, it's really easy to scale stuff and upgrade stuff and patch stuff and roll it back and do A, B testing. It's really easy when it blows up to know what's valid in terms of getting it unblown up. You know what things you can do. You know you can throw any instance away and that's fine. That's a really important property. So, there are lots of systems that take advantage of this. Serverless has suddenly got taken advantage of status functions, pay-per-use, autoscaling. What's CF push? It's status apps paid by memory, autoscaling. The difference isn't code and containers. The difference is statelessness. And it's not the only thing. MapReduce had the same trick. MapReduce is a way of processing huge amounts of data without reinventing how to do data parallel pipelines all the time. How stateless map functions, stateless reduce functions, don't push a Hadoop cluster, give me your map and your reduce code. So, that way, interesting problems. Yes, all that hard stuff, you can let something else take care of. Fun and toil. Stateless and stateful. That's the trick. And the good place and the bad place. We can live in the good place most of the time if we make the bad place someone else's problem. So, the problem is state. State is bad. Containers and Kubernetes are fantastic. These are fantastic ways of dealing with those stateful problems. But actually, I think keeping the good place and the bad place separate is quite a good idea. Because a lot of what you do is just code. So, good solutions, comparisons. Just going to talk quickly about Cloud Foundry and Kubernetes, Cloud Foundry and Serverless and like how these all relate. So, I think one thing to really understand is Cloud Foundry is still containers. Cloud Foundry has been containers all along. If you want to do cf push-o, you can. Cf local now, there's really great tools for interoperating with that world. It's not about whether you use code or whether you use build packs, whether you use containers. It's about whether it's stateless or not. That's the big difference. Kubernetes is fantastic for the stateful stuff. And it's awesome we now have tools for integrating these together. But it's not about code. It's not about code. It's about state. Come to our talk about cube in the past at 1205 earlier today. I was thinking all day I need to update that, but now it's funny joke. Serverless. They're actually both stateless. It's really just about functions versus apps. They both take your code. There are some other differences with serverless I think are really interesting. But fundamentally these I think are things that let you go faster, iterate faster and pay a bit less. So that's how you choose between them. You choose by which one fits your use case. So that's the talk. Suffering exists. This is the nature of suffering. That was a path to end suffering. Hopefully that lets you spend more time on fun and less time on toil. So you can have the good problems, user experience, performance, analytics, AI, any of these nice things and not orchestration and containers and high availability and backup and recovery and all that stuff, which if we're still worrying about in five years as an average developer, I think we'll be really sad. So have 99 good problems, but hopefully don't let containers be one. Thank you very much.