 Thank you, Jim. So you've seen a lot of keynotes here today where people have talked about all kinds of interesting big ideas. I only have five minutes. So we're not doing that. What we're going to do right now is we're going to do something much more experimental. We're going to have a conversation. So really quick calibration exercise for those of you in the audience. Who here can raise their hand? That's much better than average. Usually it's only about 60%. So congratulations. So the topic that I'm here to talk about is actually the divide that we see between DevOps and the networking people. So really quick show of hands. Who here in the audience is a networking person? Who here has opinions about routing protocols? Has run networks? Has built networks? Has been the guy whose head is on a plate if it doesn't work? OK, that's actually a much better than expected representation in this crowd. And who here thinks of themselves as DevOps? Builds apps, runs DevOps, does CICD, and is making the transition or has made the transition to cloud-native, microservices, et cetera. Excellent. Good. So I want to talk a little bit about history of the relationship between those two groups of people. So back in the good old days, we had servers. They didn't change much. There were a whole lot of them changing at once. You can sort of think of them as Dino, the pet dinosaur. And that worked relatively well. You knew you needed a server for your app. A couple of quarters ahead, you started lobbying for budgets. It gave you plenty of time to go talk to your networking people about subnets and getting those servers deployed. And the networking portion of your exercise was usually all about racking, stacking, networking. And it worked because nobody had to move all that fast. And there weren't that many things in motion. And of course, the world changes, and we move to VMs. We can sort of think of them as the apocryphal herd of cattle. Now, things moved a lot faster here. There were a lot more things in motion. And let's be honest, networking had some difficulty keeping up with the rate of change. And so what you saw emerge in that case was a lot of overlays over the network that was there. It was essentially pretending that we were still in the world of servers by compensating, by having the servers do overlays over the network that was being provided by networking. And now we're in the middle of another transition to microservices, to containers, to serverless. And I tend to think of this more as the human microbiome. There are more of them than there are of us. And things change here at an astonishing rate. And there are a huge number of them in motion. And the things that we did for VMs don't scale here. We can't deal with the kinds of problems and pain that we had playing games with overlays, smearing subnets across multiple servers. It just doesn't scale. And it ties you up in things as a developer that you don't want to know anything about. Quick show of hands for the DevOps people in the room. How many of you really want to think about subnets? That is a miraculous zero. I was thinking at least one of you would take perverse pleasure in understanding subnetting. OK, excellent. So I spent a lot of time thinking about where this divide originates. And a lot of it comes down to the fact that as networking people, we have really cool tools that we have spent a lot of time falling in love with. We have subnets, we have IPAM, we have ACLs, we have VPNs, we have load balancers. We have all these cool toys. And we would really love for you to love them too. But again, quick show of hands with the possible exception of load balancers, because they do things that you recognize. How many of you feel affection is DevOps people for these particular tools? And again, oh, wait, we have one. Thank you. Excellent. Oh, two, two. Excellent. But what's happening and what we're seeing emerge as we move to microservices is that we actually are dealing more at the level of concepts. These are the ideas that actually do something for you as an application developer. And there aren't nearly as many of them. And they're easier to wrap your head around. So the first one is reachability and isolation. So quick show of hands as DevOps people, how many of you care about your microservices either being able to reach your other microservices or be isolated from microservices who shouldn't be allowed to talk to them? Yeah, I think that's all the DevOps people in the room. So good, we have a concept that you care about. And the second one is service discovery and routing. Because these microservices are coming and going so quickly, you need some way to figure out where the hell the microservice you care about is and get the communications you need route into it from your other microservices and from the outside world. So again, quick show of hands, how many people in the DevOps world care about this? Care about service discovery and routing? Awesome. I was going to be very confused otherwise. Never a good thing when you're on stage. So the other thing that I find is there are often concepts that exist both in the networking world and in the DevOps world. But we have entirely different names for them. We think somewhat differently about them and so we talk straight past each other. So you guys care about service discovery and routing. On the networking side of the house, we figured out this style of problem as being something we cared about 15, 20 years ago. We call it identifier locator separation. And for us, because we usually are working at L3, we're usually working with IP addresses, it's the notion that you have an IP address that identifies something that you want to communicate with and a different IP address that allows you to locate it in the network because networks are vast and huge and finding things is trickier than you would think. And we have mechanisms for allowing us to take these identifiers and get them to the proper locators. So as I'm closing, because as I mentioned, I have five minutes, I'd like to continue this conversation somewhat. This is where we get to the really experimental part of today. So really quickly, when the networking people raise their hands again. Excellent. So DevOps people, look around the room. It's amazing how the hands all went down. Keep them up. Keep them up. So DevOps people, look around the room. Find a network person for after this keynote and go talk to them. Because here's the really interesting thing. Everything you build is completely uninteresting without the network. And these are the people who work day and night to make sure it stays up. It is ubiquitous for you. And for the networking people, the only reason we do what we do is to support the applications that US DevOps people are building in the network. And we need to be talking to each other more. The days of talking past each other, of overlaying over each other, of thinking we can continue to move forward with the same sorts of shiny baubles that we had on the networking side. Or that we can just ignore networking and just figure we have a single IP address on a single server we can count on and we'll figure everything else on the edge. They're coming to a close. Because it doesn't scale and it doesn't work. And what we have to do is come back to a hand in glove relationship. Much like what we had before, but at a much accelerated pace. Thank you very much.