 So my apologies, my colleague Justin was supposed to lead this conversation today. He got stuck with travel issues, so I'm pinch hitting today, so my apologies for the confusion. I am Ryan Garrett, I'm the head of sales engineering for Cortex. Today we're going to walk through just a kind of a quick evolution. What's that? What's that? Yeah, if you want to see if you can grab them, that would be great. We'll do a quick evolution of the DevOps and platform engineering, right? It's a big hot topic today. Platform engineering is something that we're seeing over and over again as we kind of speak at platform engineering day. We can kind of, you know, hop into this here. So when we think about the evolution of DevOps, right, we go back to DevOps 2009. We go back to Patrice and DevOps Day 2009 in Ghent, Belgium. We all think this is kind of the common history or the common backspot of DevOps. However, I think what we would like to think about is it's actually a little bit different than that. It actually goes back a little bit farther in time, and specifically it goes back to the idea of it's no longer the big beating the small, but actually the fast beating the slow. And if you think about the rise of Uber, the rise of Airbnb, they've challenged and completely upended industries. They've kind of done that just by doing, you know, being faster than everybody else, right? Being faster than those big hotel chains, being faster than those big traditional taxi industry. I would actually say that this goes back a little bit further, right? It goes back to the idea of, you know, what we'll call the ancient business wisdom of the 70s and 80s. Specifically, Dr. Eli Goldrott. So he wrote a book called The Goal. So Eli Goldrott was a physicist. He wrote a book called The Goal. Basically it was the idea of the goal was to be able to introduce the idea of the theory of constraints, right? Theory of constraints to a business. So it was a fictional account of a VP coming in, VP of engineering and a change agent coming in and being able to, you know, dramatically change the business, right? Our modern take on that is actually what we would call the Phoenix Project. Sorry? Yeah, sorry. This thing is not reading the slides here properly. So my apologies, folks. We'll just talk through it. So the more modern adaptation of that is the Phoenix Project. We're all familiar with the Phoenix Project. We've read the Phoenix Project. The idea there is, you know, adding the theory of constraints to a business. So if we think about the evolution of that, right, is the idea of adding the concept of throughput, inventory, and cost and applying that to the software model. So throughput is, you know, money. Inventory is your code. And organizational cost is the cost of doing business. It's the cost of writing code, deploying software. So within, you apply that to a business. It becomes challenging to kind of keep up with the pace of business, right? So we think about kind of DevOps, right? We want to keep up. We want to go fast. There's also this challenge of what's called entropy, right? Entropy, if we're not moving forward, we're staying still, right? We're falling behind. Same is true for your software. If you're not evolving your software, you're staying behind. And so when we apply this back to the DevOps mentality, being able to, you know, and the theory of constraints, really the only thing that is going to be able to drive forward is initiatives that positively impact long-term performance are the ones that increase throughput and simultaneously decrease in cost. So if you think about, you know, when we evolved DevOps, we're now talking about platform engineering, the key thing of this is how do we not just do things faster, do things cheaper, but deliver innovation that we've never been able to deliver before. This is led, and if I have a lovely slide here, imagine the DevOps continuum, so this has led to the DevOps continuum, you know, where we've really tried to optimize the cost throughout that DevOps lifecycle, basically being able to shorten the lifecycle between delivering code and transforming that into money for the business, right? I'll say that again. We want to shorten the lifecycle between delivering code and transforming that to money to the business. Now, also if you'd see here, there would be a lovely slide with all of those logos, many of those represented here today. When we've done this, there you go. When we've done this, we've actually now created an additional degree of complexity. We've now kind of spun things up into multiple tools. We've spun things up into many microservices, right? And we're now managing, manually managing those microservices across multiple parts of the platform. Now, this has really changed how we've delivered code, right? So now we have to think about ultra portability with code. We have to think about not just running that and kicking that code and deploying it once. We have to think about delivering that code and delivering that in small little bits. We have to think about putting that in cloud. We have to think about that being super portable, kicking it into Kubernetes, right? Busting it up in all kinds of different little bits. We've created a framework around that called the 12 factor, right? 12 factors actually being able to talk about the portable design of that code, right? So being able to think about a single repository of truth, your Git, your logs, your event streams, et cetera. The challenge with that is we've actually not simplified things. We've actually made things more complex. We've actually created a challenge for our own developers, right? So now what we're seeing is the challenge is actually in developer productivity. What used to be really easy to manage, we had one application. We knew where it ran. Now it becomes really, really complex. It's now hundreds of microservices, multiple different places, on-prem, cloud, multiple different tools. And this creates a challenge that's fairly unique. And a lot of times we fall back to this idea of like, let's manage it with spreadsheets. Let's take all that data. We've got out of where all those tools, let's manage it with spreadsheets. Let's track it with spreadsheets and be able to run our business that way. Now this has led to the rise of what we're calling platform engineering, right? How do we simplify the process of actually driving efficiencies in that code delivery method? How do we actually drive efficiencies and take those... And take the efficiencies out of the code and going back to that theory of constraints. Shorten that cycle between code and delivering money for the business. Now if we think about the platform engineering space, it really is this kind of clean sheet of paper on how to approach this problem. How can we change? How can we evolve that? How can we reduce the time it takes between code and delivering money to the business? And so we at Cortex, we've taken a unique approach to that. So if you want to stop by our booth, we're happy to kind of walk you through how we think about this. Thank you very much.