 Hi, I'm Etsy, a production engineer at OVO Energy, and I'm going to talk to you about why you need platform engineering. So yeah, I work for OVO Energy. OVO is a UK-based energy provider with a strong commitment to net zero carbon. You build it, you run it. We've all been saying this for a really long time now, but we've all interpreted it pretty differently. So what does it mean? So I can talk about how OVO has interpreted it. When a new team starts up, they set up the majority of their platform themselves. They choose a Cloud provider within the Clouds that we operate in, create their Cloud projects, set up a VPC, connect it to the shared network, do something about databases, deploy some Kubernetes clusters, choose a monitoring and logging tool, spoiler, we've got lots. Choose a DNS provider, we've got lots. You get the picture, there's quite a lot they have to do. So what does our estate look like today? We're using three Cloud vendors. We have 135 Kubernetes clusters across those Cloud vendors, and give or take, that's for around 500 engineers across products, data and engineering. This means that we've got a maintenance burden of one Kubernetes cluster for every 3.7 engineers in the organization. Typically, it takes a new team 25 days to get their platform running to a point where they can start contributing to their team's core remit. The ongoing impact is that teams will spend between 20 and 40 percent of their time on platform maintenance. As an organization, you have to ask yourself where your value is. The value for OVO is in creating transformational energy solutions, and the value for our teams is in helping contribute towards that value, not in maintaining their own platform. Given our current estate and the impact on our teams, we're not optimized for value. So what are we doing about it? This was our first take on using a platform engineering model to try and help our teams. Centralized platform teams would build components such as infrastructure as code modules, reusable CI workflows, and actively engage with teams on their projects and write guides for them to know what to do. However, each team was still responsible for running their own platform. As a model in optimizing engineers time, this can be pretty effective, but there are situations where it falls down. Teams still own their Kubernetes clusters and things can happen outside the control of the tooling provided to them by the platform team. We had an incident where centralized tooling was making requests to the control plane of every cluster in the organization and was inadvertently calling deprecated APIs. One of the managed providers needed for those APIs not to be called in order to make automatic upgrades. So about three-quarters of the clusters of the organization were being blocked from auto-upgrade. Every team involved was asked to go and investigate and spending a lot of time trying to work out what was going on. The disruption only stopped when we found the root cause of the issue by which time teams has spent lots of time trying to work out what was going on with their clusters. So what are we doing about it now? Internally named Project Bedrock, we've built a new multi-tenant platform that allows developers to deploy their services to the Cloud without having to manage the auxiliary supporting services around their platform. We've achieved this by building a platform using Cloud-native technologies. Running a multi-tenant platform comes with plenty of new challenges and often these are a lot more complex than the ones that were faced by the teams when running their own platforms. But crucially, these challenges are now being tackled in a platform team with the expertise and focus in order to solve them, leaving the majority of our teams to focus on what matters, their value. So why might you need platform engineering? If this talk reminded you of any similarities with your organization and you think that you might not be optimizing for your value, then perhaps a similar journey could help you too. Thank you.