 So now we'd like to hear from Steve O'Day, Clydesdale Bank. Hi, how are you doing? Yeah, I'm Steve O'Day from Clydesdale Bank, Clydesdale New Yorkshire Bank. I'm a technical consultant in the bank and my roles are technical lead in our platform engineering team. The platform engineering team is a team that have brought OpenShift into the bank. I'm going to talk a little bit on why we chose OpenShift. We, about three years ago, started work on a digital brand called B. That digital brand was a star of our digital transformation. And like most others, it involved building a microservice architecture. Now, being a microservice architecture, we saw the good, the bad and the ugly of it, to be honest. The good, we saw the benefits. We can scale little bits up, we can scale bits down. We can keep small little changes going. We saw the bad, which was the configuration. We now had to manage configuration to 40, 50 different components rather than one, as well as the dependencies of all of those. And we saw the ugly, which was the amount of time and effort it took just to manage that and to get it into production and just to then keep it going to make it better. So based on that, we started to look at how could we do it better with containers. Some of the benefits that we hoped to get from our operational platform, as we call it, or from the platform of the service was the auto scaling, the auto healing, the service location. So we've now built an API gateway, which uses the Kubernetes APIs to allow us to, when a new microservice comes up, it automatically reconfigures the gateway for us and allows us to expose what we need to be exposed. We've also embedded a bunch of our operational imperatives into our containers. So our containers automatically get the application performance management built in. We don't need to remember to get it added in. We don't need to tell the developers you need to do this. So that's great. We started to enable build and burn environments. So we don't need to worry about how many people are going into the same environment. Every developer can have almost an environment on their laptop. They can then take it through the pipeline and build new environments as they need it. And we've also then been able to get it to integrate with the rest of the system. One of the things that we did do was to fix the problem that we've seen with configuration and dependency management, we started to build some of our own tooling. Now, we've done this about two years ago, and we've been working on it. And it's only recently we started to realize that we'd started to build a service broker. We didn't put all the right APIs around it, but we've got all the sort of the workings there. So that's somewhere where we're going next. And just finally to share a little bit of one of the successes, the first application we took on to the PaaS, usually we would release monthly. And it would take between a month, two months. So you'd maybe get in a three-month period, one or two releases. The first service we brought on, we built it 52 times, deployed it 89 times into different test environments, and then deployed it 36 times into production in a three-month period. So we really started to see that we could get the bank moving towards a continuous delivery practice. And that's all from me. Thank you, Steve.