 Right, so with Kubernetes, the history is we started off with only file systems. Block is something very new within the past couple of releases that I actually personally worked on. The next piece that we're doing at Red Hat is leading the charge to create CRDs for object storage. So it's defining those APIs so customers can dynamically provision and manage their object storage with that. In addition, we recently acquired a company called Nuba that does exactly that. They're able to have that data mobility through object buckets across many clouds, doing the sharding and replication with the ability to dedupe. And that's super important because it opens up for our customers to have image streams, photos, things like that that they typically use within an enterprise and quickly move the data and copy it as they need to. So we noticed that more and more people want to try their workloads outside of the centralized, one centralized data cluster. So the big term for the last year was the hybrid cloud, but it's not just hybrid cloud. People coming also from the IoT user space wants to containerize their workloads, wants to put the processing closer and closer to the devices that are actually producing and consuming those data and the users. And there's a lot of use cases which should be tackled in that way. And as you all said previously, like Kubernetes won the developers' hearts and minds. So APIs are stable, everybody's using them. It will be supported for decades. So it's natural to try to bring all these tools and all these platforms that are already available to the developers try to tackle these new challenges. So that's why last year we formed the Kubernetes IoT Edge Working Group, trying to start with the simple questions because when people come to you and say, Edge, everybody thinks something different. For somebody, it's an IoT gateway. For somebody, it's a full blown Kubernetes cluster at some telco provider. So that's what we're trying to figure out all these things and try to form a community because as we saw in the previous also for the IoT user space is that complex problems like these are never basically solved by single company. You need open source, you need open standards, you need a community around it so that people can pick and choose and build a solution to fit their needs. Yeah, yeah, so I care a lot about diversity in tech and women in tech more specifically. One of the things that I feel like this community has a lot of very visible women. So when I actually looked at the number of contributors by men and women, I was really shocked to find out it was 3%. It's kind of disappointing when you think about it. It's 3% of all the contributors to all the projects in the CNCF. Exactly, if you look at the 36 projects, you look at the number of the people who've made issues, commits, comments, pull requests, it's 3% women and I think the CNCF has put a lot of effort into the, for example, the diversity scholarships. So bringing more than 300 people from underrepresented groups to KubeCon, including 56 here in Barcelona. And it has a personal meaning to me because I really got my start through that diversity scholarship to KubeCon Berlin two years ago. And when I first came to KubeCon Berlin, I knew nobody, but just that little first step can go a long way into getting people into feeling like they're part of the community and they have something valuable to give back. And then once you're in, you're hooked on it and yeah, then it's a lot of fun. I think the ecosystem may finally be ready for it. And this is, I feel like it's easy for us to look at examples of the past. People kind of shake their heads at OpenStack as a cautionary tale of sprawl and whatnot. But this is a thriving, which means growing, which means changing, which means very busy ecosystem. But like you're pointing out, if your enterprises are going to adopt some of this technology, they look at it and everyone here was eating cupcakes or whatever for the Kubernetes fifth birthday. To an enterprise, just because this got launched in 2014, okay, June 2014, that sounds kind of new. Like we're still running that mainframe that is still producing business value and actually that's fine. I mean, I think this maybe is one of the great things about a company like Microsoft is we are our customers. Like we also respect the fact that if something works, you don't just yolo a new thing out into production to replace it for what reason? What is the business value of replacing it? And I think for this, that's why this kind of Unix philosophy of the very modular pieces of this ecosystem, and we were talking about Helm a little earlier, but there's also draft, brigade, et cetera. Like the Porter, the CNAB spec implementation stuff and the cloud native application bundles, which that's a whole mouthful. One of the things I like, I've got a long history in open source too, is if there are things that aren't perfect or things that are maturing, a lot of times we're talking about them in public because there is a roadmap and people are working on it and we can all go to the repositories and see where people are complaining. So at a show like this, I feel like we do have some level of transparency and we can actually have realism here. I don't think we hear that as much anymore because there is no more barrier to getting the technology. It's no longer, I get this technology from vendor A and I wish somebody else would support the standard. It's like, I can get it if I want it. I think the companies that we typically have aren't about features anymore. They're simply, my business is driven by software. That's the way I interact with my customer. That's the way I collect data from my customers, whatever that is. I need to do that faster and I need to teach my people to do that stuff. So the technology becomes secondary. Like I have this saying and it frustrates people sometimes but I'm like, there is not a CEO, a CIO, a CTO that you would talk to that wakes up and says, I have a Kubernetes problem. They all go, I have this business problem. I have that problem. It happens to be software. Kubernetes is a detail. Sure. I think the NSM is just a first step. So the network service mesh is basically doing a couple of things. One is it is simplifying networking so that the consumption paradigm is similar to what you've seen on the developer L7 layer. So if you think SSTO and how SSTO is changing the game in terms of how you consume layer seven services, think of bringing that down to the layer two, layer three layer as well. So the way a developer would discover services at the L7 layer is the same way we would want developers to discover networking endpoints or networking services or security capabilities. That's number one. So the language in which you consume needs to be simplified whereas it's whereby it becomes simple for a developer to consume. The second thing that I touched upon is we don't want developers to think about switches, routers, subnets, BGP, VXLAN, VLAN. For me, I want to dig a little bit more into the idea of multi-cloud. I've been making a bit of a stink for the past year with a talk called the myth of multi-cloud where it's not something I generally advise as a best practice. And I'm holding to that fairly well. But what I want to do is I want to have conversations with people who are pursuing multi-cloud strategies and figure out first, are they in fact pursuing that? The same thing that we're defining our terms and talking on the same page. And secondly, I want to get a little more context and insight into why they're doing that and what that looks like for them. Is it they want to be able to run different workloads in different places? Great, that's fair. The same workload run everywhere in the lowest common denominator. Well, let's scratch the surface a bit and find out why that is. Bob Wise and his team spend a ton of time working on the community and the whole team does, right? We're one of the biggest contributors to EtsyD. We're hosting Birds of the Feather. We've contributed back to a fair amount of community projects. And I think a lot of them are in fact around how to just make Kubernetes work better on AWS. And that might be something that we built because EKS or it might be something like Cluster Autoscaler, right? Which ultimately people would like to work better with auto scaling groups. So I think we have the community involvement but I think it's about having a quiet community involvement. That it's about chopping wood and carrying water and being present and committing and showing up and having experts and answering questions and being present in things like SIG groups than it is necessarily having the biggest boost. So Joe, tremendous progress in five years. Look forward for us a little bit. What does Kubernetes 2024 look like for us? Well, a lot of folks like to say that in five years Kubernetes is going to disappear. And sometimes they come at this from the sort of snarky angle. But other times I think it's going to disappear in terms of like it's going to be so boring, so solid, so assumed that people don't talk about it anymore. I mean, we're here at something that the CNCF is part of the Linux Foundation, which is great. But how often do people really focus on the Linux kernel these days? It is so boring, so solid, there's new stuff going on. But like clearly all the exciting stuff, all the action, all the innovation is happening at higher layers. And I think we're going to see something similar happen with Kubernetes over time. Exciting is being here. If you rewind five years and tell me I'm going to be in Barcelona with 7,500 of my best friends, I would think you were crazy or from Mars. This is amazing. And I thank everybody who's here who's made this thing possible. We have a ton of work to do. And if you feel like you can't figure out what you need to work on, come talk to me and we'll figure it out. Yeah, for me, I just want to give a big thank you to all the maintainers, folks like Tim, but also some other folks who you may not know their name, but they're the ones slogging it out and the GitHub PRQ trying to just make the project work and function day to day. And we're not for their ongoing efforts. We wouldn't have any of this.