 So this is the story of how it into it. We got GitOps to all our developers and what it really takes to enable front-end, back-end, AI developers, everybody, to rapidly create, update, and dispose very important of applications. This is the Cliff Notes version. For those who know what Cliff Notes are, so our learning involved that we had to do deployment, we had to do configuration, we had to cover monitoring, we had to cover cloud interactions, cloud resources, alerting, and more and more and more. There is really a lot that goes into this. And so what we found out, like most people know, in most software that get working with GitOps, create different software assets. You need to create a repo. You have to populate it with sample working code that demonstrates and propagates the standards we'd like to follow in the company for consistency, security, and compliance. And so it was it into it. And we were very proud of ourselves about three years ago when we got to this point. And then we realized that there's add-ons, that there are things that people want to add afterwards and we had to give them documentation instead of automation, database access, messaging access, and so on. And they used to file a ticket, they used to create the new resources or get access permissions and then follow some Wiki to update their code, but not anymore. And then there were different updates that had to be happening. For example, the platform change, we went to Kubernetes 116 and suddenly we had to send 3,000 PRs and trace all those teams and work with them and everything else. And while there are tools like Dependabot and SNCC and so on that help with the simple dependencies, when you need to handle the more complicated ones, there is a lot of work that goes into keeping that system update from a central team's point of view well beyond what needs to happen. And finally, there's the whole issue of cleaning up because there were a ton of resources that were being created with all this wonderful automation and they cost money, as the AWS guy knows very well. And so in order to understand how to solve the problem, a lot of the presentations I've seen here today mainly address the developer but we found it's only one piece of the puzzle. We have capability teams and at Intuit capability teams, we have a separate team that runs GitHub and a separate team that runs Jenkins and a separate team that specializes in performance. But really what they want is they want their resource used, used correctly, used by the developers, give them what they need and they run around to keep it operational. And whether it's one person doing it or at Intuit, a separate team, the one person may be running around spinning plates but it's still a capability team and that was, they had their own needs. The next piece that had to be taken into account is a paved road team. This is an Intuit term. I hope it will become more general. These are people that handle a specific type of resource such as a service, a web application, et cetera, et cetera, et cetera and want to propagate everything in their paved road off to a specific team. And then of course there's the product development team that wants to use the blueprints and wants to not worry about anything else and just push a button and there they go. And so we needed to develop what we called an asset life cycle management team and following the GitOps and everything else. We wanted it to be declarative, it important, retain what should be, get very GitOps, know what is so we could do the diff. We wanted it to be data-driven. We didn't want to have to build a workflow for every single pattern. That was getting unmanageable so quick you can't believe it. We wanted that the data for each one would be the true source of truth for Jenkins would be Jenkins, for Git would be Git, et cetera, et cetera, and yet from the point of view of somebody accessing the system it had to all operate as one. It had to support making changes after the fact and it had to be low no code for people that want to create patterns or for developers to consume. And it needed that all these different teams can work independently instead of having tons of meetings to coordinate with each other on every piece of work that had to be done. So what we did, we built this on Kubernetes but not using the Kubernetes infrastructure. We used GraphQL as federation, as the technique to assemble all these microservices. Each microservice acts as a controller. We used a bus to shuttle messages between them to allow all this occur, eventual consistency. And what the users ended up doing is they go to a UI which is set up by one of these paved road builders. That paved road builder then fills in this huge YAML document. I need two repos. I need this code. I need this. I need this. Everything, Splunk, indexes, certificates, anything, cloud resources, anything. They build it. That was the majority of it. One of the squares you'll look there and we have currently 25 different integrations that go into this to all the different resources is content. Our content system allows both this system to send either new code or send updates as PRs. It also allows through the UI to get a list of PRs available for PRs on demand, for example. Upgrade me from Java 8 to 11, which requires changes to the code, changes to the POM, or to Gradle build or into the Dockerfile, etc., etc. So all these automations, and they all use tools like Combi and Gradle and other tools, but they put it all together. So it's really simple to operate all of this. This is the UI that's used to see people accepting the PR and nudge them when that's needed, and some metrics about what happens. So currently we have an excess of 17,000 durable assets which are managed through this system and it grows on a regular basis. We have 15 active paved roads of which 12 were built through contribution in the company. We had nothing to do with them. We're managing 20, well it's now up to 25 microservices, that 12 were them and now it's even more contributed. This is our growth pattern and 65 engineers internally contributed to this, but we over the last three years only had 15 engineers ever working for us. So now what happened as a result of making it so easy that with a click of a button you can get this GitOps everything A through Z and if you need to add a database you go to the UI and you say add a database, you select and you connect or whatever it is, is two things. One, because it was easy, 50% of new resources being created live between one hour and one month and then they abandon it. The experimentation level has skyrocketed and innovation as measured by features pushed to production has gone up well over 100% it's actually gone up, I didn't want to put it down here but I'll say it, it's gone up over 400% and I checked that number several times with several people because it didn't seem likely but that's what happened. So that's a 10 minute quick story about there is no question and answer to a lightning talk. I'm at CubeCon all week and can be reached at this address. Thank you very much.