 Thank you all for staying for coming. Oh my goodness. We're going to be delivering a live hands-on workshop on Istio's Ambient Mode or Ambient Mesh. If you have your laptops with you, we'll be going through, like I said, it's hands-on, it's instructor, us, lead, and you'll be given access to an environment that really, you have full reign and full control over the environment, but we're going to walk you through the steps of using Ambient Mesh and testing out various scenarios. So let's get going. My name is Christian Posta. I'm a global field CTO at a company called Solo.io. I've been involved with the Istio project since the spring of 2017 and written a number of books, including an Istio Ambient book that you can get at the Solo website. Lynn and I co-authored that. And I've been working with our customers, people in the community, adopting Istio for quite a long time, and some of those appointments are at really massive scale and criticality. All right. Good afternoon, everyone. I always appreciate a 430 crowd because you are really dedicated and because we're the only people standing between you and your evening activities. So thank you very much for being here. I'm Jim Barton. I'm a field engineer with Solo. And I've been working with Istio for a couple of years now, and I've been in the industry much longer than that. You can see that I actually had hair when I started this journey. So it's very good to be here with you this afternoon. Christian's going to give us some intro remarks to kind of set the context for Ambient Mesh. What I'd like for you to do, if you would like to follow along with us. What we're going to do is going to be up here on the screen, so don't feel like you have to pull out your laptop and follow along live. But if you would like to actually get your hands on Ambient Mesh itself in this environment, I encourage you to go ahead and get out your laptop, point your browser at academy.solo.io. Again, academy.solo.io. You will see a number of free courses that we have set up there. One of those which should be on the top line will be called Get Started with Istio Ambient Mesh. And so click through that. And if you have never been on our Solo Academy, our kind of instruct based workshop environment, you will need to register. Once you register, if you haven't already done that, then you should see an interface that looks something like this one. And the navigation you're looking for is the one that says Hands On Lab. So get to Hands On Lab, click through that, and that's going to take you to a screen that looks something like this one. And eventually you should get to where you have, once you see this, you can click on the Launch button there. That's actually going to provision an instruct environment for you with a kind cluster in there that we'll use to actually build out and test some ambient configuration. So go ahead and get started on that. Hit the Launch button and let that environment be provisioning. The really fun thing about this, if you enjoy live demos, you've seen a fair number of live demos today. So there's always a performance risk there. We have made our sacrifices to the demo gods today. And so hopefully adding a couple of orders of magnitude of people into our live demo won't create any issues. All right. Once we get to the end of the exercise here, you'll also have the option through that same workshop to do the Fundamentals for Istio Ambient Mesh Badge if you've been paying attention. And so we'll invite you to do that. That's completely free, and you can do that through the Solo Academy as well. All right. Christian, take it away. Yep. So while I'm going to introduce some of the basics and motivations for ambient mesh, probably some of you have seen this earlier. We've through some of the talks, but you can be provisioning your environments as well. And once I get through some of this intro material that will be ready to hit the ground rolling. So I'm certain you all have heard of Istio. This is the last session of the day. But we've been following Istio involved and working on Istio for quite a while. And at Solo, we've been following Istio for the last five or six years. And what we've seen is the market speak. We've seen it go from, well, it's this new technology to, hey, there's this huge landscape of different competing technologies to where we are today, where I believe Istio is the clear, far and away winner. It's deployed in the most organizations at the most scale and has the most mature functionality set. At Solo, like I said, we've been involved a lot of the original contributors to the project. The creator of Istio, Louis Ryan. They all work at Solo. You heard from Lan and Niraj on the TOC earlier in the Ask Me Anything session. And we recently also saw Istio get into the CNCF as a graduated project, fully graduated project. Actually, the person who wrote the PR to get Istio into the CNCF, Craig Box, has joined Solo as of today. So we have a number of the leaders and contributors, and we help drive the direction of the project. A big part of that direction you've probably been seeing or hearing throughout the day is Ambient. We originally started digging into Ambient and building what eventually became Ambient alongside Google in an effort to reduce the friction that it takes to adopt a service mesh and get the benefits and the business value of a service mesh. Running sidecars has some challenges. And how we work around or how we just kind of get rid of that completely and put this functionality into the network was a top goal. Improving things like cost and performance at the time was sort of an ancillary goal. But actually, when we talk with our users and folks that we're working with to get Ambient into production today, that is actually one of their top concerns is cost. I think we've seen some numbers loaded around. And our anecdotally, what we've seen is sidecar resource usage takes between 20% and 30% of resources to run in a cloud. And so cost reduction is a really big, important piece to adopting something like Ambient. Now, what we've done to kind of rearchitect Istio and solve for these problems and allow you to adopt the functionality at the layers that you need is to split the layers. So the number one use case for service mesh, which is workload identity, encryption, and zero trust, we split into its own layer, made it easier to adopt and implemented it in such a way that this component runs one agent per node as a daemon set, if you will, in Kubernetes. And in some ways, if you squint, it kind of starts to integrate and tie in with what the CNI is trying to do. And this component is called the ZTunnel. The ZTunnel is responsible for creating MTLS connections on behalf of applications, just like you see in the sidecar version of the service mesh today. Now, the service mesh provides a lot of capabilities. MTLS is one, telemetry and observability data, things like layer seven, traffic routing and load balancing. And we move that into another layer which we call the waypoint proxy layer that also sits in the network. It's not deployed with the applications. And when you need to take advantage and implement those capabilities of the service mesh, the ZTunnel will be smart enough to know to route traffic through one of these layer seven proxies, which is deployed one per identity, one per workload identity. So we don't get into this multi-tenant layer seven proxy business like we've seen in the past, or some service meshes are taking that path today. A diagram of a traffic flow between workloads that may not need layer seven capabilities and maybe want to start with just getting workload identity and mutual TLS looks like this, where traffic will flow from the workload through the ZTunnel, and the ZTunnel will take care of presenting certificates to the destination end and encrypting that traffic over a transport that is called, it's an HBS connect tunnel. I think if you go look in the docs, you'll see this referred to as an HTTP overlay network, or HTTP-based overlay network. Like I mentioned, the layer seven capabilities, the ZTunnel will be smart enough to know to send the traffic again over MTLS to the waypoint proxy, which can then implement things like traffic splitting or layer seven load balancing and the rest of the layer seven capabilities. You can see in this model that since there are no sidecars, it makes it easier to onboard the applications, makes it easier to upgrade the mesh itself. In the case of CVEs, for example, they need to be patched. You don't have to mess around with trying to coordinate with every single application because you're going to have to restart those applications in the sidecar mode. All right, very good. So I hope everyone's had a chance to, everyone who wants to follow along has had a chance to launch the environment. Here's some of the things we're going to be covering today. We'll obviously do some basic installation. We'll do some onboarding of services to the mesh with outside cars. Show you some level four authorization and observability features using primarily the ZTunnel. Then we'll expand that out to add some layer seven authorization and observability by adding the waypoint into the mix. Do a brief traffic shifting example, time permitting. And finally show you a frequent question we get is about interoperability between ambient with sidecar based services. And so we'll give you just a very quick opportunity to test that out for yourself as well. Okay. Real quick before you get going. Go ahead. If you all are going through the exercises here and you happen to run into some sort of issues or things aren't working as you're expected or as we said would happen. Then just raise your hand. We have a couple of folks here to help out. And I can jump in the crowd and help as well. Yep. So we do have some solo people sprinkled around the audience here. And they can just, yeah, just raise your hand and we will get, okay, we already have, see this is the fun of doing a collective demo. So, yeah, Alessandro, Nick, wherever you are. Yeah. Feel free to check in with those folks. Okay. Very good. So everything we're going to do here is in the instruct environment. Let's see. Do I need to, is that large enough for the back of the room? A little bigger, right? All right. Let's go with that. So this is an instruct based environment. So obviously on the left, you're looking at a, looking at command line that gives you access to this, to this cluster that we're going to spin up on the right. We have some commentary and some command, command blocks. What I would encourage you to do is if you, if you haven't used instruct before you'll notice in these little command blocks, there's a, there's a, there's a little box here in the top right. You can click on that. That's going to copy that content into your, into your copy paste buffer, which makes it, you know, pretty easy to go through this without, without a lot of errors. So feel free copy that, go over here to the left side, paste that in and that will run these command blocks for you. So the first thing we're going to do is we're going to establish a kind cluster using this, using the second script here, this deploy.sh script. So paste that in and kick that off. That'll take just a minute or two, to spin up. So we will get the, we'll get the kind cluster spun up there. Then we will run a check script just to make sure everything is, everything is good there. And a couple of the things that, that we'll be doing in this initial exercise, we are going to deploy Istio using, using ambient mode. Okay. We will deploy some, some fake services. And when I say fake services, I'm talking about services that actually use the, this, this fake service framework here. If you hasn't, haven't used that before, it's a really cool way to be able to test these sorts of, of, of inter service patterns that you want to be able to, you know, test routing and that sort of thing. So it may look like based on the names that we're building a full e-commerce system. We're not. We're simply going to, you know, string together some, some familiar names into a sequence of service invocations using this, using this fake service here. Where did we go? Very good. So once we, once we've done that, we will also, we'll also then expose that through using the, the, the newish gateway APIs from, from Kubernetes. And that will be our first exercise. So can some of you give me a thumbs up. You've able, able, been able to deploy those of you who are okay. All right. I got a few thumbs. That's good. So, so let's run this check script as well. That's just going to do a quick, quick sanity check on the environment here. So everything looks good in my world. We've got to, we've got our CUBE cluster up and running. We've got metal LB that we're using as our load balancer in this, in this little environment. So that all looks, looks solid. Okay. So let's go ahead and download the, the Istio release here. We're going to be using 1.9.3. This is actually a workshop was updated pretty freshly to what's that? I'm sorry. I said 1.9. Yeah. We're not using 1.9. We're using 1.19.3 and we will install that using the ambient profile right here. So go ahead and kick that off. And that's going to, you can see obviously it's going to install the, the Istio D control plane. It's going to install Z tunnel. You, you will notice that you do get Z tunnels deployed on a per node basis as a daemon set out of the box when you do this initial installation, you do not get any waypoints that are spun up initially. Basically that's going to wait for your configuration to determine right, even if waypoints are needed. We have a lot of customers at solo who come from financial services, other environments like public sector with where the primary, the primary requirement is, is security MTLS. And so in that case, you can actually deploy. You can more easily incrementally adopt Istio using ambient because you're only spinning up these lightweight Z tunnel components. You don't need your, you only need the waypoint component where you are doing layer seven policies and then only for the identities that are specifically using those policies. So it's, it's easier to, to, to spin this up incrementally and to do it with a lighter weight footprint. Okay. So we have, we've spun up, we've spun up Istio here with the, with the, the ambient profile. You take a look at the pods that are deployed. You can see initially it's pretty lightweight footprint, right? You can see the Istio D control plane. You can see the Z tunnel that's on this note here. And you can see a CNI node that's going to be watching for namespaces that are onboarded to ambient to then do the traffic redirect from those, from those services to their local Z tunnel instances. Okay. So that's all good. We're also going to go ahead and install the, the gateway CRDs. Those aren't there by default with, with most Kubernetes clusters. So let's go ahead and install those CRDs as well. That should take just, just a second. And then we're ready to actually to deploy our, our, our quote unquote workloads. So we're going to deploy these fake services as we talked about before. The specific configuration we're going to use is shown on this diagram. So we're going to have a, a client service here that's called the sleep service. It's going to talk to something called the web API. The web API is going to talk to a fake service called recommendation. Recommendation will talk to another fake service called, called purchase history. And that's what we're going to be working with as we configure the policies in this, in this ambient environment. Okay. So let's go ahead and deploy, deploy these. We'll create a name space, a test name space for these. We'll deploy these services and you can see on the, on the, on the left there, kind of a manifest of the, of the different services that we're creating at this point. We'll expand that out just a little bit as we get to some of the more advanced use cases, but for now this, this gives us all we need to, to get started. If you take a look at this test workspace that we've, that we've spun up here, you can see we have instances of the two client applications or the two client services we're going to use sleep and not sleep. And then also the three fake services that kind of represent our workloads of purchase history, recommendation and web API. You'll notice, of course, at this point, there are no, there are no, there are no envoy containers injected as side cars here, right? Everything is just, you know, we've got, we've got one container, which is the workload container. And even as we onboard with ambient, you're not going to see, you're not going to see that change. You know, nor are you going to see things like, you know, us having to restart these application workloads as we, you know, upgrade versions and, and that sort of thing. Okay. So let's test this out and make sure that our configuration works. So to do that, we're going to go to our client service and we're going to run a curl command to hit the web API. If you've ever used fake service before, you'll recognize what, what we're going to get back as a, as output here. So you can simply, you can configure a message for each of these fake service and you can also configure upstream calls for these fake services to make. So you can see web API is at the head of our chain here. We get back a little configuration message from it and then it makes an upstream call to this recommendation service, which has its own, its own configuration message. And then in turn it makes an upstream call to this purchase history service. So we have a, we have a chain of, of a, of a handful of service calls here that we can inject some Istio policy into and see how, how ambience is going to behave for us. Okay. Can I, can I get a thumbs up or some of you are able to get to this point with no issues? All right. Collective group demo. Love it. All right. Very good. So, so that's all good. And now what we're going to do, so we basically exercise that service from within the, from within the Kubernetes cluster itself. Now what we want to do is we're going to use the Kubernetes gateways API APIs to expose, to expose the service outside the cluster. So to do that we're going to, let me switch over here to this configuration tab. And you can see that we're going to establish a couple of, a couple of Kube components here. Again, this is, this is specifically using the new gateway API. So you can see we're establishing a gateway component. It's list, listening on this host is to explain.io at port 80. We're also establishing an HTTP route that's, that's attached to that same host and basically taking, taking a request that come in on any, any HTTP path. And we're going to forward that to this web API endpoint. So pretty, pretty simple basic, right? There's nothing that's ambience specific here. This is just using the, the web API config. All right. So we have exposed that have, no, we have not, but let's do that. So let's apply this config. All right. So we've created those two components. And let's get the, the gateway IP address into an environment variable here. And, and at this point, so with the gateway API, that should have spun up a, a gateway for us. And so now we can, we can hit that gateway endpoint. And when we do that, we'll see that we get exactly the same result as when we executed on the cluster that was already there inside, inside a Kube. So we get, you know, there's a web API talking to these, to these other services. So that's all behaving just as we expect. All right. So if you're able to follow along to this point, we're going to actually begin onboarding some of these services into ambient. And we'll take a look at some of the, the layer four policies and metrics that we can extract from this. Okay. So if you're, if you're at this point, go ahead and hit this check button down here. That's going to do a basic check in your environment and make sure that everything is in a good state to continue to the, to the second exercise. And here we're going to begin adding some services to ambient and looking at some of the layer four policies and metrics. So again, as before, hit the start button here. That's going to take you through to the beginning of this second exercise and, and give you a nice command prompt here. So what we're going to do to get started here, to, to onboard these test services into ambient, similar to, to, to what you do with, with Istio and Classic Mode, we're going to label this namespace only we're going to label it for, for ambient mode rather than sidecar injections. So we'll go ahead and enable that. And when we do that, if we get, we can actually get some hints that there are things going on. If we take a look at the Istio CNI demon set and take a look at the logs here, you can see there are some redirect rules that are being applied to ensure that the traffic from the services is going in and out of the, the Z tunnel. So our Z tunnel is up. It's working. We've got some traffic here. And so let's build, let's build. We're actually, the scenario is going to look something like this, where we have the client calling the Web API. If they're, if they're deployed on different nodes, that traffic is going to go through the Z tunnel that's specific to each node, which again is a very lightweight rust based proxy does not require a full up Envoy configuration until you want to apply some layer seven policies. So as long as we're operating here at, at layer four, then all we're going to need is a Z tunnel as shown in that diagram there. Okay. So let's, let's generate a little bit of traffic against our, against our deployment here. So we'll run, we'll run this script that's going to bounce a hundred calls off of our, off of our Web API. And in fact, if you take a look at the access logs from the Z tunnel, you can see that in fact it is, it is handling this traffic just as, just as we would expect it to. Okay. So there we go. So let's take a look at, now that we've, now that we've bounced some traffic off of, off of these services, let's take a look at some of the metrics. So obviously the metrics we're going to get are going to be split. You know, they're not all, this is not, this is not the traditional sidecar model. So we're not getting all of our metrics out of the sidecar proxies. We're going to get some layer four metrics out of the, out of the Z tunnel. And then later, later when we add in a waypoint, we'll see, you know, a different richer set of HTTP metrics that will come from the waypoint. So let's just take a look, you know, for example, you know Istio TCP cent bytes total might be one that you're interested in. And there you can see for each one of the source and destination pairings. All right. For example, here's, you know, this is a traffic between web API and the recommendation, the recommendation service. You can get a sense of, you know, what, what volume of traffic is, is going back and forth between those, between those two endpoints. Okay. Now let's take a look at specifying some of the, some policies here. We're going to start with policies that are just operating at layer four so that we can, so that we can implement those with just the, with just the Z tunnel. And so initially we're going to let's assume that we're all, we're all good, good engineers here. And we're going to start with a complete zero trust posture. So we're going to start with an authorization policy that's going to allow nothing. All right. And so this is what that policy looks like. Obviously very simple, nothing, nothing ambient specific here at all. But what's going to happen is the, the IstioD control plane is going to program the Z tunnels to implement this policy just like it would do in a traditional model with, with side cars. And so at this point, what do you expect to happen if we issue the same request that we did before? What do you think is going to happen? Well, the Z tunnel is going to intercept that. It's going to, it's going to drop those packets and you're going to see that the, the operation couldn't be, couldn't be completed there. Let me make this just a little bit bigger for everyone. Now what we're going to do is let's start to, let's start to green light the path that we actually want to be the acceptable path through these service invocations. So to do that, we're going to build a, a series of authorization policies. One that, that green lights each of the paths that we need in order for this, for this web API service to do its work. So we're going to establish here in this first one, we're going to establish access to the web API service. We're going to, we're going to define a couple of principles that we want to allow to call the service. One of them is our, our sleep client. The other one is the, is the, the API gateway. So that's good. Then we're going to have a second policy that's specific to the recommendation service. It's going to allow calls just from the web API. Right. So you can see we're establishing this path through our service network here. And then finally one for the purchase history, which is the final service in the chain that's going to allow invocations only from the recommendation service. Now let's, let's have a little fun here. So let's say we, let's say we green light just two of the, let's try again. Let's say we green light just two of these links in the path. What do you think's going to happen? Right. So let's, let's try that. Let's, let's not, is that what I'm after? That's what I'm after. If we green light just two of the services in this path, what do you expect's going to happen? Well, so you're going to see the first, the call the web API is going to be okay. It's going to make its upstream, its upstream call to, I believe to, to recommendation, which is going to be okay. But then it's going to fail on the third link in that chain. So if we, if we do the, if we do this call here, you can see that's exactly what happens, right? So the Z tunnel is successfully applying these policies, right? There's web API. That's good. It makes its upstream call to recommendation. That's good. But then when it tries to call purchase history, right, we haven't, we haven't green lit that link in the chain. And you can see that we get an error right here that actually fails the, the entire operation. Again, just as we expect. But if we go back and we green light everything in this authorization policy chain, then what we expect to happen is it should work without any problems. And in fact, that's exactly what we see. We get back 200 codes from the entire service chain. All right. So, and again, we're doing all of this. If you take a look at the, you take a look at the, all right, the pods we have deployed here, you'll note we're applying this all via standard Istio APIs. There's, you know, we haven't had to, you know, we haven't restarted any services. We've got a single container. There's no envoy proxies that are actually in the mix at all at this point. Okay. That's the, that's the end of the second exercise here. Can I get a couple of thumbs up? People still tracking. All right. Cool. Very good. So let's hit the check button again. And we will move on to the third exercise here. So the third exercise, we're actually going to start looking at layer seven. So we've introduced Z tunnel. We were managing some layer four policies. Now we're going to add layer seven into the mix. And so we're going to need to establish, actually we're going to end up establishing a couple of way point proxies to do, to do some different things here. So we're going to take a look at layer seven authorization, layer seven observability. And then we're going to throw in a little traffic shifting exercise at the end of this as well. So let's kick this off. So at this point, you'll recognize the top half of this diagram as being what we've already done, right? We've used the Z tunnel to implement layer four policies, generate layer four metrics. Now we're going to add a new use case. So to start with, it's going to be very simple. We're going to say for this service that we're going to allow get request to come into this web API service, but we're not going to allow any other HTTP operations. So no post, no puts, no deletes. And obviously that requires knowledge of the request at an HTTP level. And so to do that, we're going to need to move up to layer seven and establish a way point proxy. And we will deploy that just as a standard Kubernetes deployment. So let's get into that. So here we go. Again, we're going to use the Gateway API. And we're going to establish this for the web API service. All right. And so once we establish this way point for this gateway, Istio is actually going to spin this up for us. So it just takes a couple of seconds for that to happen. And then we can take a look and see that our way point has been deployed correctly. And there it is. So now this is just, you know, this is an envoy proxy, right? This is an envoy proxy that we've deployed that is going to manage layer seven policies and telemetry specifically for this web API identity, for this service account. All right. So we have our way point running here. And now we're going to take this authorization policy that we built before. And we're going to use it with one slight difference, right? If you check out the last few lines of the policy there, you can see we're restricting this. Whereas before we allowed anything, now we're going to restrict this to HTTP GET operations only. So let's go ahead and apply this policy. Now this policy is going to be pushed out to the, it's going to use the way point as part of that, as part of the enforcement point for this policy. So if we run the same operation we did before, right, that was using an HTTP GET through curl, right? We expect that to work just like it did before. That's good. But if we try to send a delete request instead, we expect to happen. Let's actually go ahead and add another option there. And there you can see we're getting back a 403 forbidden code. So in fact, the policy is working exactly as we expect. And again, just to reinforce, you take a look at this namespace here, and you can see there are no envoy proxies that are injected anywhere into these workloads. You can see, right, you can see that there is, there's Z-tunnel deployed on a per node basis, and you can also see there is this gateway, this waypoint proxy that's been deployed to implement the layer seven part of this. So everything's working exactly as we expect. Now, from an observability standpoint, obviously Envoy generates a whole raft of metrics at layer seven. We can take a look at just one of those here. So this is showing us the ICO request total metric here, and you can see it's looking from between a couple of these endpoints. Between the sleep service and the web API service, we've had one call there that was a 403 that failed, and then we've had another one between those two endpoints that generated a 200 that was successful. If we go back and we issue, let's do one more of these, let's actually issue another one of the bad requests here, all right, that's going to fail, and if we check the metrics again, check the metrics, we expect that the 403 count has incremented to two, and in fact that's exactly what we see there. So just confirming that the metrics are being generated exactly as we expect. Okay, a few minutes left here, let's take a look at a simple traffic shifting use case. So obviously canary deployments are something that are very commonly done with Istio to manage the migration from say version one of a workload to version two of a workload, and so let's take a look at how this could be implemented using an ambient framework. Again, from an API standpoint, there's really no change here. It's just from in terms of how this is carried out inside the Istio infrastructure, that's obviously going to be handled a little differently. So here we go, so we're going to create, for the purchase history service, we're going to create a second version of v2 of this service. There's already a v1 that's out there, and so if you take a look here, you can see that now we have a purchase history v1 and v2, neither of them have a sidecar injected, and what we're going to do, because we want to apply a layer seven policy at a different identity, so initially we applied policy at the web API identity, and now we're going to establish layer seven policy for this purchase history identity. We're going to set this up, we're going to manage this one using a separate waypoint that we're going to configure specifically for the purchase history identity. And so let's go ahead and we will apply that. Take just a second to spin that up, and yep, so now we have two waypoints deployed, one for web API, one for purchase history. We're going to make a small tweak to our authorization policy here for purchase history to point at the label generated for the purchase history waypoint, so that's just a small change. So we'll apply that. And then we're going to create a virtual service resource that actually configures the traffic shifting, so you can see 90% of the traffic we're going to send to V1 of our purchase history service, 10% we're going to send to this new V2 of the service. So let's go and apply that virtual service. We also need to establish a destination rule to associate the labels on the pods with the services themselves. So we're going to set up the V1 and V2 subsets here. So we'll do that with a destination rule. That's all good. And now at this point, so if we send 100 requests against this service, what do we expect to happen? Well, we would expect to see about 10 of them routed to the new V2 version. And in fact, we got 15, but obviously, law of large numbers, if we do it long enough, eventually it's going to average out to about 10%, which is exactly what we expect. Okay. All right, very good. So we still have a little bit of time left here. So let me go to the... There's one final bonus exercise I want to show you here at the end, kind of lead you through that. And the bonus exercise is responsive to one of the questions that I'd say we probably get most commonly from people who are considering adopting Ambient. And that is what happens if, you know, we already have a large Istio footprint based on traditional sidecar model, right? You know, we're not going to flip a switch and move to Ambient overnight across our entire fleet, which of course makes perfect sense. Will we be able to interoperate the two? Will we be able to interoperate between sidecar-based services and Ambient-based services? And so I'm going to show you just a very, very quick example of that here, and then hopefully have a few minutes left for questions. So let's start up this final exercise here. So we're going to establish a new service in our environment. So you've probably all heard of the HTTP-BIN service, which is handy for, you know, testing out HTTP calls and, you know, returning header information and all that good stuff. And so we're going to establish an HTTP-BIN service here in our cluster. Now, we're going to handle this one differently, right? Remember the first set of services we established in Ambient mode in this one, we're going to establish this workspace with traditional Istio injection. So we'll establish that. And then when we do that, we're going to spin up just a standard service deployment here in this workspace, all right? And in fact, if we take a look at the pods that are deployed, you can see very clearly the difference, right? So here's our first set of services. You can see they all have a single container, which is just the original workload. But if we look at this HTTP-BIN service, right, you can see that there are two. All right, so let's give it a second here. You can see there are two containers associated with this pod. One is the workload. The other one, obviously, is the Envoy proxy and Istio injected to mediate its traffic, okay? So what we would like to happen is, let's say we make a call from our sleep client pod, which is part of the ambient partition of the mesh, to this new HTTP-BIN service, which has a traditional sidecar model. And what you're going to see is, in fact, it works exactly as expected. We get an echo of the request headers and path and so forth. You can also see the B3 headers there that indicate that, in fact, Istio is in the mix here. It's injecting the trace headers that we can use to keep track of this. All right, and so that is our exercise. If you've made it this far, congratulations. Thank you for your participation in that. And let me just do one other thing here. All right, let's go back here. And if you'd like, there's also on that same academy workshop if you need something to put on your LinkedIn to prove to your manager that you've actually been at a conference this week. You can take this test and earn the fundamentals for ambient mesh badge, again, all completely free. And we encourage you to do that. If you are like me and you came here on a plane and you have a flight home, you'll need some reading material for that flight. Let me encourage you to grab Christian and Lynn's book, Istio Ambient Explained It. It does a great job of explaining all of this in about 90-minute plane ride, I'd say. And you can use that bit.ly link there or the QR code to get a copy of that and be your travel companion for your trip home. All right, hopefully everybody got that. Who wants it? I still see some phones up, so I'm going to give you another couple of seconds here. All right, very good. If you'd like to continue the conversation, there's going to be a lot more Istio and related content throughout KubeCon. I'm particularly excited about this one tomorrow at 5.30. Any session that has battle scars in the title, right, based on practical experience, that's one that's going to be interesting in wide representation from the community on that panel. So definitely we invite you to those sessions. We'll also have a booth solo will in the Solutions Showcase, booth D11, can't miss us. We would love to talk with you or, yeah, or we will also, if you have any questions now, if you want to make your way to the mic there. If you have any feedback for our session, we'd really appreciate that. We do a lot of these sorts of workshops on a variety of cloud-native application networking topics. So feel free to check out Solo Academy. Feel free to give us feedback. Let us know how we can improve. We would really very much appreciate that. All right, any questions we can answer? Christian, anything you want to add here? No, thank you all for staying this late. I do want to encourage, though, Istio Ambient Mesh is a sidecarless implementation of Istio. There are often questions about how does Istio compare to this other mesh or how does Ambient compare to this other mesh. Please come to the booth or come find us and we're happy to go into more detail. There are very good reasons why we specifically designed Ambient the way that we did. And there are very big differences in how we've implemented Ambient and how other sidecarless service meshes have been implemented. Come find us. We're happy to go into the detail and explain it. All right. Don't see any hands. Thank you very much. Appreciate your late afternoon time. Thank you.