 Good morning, everybody. I'm glad to be here at KubeCon to talk to you as a representative of VMware. I work on a project called the Tanzu Application Platform. And it's our platform on top of Kubernetes as a platform, really oriented towards application developers. Now, I'll start by saying at VMware, operations teams are really important to us. It's in our DNA. Everybody knows who VMware is. And because we have this real close connection to the operations community, we've been really close partners as those groups have undergone a transformation. So we've always had sort of in the past this relationship where you have your delivery teams, people who are writing your business logic, delivering applications. And the way they interacted with their operations team was to basically throw some code over the wall. The operations team was responsible for care and feeding of all of these kinds of things, whether it was a middleware, whether it was the operating system, and the things that went along with that. But with the rise of new technologies, specifically containers and Kubernetes, the need for middleware, and specifically middleware managed by another team, has really decreased. So now, all of a sudden, developers are responsible for that. But by taking on that responsibility, they've also sort of gone through an expectational change. They have this expectation now that what they want is a self-service platform. They want to do more of this work themselves, rather than having to deal with an operations team. But that means that the operations teams are also often making the same kind of transitions. They need to make a self-service platform. And probably for the first time and the way many of them think, they have customers that they need to make happy. It's no longer, hey, somebody's just going to throw something to me. It's, hey, people want to use my platform. How can I do that for them? How can I have a product that's really good? And this is where I personally come in. My history is I've worked on application development frameworks for more than 20 years. In fact, the reason I'm here at VMware is because I came along with the spring acquisition. VMware is the steward of one of the most important software development frameworks. So we really have a good look at both sides. Hey, here's what an operation team wants to build for their customers. And here's what their customers are expecting them to build for them. And so along those lines, I have three things that if you are building one of these kinds of platforms, you should keep in mind that your application developers are thinking of. Number one, reduce complexity without sacrificing flexibility. As everybody else above me or before me has said, hey, look, this looks complex. I personally like the line right at the top where it says overwhelmed with a question mark, as if somebody doesn't think this is overwhelming. A lot of teams, when they attempt to sort of boil this down for their customers, pick a very thick set of things. You must use flux and build packs and gripe and Kubernetes. That's our stack. But you have to remember that all of your teams want a little bit of flexibility. Maybe they don't want to use flux. They want to use Argo. Maybe they want to use Conoco. Maybe they want to use Trivia or Sneak instead. And maybe they want to deploy into Knative. All of these things still need to be there. Customers don't want the full map, but they wouldn't mind a smaller selection instead. Number two, when you think about the shift left movement and sort of the DevSecOps world, we started in the sort of the old days. I'm obviously a Java person from way, way back. I remember the sort of we do source tests. We throw it over a wall. Occasionally somebody comes back to us and tells me something didn't work or we didn't meet some sort of requirement. We had these two separate teams that were divided where application developers knew a lot about their language and you had an operations team that was responsible for knowing all of the other technologies that went into it. As we went through this evolution, sort of the first generation of the shift left evolution, you saw a bunch of developers who really recognized the power of the shift left, making sure that they were doing things like signing and scanning and auditing early on. But what ended up happening was you ended up shifting all of the burden of knowing those technologies left as well. And so we need to make sure that as we deliver these platforms, we still keep that knowledge centralized, right? In an operations team who's sort of bread and butter is what does it mean to scan? What does it mean to sign images and attest to certain things? But still give the outcome to the developers themselves on the left side. And the final thing is that we need to make sure that we're ensuring the consistency and security are enterprise once from us or organization once from us, but without giving up the agility that it also wants from us. So all of us have, you know, at some point seen an internal footprint that looks a lot like this, Java developing or landing on Kubernetes, Go landing on Knative, maybe you're really exotic, you got some Python going on to Flink. Again, what you end up seeing is, hey, my enterprise really wants to ensure we've gone through a robust set of tests and we've done some test scanning, but they often go a little bit too far and say, hey, you also are gonna have to use this input language and deliver onto this platform. So when you're building a platform, you need to make sure that you identify clearly what's important, right? What the key things are, the testing and the scanning bit of it, while allowing the flexibility at the endpoints, right? What languages you're going to program in, what platforms you're going to deliver onto or what runtimes you're going to deliver into so that you still get the agility that the business needs while focusing on what its requirements are. So if you can sort of keep those three ideas in mind, I think you're well on your way towards building a successful platform that your application developers, users will love. Thank you for your time.