Colin Humphreys - Creating the Cloud-Native Learning Organisation

Hello, testing. Can you hear me? Hey, fantastic. Light as well. You can see me as well. Great. Thank you all for coming. My name is Colin Humphreys. I am CTO for Cloud at Pivotal. I apologize for the delay. The problem we were having was we were trying to get on the Wi-Fi on my laptop, and as you can tell, I'm English, and we didn't have a number of special characters to join the Wi-Fi, so we didn't have the eye with the two dots on top. We were trying to get on. We had a few problems. Unfortunately, we may have to cut the very brief demo out of this. It wasn't very exciting anyway, just because I couldn't go on the Wi-Fi. That's okay. So, we're here to talk about creating the cloud-native learning organization and what that means. So, for those of you that haven't met me before, as I said, I'm Colin Humphreys. I'm well known for coming out with sound bites and interesting things at talks, which is why the Pivotal public relations people send me around to a lot of conferences because I say controversial things. One of the things I said is that Cloud Foundry is not exciting. What's exciting is what you can do with Cloud Foundry. So, a quick show of hands. I can't really see you, but who's heard of Cloud Foundry here? A few people. Thank you for the lights. That's great. So, I did say this. You may notice that this is attributed to my name, but the gentleman behind me, this is actually Colin Humphreys. This is Colin Humphreys, professor of metallurgy at Cambridge University in England. This is not me, but all of my quotes get attributed to him for reasons I don't understand. So, thank you, Colin. The scary thing about this is that the link down the bottom here, as you can see, there's over 90,000 Colin Humphreyses out there. There's like a robot army of Colin Humphreyses coming to kill you in the very near future. I'd be worried about that. But I'm not actually here to talk about me. I'm here to talk about learning. Now, why am I going to talk about learning? Because in my opinion, software development is about learning. It's about learning about your users, about learning about your market, learning about your customers. But why do I think that? Why am I so fixated on learning? So, we're going to have a quick detour. I'm going to talk about methodology. So, three methodologies I want to talk to you about very, very briefly. Agile, Lean, and Six Sigma. I like a bit of audience participation. Who in the room thinks they're doing Agile? Oh, quite a few people. Who's doing Lean? A couple of people. Is anyone doing Six Sigma? Some people. A few kind of curious-looking folks. Okay. So, I don't think these actually exist independently of each other. I think they actually represent more of a spectrum. So, Agile, the key metric is responsiveness to change. How fast can you change direction? With Lean, the key metric is cycle time. With Six Sigma, the key metric is deviation. So, very few hands went up about Six Sigma. Those of you that haven't used it, it's about trying to make the next unit you produce 99.9999% like the last one you produced. So, trying to have Six Sigmas of confidence that the next one will be identical to the last one. So, it's a lot about kind of mass production, building lots and lots of things. And I think these represent a spectrum, as I said. I think if you're focused on learning, you tend to be more towards the Agile side. So, if you're learning about your users, if you have high uncertainty, you're more on the Agile side. If you're looking for efficiency, you tend to be focused more on the Six Sigma side. So, the example I'd like to give you here is one of cooking. Sounds a bit strange. Please allow me to clarify. If you are baking a cake, you probably want to make one of them and find out whether or not you like the taste of that cake. Okay? And then if you don't like it, you'll change the ingredients and bake another one. Makes sense. So, this kind of leads us towards the Agile side, because we're learning about what we're building. We're experimenting with recipes. If you go into McDonald's and you order a Big Mac, you probably don't want the person that cooks that Big Mac experimenting with the recipe. You probably want to have a Big Mac that's exactly like the last one you ate and the last one that you ate. So, it lends itself more towards Six Sigma. Now, I think if you're developing software, it's very easy to mass-produce software, because you have a copy command on your laptop that can mass-produce software incredibly quickly. So, if we're developing software, we tend to be focused more towards the Agile and Lean end of the spectrum. So, if we're developing software, we're focusing on learning. Focusing on learning about our customers. So, let's get back on track. Now we know we're focused on learning. This has been recognized across the industry. So, this quote, everyone must be able to experiment, learn, and iterate. This is back from 2006, over 10 years ago, from an Amazon blog. I believe Amazon has been reasonably successful since then. So, this is a well-proven kind of ethos. Everyone must be able to run experiments and to learn. But asking a very metaphysical question, how do we learn? So, when I was at school, I learned by scientific method. Another show of hands, who's heard of scientific method? Quite a few of you. Great. I'm going to cover this in a very small amount of detail. So, this slide gives you an idea of scientific method. We have a theory, something we think is going to be true, make a prediction based upon that theory, something that's going to happen. We then run the experiment to actually put the theory into practice. We then observe the results. So, when I was at school, I had a theory. My theory was that thermite reactions are fun. If any of you have played with thermite, you'll know they're fun. My prediction was if I lit a thermite reaction in my science class, everyone would think I was super cool. So, my experiment was to light a thermite reaction on the desk in my science class, and I observed that I was suspended from school for burning a hole in one of the desks. That wasn't quite what I intended to have happen, but that was something I learned via this method. Now, I did a little research on this. I found that we as humans have been acquiring and validating knowledge in this way for as long as we've had civilization. There's evidence of this being used in ancient Egypt. Recently, I've noticed this is absolutely everywhere. So, this is the cycle from a famous book called Lean Startup by Eric Ries. Who's read Lean Startup? I think we're getting audience fatigue now. People aren't putting their hands up, but thank you for those that have. There's a book along similar lines called Four Steps to the Epiphany. These are really changing how we do product management. The idea being that you have an idea, you build that out via some code, you measure whether or not your customers like what you're building, very sensible, by looking at the data, you learn something, you form a conclusion, and you have some new ideas. The book correctly states the faster you can go through these cycles, the faster you can learn, the more successful you will be. Another one here, the OODA Loop, Observe, Orientate, Decide, Act. A gentleman called John Boyd came out with this idea. John Boyd was an F-86 Sabre fighter pilot in the Korean War. He was effectively trying to work out why the American pilots were regularly losing battles to what effectively were Russian pilots fighting on the Korean side. Why they were losing those battles, given they had a vastly superior, in all ways, fighter. It turned out the reason why they were losing these dogfights was because the Russian plane could turn faster. In that aspect, it was superior. This is all about being able to observe what's going on and change direction quickly. You can see how that has a direct correlation to some of the things we think about agile, being able to change direction quickly brings success. My personal favorite learning cycle is this one. This is the Deming Cycle, Plan, Do, Check, Act. You notice how these are all very similar implementations of scientific method. Deming was a fascinating person. He took the development, or the building, of B-29 bombers in the Second World War. He took it from being multiple weeks per bomber to delivering multiple bombers per day, based around testing out hypotheses in the way that they were built. He's known as very famous for those reasons. Interestingly enough, he was effectively shunned by the Americans after World War II, because he'd done his great work. He then went over to Japan and helped out with their manufacturing and helped the Japanese car industry destroy the American car industry because it was so successful. A lot of the ideas in Toyota manufacturing come from Deming's ideas. I realize you probably came here for a tech talk. I've turned this into a history lesson. I apologize for that. There's going to be more history as we go on. The thing to notice from all of these, from Lean Startup, Forceps, Epiphany, Deming Cycles, all the stuff I'm talking about here, the key aspect is that the faster you can test out ideas, the faster you can go through these cycles, the more successful your company will be because you will learn what works, you will learn what doesn't work, you learn what users like, you learn what users don't like. That's really, really important. To illustrate why that's so important, have you ever noticed how, on your phone, the apps that update most frequently are from the most successful companies? Correlation is not causation, but those companies are learning faster, which breeds success. If you want Colin's top tip to get rich quick, go and find a market area, a segment, where nobody's learning and nobody's iterating. Establish in that area and outlearn the other companies and you'll beat them. This is all very theoretical. I appreciate that, and largely historical. How do we actually put this into practice? How do we as Pivotal actually make this work for our customers? I like to do an exercise called value stream mapping. Some of you may have done this. This is a lean technique. Take what you're building to have an idea and think about the activities you have to undertake to go from idea to delivery. We work with our customers and we do this ourselves. We plot the activities going across from idea to delivery. We do this with Post-it notes generally. Stick them on a wall, put timings against them. It's great to work out your cycle time doing this. For the things we typically do, we'll take the idea, break it down into stories. We love XP at Pivotal, so we'll do some test-driven development and pair programming to bring those stories to life. Commit our code into a continuous integration system. Deploy our code to Cloud Foundry. For those of you that haven't heard of it, it's a platform as a service. You can write code, push your code, and it works. Then it's delivered. Once you've done this and mapped out how you go from idea to reality, then think how do I look at some data to work out whether or not the feature that I've built is good or bad? How do I get feedback? What's interesting about doing this when you talk to companies about it, about how do they go to delivery, is quite a lot of companies never look at any data. They never actually work out whether or not the things they're delivering are good or bad. Think about that. How do we get some feedback? Then think, well, who actually listens to that feedback? How do you engage back with the people having the ideas such that they can have a new idea based upon the knowledge they've gained from the first delivery? Because if you take this, you do the value stream mapping, you think about data and get the feedback, you feedback that data to people making decisions and they have a new idea, you've created a learning loop. This looks like, okay, it's a Deming cycle. We can map all the things we've just said. Stories, test driven development, pairing CI Cloud Foundry on the do side. We check with our data and we engage the business to think about having a new idea. Okay, so I realize I can't quite see you, but a lot of you are probably thinking this is blindingly obvious, Colin. Why are you even telling us this? This is so obvious, so simple, so straightforward. Surely everybody's doing this. Well, I hope that's true, and if you are doing this, that's fantastic. I personally worked on a project that had a three-year-long Gantt chart to deliver. It was 12 million pounds, so that's about 50 euros nowadays, I think. We'll be doing more Brexit jokes, so come on, keep up. Okay, so that's not a lot of money, but it was then. It was lots of money back in those days. So we took three years and 12 million pounds to go from somebody having an idea about delivering some insurance software. We bought some land, we built a data center on that land, we put servers in there, we put operating systems on there, we put application servers, database servers on there. We wrote lots of software, obviously. We had everything planned out minutely, and we hit our three-year deadline, and then after three years and all this money, the users absolutely hated what we built. Nobody used it. The servers were reconditioned to be an exchange farm, and a lot of people lost their jobs. So that was a huge amount of waste based upon a massive batch. Now, the part of this that I think is interesting is that the reaction of that company was not to say, oh, whoops, let's do it faster next time, let's execute faster. They actually said what you should do is plan more, you should design more, next time we'll do it in five years, and then we'll get it right. Because people get very scared when they have those kind of failures. So I think our role is to help people go through these loops faster, because if you succeed, that's great, but it's about having a faster iteration so that if you can work out what you're not doing, you don't waste three years of your life. So where does this go wrong? What are the anti-patterns that we see? Why does this not happen? Because you're looking at me like this is blindingly obvious. Surely everybody's doing these fast iterative cycles. So what happens if you don't complete the loop? So part of what I see a lot at the moment, lots of companies doing this, an anti-pattern called water scrum fall. So I see development teams who are doing lots of very agile stuff. We all like to be agile, lots of hands went up. So they're doing story mapping, they've got lots of post-it notes, maybe doing a bit of lean, they've got Kanban boards, this is great. They've got CI systems, this is awesome. They're probably doing some test-driven development, some pair programming, everything's wonderful. So what they do, they commit code, the code then runs, the CI system's tested, that CI system puts out integration environment, everything runs, that's fantastic. Why don't we put it to production and show it to some customers? Oh, the production environment's not going to be ready for another two years. We've just bought the land, we're building the data center. Or we're building a huge platform of the future. You're going to have to give us a few years before we go into production. Now, you'll hear at this conference, I'm sure you've heard lots of people talking about platform shaped things, lots of the cool things happening in modern infrastructure. So you're probably thinking, isn't that the bad old days, Colin? Surely nowadays we're pushing at least a million times a second, because this is the cool new future. I'm not sure that's true. What I think does happen is people with modern tooling still spend a long time building out platforms. I'm going to give examples of that. This is a talk I went to recently. This was at Jaxx London. This gentleman gave a fantastic talk on Kubernetes. Now, I'm not calling out Kubernetes here. I love Kubernetes. Great technology. I'm not going to pick on Kubernetes or Mesos or anything else that's a container scheduler. But I went to see this talk. Basically, it was how you can take a year to build a production platform using a container scheduler. So I'm not sure that's necessarily the right way forward. Another one here. One year using Kubernetes in production. This, again, a one-year time frame to take a scheduler and turn it into a production platform. So I think, you know, these are some of the latest tools. Again, I'm very clear here. I'm not picking on K8s. I love Kubernetes. This is true of a lot of things at the same abstraction layer. But we still waste a lot of time building production platforms and delaying that delivery to production. So what's missing from things like this? I have a slide here. This is a colleague of mine. This is Bridget. She's fantastic. If you ever get the chance to see her speak, I recommend you do so. This is also very meta because you see she's presenting to a group of people and then I'm presenting her presenting. So if any of you want to get a photo of me pointing at her and then we can like someone else from Pivotal can show that and then we can keep going back in terms of layers. Bridget here is talking about the things you need to run production code, what a platform needs. Routing and load balancing, log aggregation, infrastructure orchestration, health management, a whole ton of stuff that you have to add on to a lot of the schedulers we see at the moment. So what I am saying is if you're building all these things yourself, you need to stop wasting your time. Because we're building the same platforms again and again and again. And what I want to posit, I'm completely biased here, is that if you are building these things again and again and again, come work with us on Cloud Foundry. These production grade platforms, this is what we're building. Now, this is where things in my talk start to fall apart. Here is where I would show you the amazing Cloud Foundry journey where I write some code and I push it in a demo. However, due to my keyboard being a UK keyboard, I don't have any Wi-Fi access. The cloud is wonderful if you can get to it. It's not so good when you can't. I do have Cloud Foundry running on my local laptop, but I haven't set up my local DNS server. So, unfortunately, I'm going to have to skip a demo. If you can imagine what happens here, because it doesn't require much imagination, I would stand in front of you, I would type in some code, I would write some very bad Ruby for you, because I'm a terrible developer, and then I would type CF push and I would hit enter. And then Cloud Foundry will take my code, it will recognize that it is Ruby, it will compile it into something called a droplet that is ready to run and be scaled, and it will then run that code inside of a container. And I love containers. It will then enable me to route production traffic to it. It does that automatically. It gives me logs automatically. It enables me to scale up and scale down, either via an autoscaler or whenever I demand, to bring in backing services behind that if I want to bring in databases. All of these things. And there are many Cloud Foundries out there from various different providers, not just Pivotal. So, all the things that would take, you know, a year to build yourself, if not more, are there ready to use. But we're going to have to imagine that demo, so I apologize for that. Now, I think that stuff's pretty awesome. I'm going to give you a very quick example of something we built using Cloud Foundry. This is a Cloud Foundry success story. So, this is about one of the UK's largest charities called Comic Relief. Comic Relief has been a huge Cloud Foundry success story. It's interesting, Comic Relief, because what happens, they have a once a year kind of donations night when they ask people to donate. And at the absolute peak of donations, people donating on their credit cards, they do approximately the same number of transactions per second on their credit cards as the rest of the UK economy combined. Now, I realize that sounded far more impressive before Brexit, because the UK economy is basically disappearing. But it's quite an impressive set of numbers. This takes, as you can see here, £75 million in about a six-hour period. Fairly impressive. What's interesting about this as well is this was taken from being a platform delivered by 50 people that had never worked and delivered every single donation to being a platform delivered by five people that has taken every single donation without outage for the past four years. And that went from being a Java Oracle stack to being simple applications CF pushed to Cloud Foundry. That's a very big change. If you're an architect, and we all love being architects, this is the architecture. It ran active, active, active across AWS, EU, AWS US, and a VMware provider, a completely different infrastructure in the UK. And it was active across all three. So Cloud Foundry runs this up to a huge scale. It can run each one of these with a separate Cloud Foundry. The same code runs in all of them. A Cloud Foundry can scale up to about half a million containers is as far as we've tested it. So we can run half a million application instances in each one. What's particularly nice about this is not actually the architecture. What's nice about it is building all of this infrastructure in terms of platform and all of the applications, the 27 microservices that comprise all of this, took five people four months. And like I said, at peak rivals the rest of the UK economy. So I think it's those metrics in terms of automation and in terms of lowering the work you have to do to get truly awesome things built that are really good. I think the most staggering thing about this, back to the article, is not what's being built. But you'll notice this article was written by me. I was involved in this. And if I can do it, anyone can do it. And not only that, this article was written in 2013 about work that was done in 2012. This is four years old. It's been running for the last four years. This is not brand new stuff. People are showing you the latest new technology hotness. Four years this has been running. So what are the patterns to doing this? How do we make this happen? So recommend, if you can, deploy on day one. Getting your code to production should not block your flow. So I think if you have a platform like Cloud Foundry, you can CF push day one, you can get real user feedback. So let's say we've got that. Our story doesn't end here. I am going to be controversial. I'm going to call out continuous delivery as an anti-pattern. Now, I love continuous delivery. I keep saying I love things, but I do love continuous delivery. Unfortunately, it's not the end of the story. Okay? If you are continuously delivering, it gives you this kind of a cannon with which to fire out feature after feature after feature. So many features. But what you need to be doing is if you just fire out the features and you never check the data, how do you know if you're making your services better? So when you see feature explosion on websites, so many things that can do so many things, it's somebody who's not looking at their data. But I think we can now very easily, via continuous delivery, push out new things. We can push out new services. So what we need to do is check our data. And when we start bringing in the data, we move to microservices. Small, focused services. So I think the move to microservices is good. I'm one of those people. Because I think humans can't solve big problems. We need to solve small problems. We can divide and conquer. So we can do that if we break things down into lots of smaller things. So this is, again, why I think you need a platform to deliver your code. Because if you move to microservices and you decompose a monolith, as we did with Comic Relief, from one big app to 27 small apps, if you don't have a platform, you have 27 deployment problems. You have 27 stacks to look after. That's kind of painful. So let's talk about how we do this. I'm now going to go on an implementation detour. And because I am tremendously lazy, I'm going to give you the lazy person's guide to cloud native microservices. I'm sure there's some of you in here who are absolute experts on microservices and are going to take issue with everything I say. And that's okay. Because for the rest of you, I hope you'll like this and hope you'll be as lazy as me. So let's say we've got our cloud native platform, we've got Cloud Foundry. What happens next? People will tell you to read a book by Eric Evans called Domain Driven Design. This is a fantastic book. Very well considered. I read the first couple of chapters and then I got bored and I flick read the rest. So I recommend what you do. Don't do that. Be lazy like me. Divide by reason to change. So let your microservices emerge. So start small. And then when you find yourself changing a part of the code base for a particular reason, you find it changes together, split that out into a different microservice. So you can let your microservices almost emerge by themselves, by listening and learning as to the way you're developing. So you'll see things, oh, we need to do this thing with users, this thing with users, this thing with users. Users might well become microservices. We just keep changing billing, change billing for this reason, billing for this reason. Billing might become a microservice. So you don't have to do everything up front. You can let your microservices emerge. Next up, 12-factor applications. This is a set of patterns from the wonderful people at Heroku. These are effectively the commandments for being cloud native. Thou shalt do these 12 things. But as I said, I'm lazy. Why do 12 things when you can do one thing? So let's not do 12. Let's do one-factor application. The key pattern from 12 factors to make your application cloud native, the absolute key is that you do not store state on the local disk. So that one is the one to really obey. Okay? Use brokered services outside of your platform. If you don't do anything else, do this one. So you can now claim to be cloud natives because I told you that one pattern. There are lots of great value in the other patterns, but that one is the one to listen to. You'll also hear about Netflix patterns. So Netflix have been championing a set of fantastic patterns for enabling cloud native delivery. Client-side load balancing, circuit breakers, all these kinds of things. These are all fantastic. We actually package these together and these are available as something called spring cloud services. So these are really useful. But as I said, you don't want to do all these at once. The one you want to pick is circuit breakers. I think they're the key pattern. Mike Nygaard popularized these in a book called Release It. These make your application, your small services, resilient to failure. So the idea with a circuit breaker is that if your application, your service, is consuming other services and they go offline, it will break the circuit to the other service. So what this means is if you've got a Java web server and it's calling out to external services of HTTP, if one of the external services goes offline, it will notice that and it will stop calling out for a short period of time to that service and try again. It will break the circuit. And what this means is your Java web server, which in the past will have just occupied all its threads trying to call out to a service that's not there, taking your site offline, that doesn't happen anymore. If the remote service is being denial of service by lots of things hitting it, it means you let it recover because you aren't hitting it for that period of time your circuit breaks. This also means for that period of time, you make your application that has broken the circuit to the external service, you make it do the right thing as best it can in the absence of the other service. So if it's billing, maybe while billing is offline, you don't take billing. You just say to the user, I'm sorry, we can't do that right now, please come back in a bit. Isolating your application by all these small services that have circuit breakers makes your application resilient, okay, and it can survive failures. And these make your services operable. So please do have a look at circuit breakers. Okay, let's get back on track. That's the end of my lazy guide to cloud-native microservices. So if we do that, back to our learning cycle, we're now planning, we're doing, we're checking. But if we're in the land of microservices, one of the main problems that I see and why I can see microservices becoming an anti-pattern is that you end up with all these small services, with teams working on each small service, but you lose track of the broader goal of what you're trying to achieve. So the example I've seen with this is where you have a front-end team, and their metric, they're looking at the data here and seeing how many users do we get on the site. We're targeted for maximum number of users on the site. Brilliant. So you take your small website, and then you decide to put some clickbait about the Cardassians or something else that's popular on your site, and you get lots more users. So you just start putting on lots and lots of things that are very interesting, but make you no money, because you're getting tons and tons of users. Next thing you know, you're consuming terabytes of bandwidth, but you're not making any money. But your data is telling you you're doing a great job. This is fantastic. Because you're focused on the micro and not looking at the bigger picture. So I think if you're going to do microservices, you do need to have a tight interaction between the teams that are building them and the business itself. So I think if you bring the whole cycle together, you find the constraint in that cycle, that's when you will become truly DevOps, because you're bringing development operations. I think DevOps needs to become Dev Biz Ops or something for all the teams that are involved. So there's a book called The Phoenix Project you should definitely read. That's a rewrite of a book called The Goal by Goldrat, which is a fantastic book about looking at entire systems. And I want to reclaim the word DevOps to not mean configuration management or containers, and to mean looking at systems and finding the constraint. So that's a lot of opinions from me. Why should you listen to me? It's a good question. My judgment has been questioned before. You lose a lot of credibility saying things like this. Somebody said about me. I think the joke's really on them because I never had any credibility. So yeah. I've been accused of being blatantly misinforming. That's a bit unkind, isn't it? Someone from Mesosphere. My particular favorite criticizing me is this one. You're so simple. This is an English grammar joke, by the way, because I responded to this with what about my so simple. I realize that doesn't work so well with a French audience. People have taken issue with the things I've said, which is absolutely fine. Please feel free to do so. But what I'm really asking you to do here, I'm asking you to empathize with the business. I don't know if you've tried to run a business. I ran a business. It was difficult. I'm asking you to empathize with the business to learn about their customers. Because I've also spent a lot of my career as a developer. As a developer, we have this cycle. Red, green, refactor. We can write a test that's failing. We can make that test pass. Go green. We can then refactor our code. A good friend of mine talks about this, saying that you write your tests drunk and your code sober, because if you have a good test suite from which you can get fast feedback, you don't have to write great code. Your tests tell you when it's working. This gives us as developers a really high degree of confidence in what we're writing. This is great for developers, but then if you're a business person, you don't have this. If you're a business person, you have this. Now, for those of you that haven't seen one of To give you a guide to it, it starts at the top left with unreasonable demands and it ends at the bottom right with everyone losing their jobs. Now you know Gantt charts. I object to this in software development. I want to help people. I want to transform this. What am I doing to change this? I don't want to see a Gantt chart. I want to see a series of learning cycles. I want to see products and learning rather than projects and deadlines. The one that's particularly interesting, I want to see big companies become like venture capitalists, investing in a series of small products and the ones that don't succeed, based on feedback, take those people, put them onto the ones that are succeeding. I find it really strange when I talk to C-level executives of big companies and they often sound so fearful, so scared about being disrupted by startups. To succeed, I think you need great people, you need some money to make things happen, and you need customers. The really strange thing is if you think about it, enterprises have got all of those three. The startups don't have any. They're tiny companies, they have no people, they have no money, and they have no customers. Why are enterprises scared of startups? I think the bigger companies need to become venture capitalists and we're hoping to power that at Pivotal. We are creating this learning loop. We have Pivotal Labs. It's about agile development, planning, helping people break down big ideas into small testable hypotheses. We have Pivotal Cloud Foundry, which is that platform which we imagined earlier on when my demo failed, which gives you a single command for deployment so you can get things delivered fast. We have Pivotal Big Data Suite, giving you that data that can drive your decisions and then help people work with the business to actually take the right actions. This is automation day, talking about what happens when you automate, and I think you can learn when you automate. I think it's all about organizational learning, and we at Pivotal, as you can see, we are building the operating system for organizational learning. And I think that's a great quote. I think that's such a good quote. I'm going to attribute it to Colin Humphreys, Professor of Metallurgy, Cambridge University. Thank you all very much for listening. That's the end of my talk. Thank you for coming.