 Hello, everyone. So I'm here today to talk about these three folks. They're members of our EU team, Konstantin, Ramon, and Rubin. And they do a lot of really cool stuff. So when I was asked to, well, let me back up a second. They do a lot of real cool stuff like projects like Buck and such. And so they called me and they said, hey, Bill, we've been asked to present our hackathon project at CF Summit. I said, great. And then they showed me the project. And I said, great. And then they said, we need you to do a live demo on the keynote stage. And I said, great. But these folks are always pushing the limits. And they're always doing things a little outside the box. Here at the CF community, we really like poems and haikus. So I was thinking, how do I push the limits on stage today? And I thought, how about a Shakespearean sonnet, three noble heroes, ruling from the lands across the sea. Could not be with us this morning. But a tale to tell, they do possess. And I bring it forth, though I confess, for I am just the narrator. Of Romeo and Juliet, I'm sure that you have heard a tale of great tragedy. But Shakespeare, not one to leave us wanting. A sequel has been found. For you, our dear patrons, this tale is much less haunting. Two great households, the Diego's and the Kubernetes. A feud that predates memory, much to dismay of two young containers, for their sites were set on messaging. But how could such a note be passed without great effort made? Our heroes would not true love let die, for they will save the day. So what are we really talking about? We have our app workloads in Kubernetes running, I'm sorry, in Cloud Foundry running on Diego. And then we've got our containers running in Kubernetes. And it really would be nice if we could easily communicate back and forth between them. And there are a few ways to do this. But we wanted something, our EU folks wanted something simple. And ideally, they wouldn't really have to care, or at least the application wouldn't even be aware that the data it is looking for, the service it is trying to consume, isn't in Cloud Foundry itself, or in the same tenant, or at least right next door. So in this case, they did some research and said, OK, well, Diego uses the Silk CNI, the container networking interface. And Kubernetes uses something called Flannel, at least in this case for CFCR, Kubernetes was using Flannel. They said, well, what if we just swap out Flannel for Silk? How well would that work? And with a little effort and some fighting, they found out that it was actually quite usable. And we end up with a nice happy story. They mostly took the configuration right out of the Silk configs inside of the Diego configuration and swapped it into Kubernetes. We've got a nice long technical blog post about it in three stories. And they're demoing a fairly working idea right now. And I'm going to go into the live demo. So this was live last Thursday. But it's fairly straightforward. So we have a Cloud Foundry running. And we're going to go check out an app running on Cloud Foundry called CFM. Let's grab its GUID. Then we're going to grab an IP. And then we're going to see that we have a MySQL service running on Kubernetes. Let's SSH into the app's container. And let's see if we can connect between the two. And it doesn't connect. There had to be an error in a live demo, right? So let's exit. Oh wait, we forgot to set the policy. So we set a policy so that they can communicate between one another. We'll SSH in once again. Try to connect. Success. That's all you're going to get from me today. So Constantine Rubin and Ramonov continued to work on this project. And we'll be putting out another blog post on it soon. You can see the whole series here. And all of them, as well as anyone on our team, would be happy to talk about this project. It's pretty interesting. Thank you.