 I want to spend just a few moments showing you what Istio can do. Istio being service mesh technology that sits on top of Kubernetes and on top of OpenShift. Here is my developer console, and you can see I have a preference customer recommendation. So I have three microservices. Customer calls preference, preference calls recommendation. So if you think of that set of services, they have to all work together to respond to a certain user request. So service mesh really helps you in a microservices architecture. In this case in my OpenShift console, I'm going to come back to the administrator view though and take you into operators and installed operators where I've installed a certain set of capabilities. In this case, I've got Elasticsearch here because Yeager relies on Elasticsearch. I have Yeager, which is my tracing capability. So one of the key components of Istio is the ability to trace transactions through your different microservices. And I have Keali, which gives me a really nice graphical console for viewing all that content. And then I have the OpenShift service mesh, which were where I have installed Istio control plane. And I've also identified the member role. So that's an important thing to understand about Istio on top of OpenShift. It is a little bit different because it's multi-tenant by default. So if I come here to Istio system, this is normally where Istio goes and it's Istio system. And if I look at my Istio service mesh role, you'll see I have a service mesh role here. Let's look at the YAML. And basically these are the namespaces that are gonna be monitored. So with these namespaces, I will get the automatic sidecar injection. So that's really the key thing to understand. If you don't do it this way, then you have to figure out how to get the sidecar injected on your own. With this, I can just simply do normal deployments. And with that normal deployment, I get the sidecar. So I have a namespace called one, namespace called tutorial. That's the namespace that we'll be worrying about here. If I actually come to my command line though, if I say qctrl get pods in Istio system, you'll see this is the Istio infrastructure all running here. Your typical things like pilot policy, sidecar injector, telemetry, all those things you normally expect from an Istio infrastructure standpoint are in the Istio system. The extra magic here is this concept of specifying for this particular control plane for Istio, which namespaces is it going to monitor? And again, this allows you for a multi-tenant architecture on top of OpenShift. So that's a little bit unique from an OpenShift standpoint. Let me go back to my project. Let's go to the tutorial project. There we go. This is based on the Istio tutorial we've published. If I come here now and look at workloads and pods, you'll see there's my three pods. Again, customer calls preference, preference calls recommendation. I have three deployments, customer preference and recommendation. Standard stuff here. I have three services as well. Now let's go to networking and services. So you'll see my customer preference and recommendation. Normal stuff from the perspective of a typical application. Now we introduce the service mesh. All right, so how do you know the service mesh is on board? You'll see the two slash two there. That means Envoy, the sidecar was added to it. If I do something as simple as describe this pod, OC describe pod and look into it. And I could use Qctrl or OC. Those are interchangeable command line tools. OC being a superset. But you can kind of see there's the Istio Envoy configuration. If we look right here, there's additional Istio comments. So these things were injected by the sidecar injector. So again, if you enlist your namespace in the service mesh role, you'll get the sidecar injection automatically. And you can kind of see here's the sidecar set up here, right? There's Envoy, the binary path is Envoy. Whereas it's Pilot. You know, all the standard stuff from Istio from that perspective. Even though it says Zipkin here, it's actually using Yeager for the tracing capability. Okay? The Zipkin address is kind of just a hold over from the very beginnings of the early days of Istio, which I think is funny. Now, I have my application here. And if I basically say Qctrl get services, you'll see there is the customer preference recommendation. And again, that's the order in which they're invoked. But what we have to do is invoke the Istio based application through its gateway. All right? So the gateway is an important aspect of it. And actually I'm gonna come back over here and pull the gateway information out of the Istio tutorial. So let me double check that. You know, cause you gotta know how to find that gateway. And the gateway, by the way, is in get services, is in Istio system. That's how you'll find it. And you'll see this different services here. Did I say services? Yep, services. The Istio ingress gateway. All right? The inbound, not the outbound, that's egress. So ingress in this case. So knowing what that gateway is is important. And then you'll have to just figure out how to get a hold of its URL. So if I come over here, in our tutorial, we'll show you how to do that. Okay? So there's this export command, gateway URL. It's gonna get the route from the Istio ingress gateway in the Istio system. And it's gonna pull out the spec host. If I hit return there, I can say echo gateway URL. You can see there it is. So that's the gateway URL. That is the public internet endpoint for the gateway that allows you access through this Istio system. Again, this is somewhat unique because of Istio. They wanna basically start applying a service mesh up on the gateway level. And if I do a curl of this gateway, and slash customer, because we gotta know exactly what we're gonna talk to here, slash customer, there it is. So it's customer preference recommendation v1. And of course the pod identifier coming from that one right there. So that's the pod identifier telling us who is responding. And of course a little numeric incrementer just to say that hit counted as once. If I say curl again, 117. If I say curl again, 118. All right, let's just kinda make a little loop here. Make a little bit more interesting, do. And then we'll do the same curl command as before. Let's copy and paste that one in. Copy and paste. And let's sleep for a little bit and then done. All right, so there's our little curl. And you can see it's recommendation v1. So customer preference recommendation v1. Okay, most of this is standard setup. In other words, nothing Istio magic at this point, really, you do see that two by two. So let's kinda show you some Istio magic. The first thing I wanna do is deploy another recommendation. So let's say we have a blue-green deployment or canary deployment style model. We can actually adjust the traffic to recommendation v1 versus v2. So let's deploy v2. So I'm gonna say qctl apply-f and we're gonna go into recommendation directory and q files, Kubernetes files. And let's call it deployment v2 yaml. There we go. Standard deployment, nothing unusual about it. But because we have the automatic sidecar injection, you'll see the two by two there, two slash two. It's uploading that v2 now. And you'll notice that our load balancer will go v1, v2, v1, v2. And that is the default behavior you see in Kubernetes, right? Open shift Kubernetes, the service load balancer automatically does round robin load balancing. And you can see v1, v2, v1, v2. Now here's where it gets fun. We have a couple of different things here. So if the qctl gets CRDs and grep and Istio, again, custom resource definitions, extend the behavior of my Kubernetes cluster. And one of those things is called a destination rule, destination rules, and one of those things is called a virtual service. Those are the things you primarily will be working with. You need the destination rule and you need the service. And let me go ahead and just pick again, these out of the actual Kubernetes tutorial. So let's see here. I'm gonna grab this command and paste it in. So right here, we're gonna say kubectl create-f Istio files, destination rule recommendation v1 and v2, and this is your all namespace. So that's gonna give me my dr. So I'm gonna say kubectl get dr. There's my destination rule. You notice the behavior has not changed at all because the actual rules for change are in their virtual service. So the destination rule simply sets up the targets. The actual virtual service sets up where it goes. So if I come here, and let's look at this file right here, there's my virtual service. This guy right here basically says send 100% of the traffic over to version two. Actually, I'll just go into raw mode here and select that and put that away. And we'll say kubectl create-f and we'll paste that one in. The file is also my local drive, but I'm gonna paste that in and you'll notice what happens right away. Our users are all going to be two now. So instead of v1, they're all going to be two. And if I wanted to, I could kinda say kubectl edit. Ooh, do I have my editor set up? I bet I do, I should set it up. Actually, let's actually do this, get vs. Okay, there's our recommendation. So kubectl edit vs recommendation. Let's do this, bring up my editor. This should be set to visual studio code and it's way over here in my other window. So we'll bring that over here and let's try this. We'll see where it says v200%. Let's go to v1 100%. So we'll basically edit that, okay? And we'll save and close. And now we should see our users going to v1. There they are, they're going to v1 now. So you can kinda go back and forth between how you wanna set this up, okay? Kinda show it to you one more time. Let's go over here to the kubectl replace-f istio files, virtual service, and we'll go recommendation v1, v2. Okay, let's do that. So this should flip us back to v2. So we showed you what that file looks like. Again, like most things in Kubernetes, you just have a simple yaml to make the adjustment. If I go back to v1, we'll see it go back to v1. So that's already kinda interesting. So your blue-green deployment is kinda supported for you there. Now, let's kinda look at an observability feature. Let's see here, which one of the things that makes Istio super interesting is of course you can use your standard. In the case of OpenShift, you have Grafana, Prometheus, and of course EFK, Elasticsearch, Logstash, Kibana. But there's a new observability tool called Kiali that's part of this. Here we go, Kiali of course is deployed as part of your OpenShift service mesh deployment. But Kiali lets you dig into this a little bit, right? So it's an upstream tool that we donated to the Istio project, and you can kinda do some specialized monitoring. So let's do the traffic annotation animation, I should say. So here's the traffic, all right, v1, v2. And here's why we care about this, all right? For one thing, we wanna know what our order of things are. Customer calls preference, preference calls recommendations. So now we see that, that's awesome. So you can see there's a Yeager collector here. This is Yeager metrics being captured here as far as the traces go, Kiali visualizing that force. There's lots of other cool things you can see from a Kiali standpoint, but what I really wanna show is this concept. Let's go back to, let's go to where, actually let's do this, Cube CTL, get VS. Let's actually wipe out that VS, delete VS recommendation. So we get the 50-50 load balancing again one more time. All right, so one, two, one, two, one, two. This is the part I wanna show you because this part is super cool. With the monitoring and observability capability, you can also have protection from failure out of the box, right? So you get a protection from failure, basically an automatic retry. So if I say Cube CTL, exec, IT, all right, bin bash. We have a little thing in here, a little command. It says, curl localhost 8080, we call it misbehave. And what it does is the code will misbehave and hopefully that's pretty obvious. It basically starts throwing out 503s, but watch what happens there. You automatically fail over from one to two. Now all our users are unimpacted by this. The user only sees V1 because V2 is literally acting up. Every transaction going through V2 is actually responding with a 503. There's something wrong in that code base. And the good news is you just did a fast blue-green deployment or canary deployment. It's out there in production, but it's misbehaving, but the user is unimpacted by that. And if we come back to our Keali console here and let it's still monitoring things, let's actually last minute, yeah, last minute, every 10 seconds, notice it's changing colors now. So even though our users are not seeing an error, we know there is an error because V2 is nice and red here. It's throwing out lots of errors and you kind of see that that's the information here. You can see preference is getting an orange because preference is automatically routing around the broken V2 and hitting V1, which is the correct one, all right, or at least a correct behaving one. But let's actually fix it so that it behaves now. So let's go back to behave mode. So it actually returns 200s. You can see now it's one, two, one, two again. So again, what the expected results were. And if we monitor it from a Keali standpoint, you will see it go back from red to orange to green as it realizes that, okay, things are behaving correctly again. So just a couple of key capabilities in the Istio LAN. Istio, of course, lets you do the traffic routing where you can do a percentage of traffic. I can actually route users based on their browser type or something else. So really nice traffic shifting capability, but the observability capabilities are one of the most popular features. Like let me be able to monitor my microservices architecture, see the traces, know the direction of the transactions, know where, where something might be misbehaving. But you can kind of see we can go back to green because all is good. And again, if I cause that failure one more time, you'll see it go back to orange and red so you can monitor the problem at hand. Again, lots of cool things in the Istio LAN, more things I could show you, but actually I'll work on another Istio demo for you and record it shortly, right? Thank you.