 All right, this is a fun little demonstration. I want to show you the basics of blue-green and canary deployments to give you a feel for how those things work. And of course, this leverages Istio by Istio running on top of OpenShift in this case. So you can kind of see I have a bunch of browsers here. I have a regular desktop Chrome. I have a Chrome set for iPhone. I have a Chrome set for Android. And I have a Firefox as well. So they're all set to the blue deployment. And you can kind of see that I have a bunch of pods running here. There's blue pods, canary pods, green pods. But everybody is visiting the blue pods right now because I have a virtual service that basically says point everyone to blue, point everyone to blue. So let's actually point everyone to green. So if I come over here and say let's put everyone to green and hit return there, it's going to change that virtual service and everyone goes over to green. And so blue, green. If I want to come back and make everyone blue, again, it's very straightforward, make everyone blue. But this is where it gets really exciting to use Istio in this case because Istio, blue, green deployment, you could do that with regular Kubernetes or vanilla OpenShift, no big deal there. But when you can do a percentage or actually look at specific message headers, so let me bring up my Visual Studio code. And I want to show you this little bit of code right here. This is a virtual service that basically says send everybody in Android land. Everybody in Android land gets the canary. Everyone else gets the regular old vanilla green. I know it's a lot going on here, but that's basically what this says. Everybody in Android land goes to canary. Everyone else goes to green. So let's try to apply that one. That's called virtual service canary Android YAML. So let's make sure let's get that one right away. So virtual service canary Android. And so our Android users will go to canary. So that's the one right there, that third window, if you will. And then everyone else should go green. So let's see if we get that. We have our three greens and one yellow, all right? And you'll notice also the pod identifier changes. We're basically serving the pod name from the server side to the client side. That's what you see here. And also it has a different greeting, in this case, bonjour, all right? And so there's one user on the canary pod, the rest are on the green pods. And then if I come back now, let's try the, instead of Android, let's switch it to iPhone. I think I have iPhone one here. Yeah, let's go, let's, instead of Android users getting the canary, but iPhone users get the canary. So we're gonna switch it now to iPhone, all right? So iPhone gets the canary. But the whole point of this is where you can basically route traffic based on different types of parameters, whether it be as the user logged in or any kind of cookie, anything in the HTTP header can be used as a routing rule, including just raw percentages, where I can say just 10% of the users go to this one location or 100% goes to a different location. And then you can actually have a really nice advanced traffic shifting methodology, leveraging Istio to do blue, green and canary rollouts across your user base. And this makes macro services ever safer to deploy across a cluster, and in this case, across a large user base.