 All right, a quick introduction about me. If you missed this morning's keynote, is there a problem? Sorry, thank you. Oh, it's the speaker notes. Thank you for that reminder. Appreciate it. Sometimes we're nearsighted. All right, it's good. All right, thanks so much. Quick introduction about me. I'm a head of open source at Solar. I've been one of the founding member at the Israel community. I wrote two books. And I'm also a CNCF ambassador. Now I'm going to pass the mic to Ben to give a quick intro. Yeah, I'm Ben, Principal Engineer on the open source team with Lynn at Solayo. I've been doing Kubernetes for a long time and Istio for what seems like a really long time. And yeah, constantly learning. This has been fun stuff. Awesome, thanks Ben. And just a little bit introduction about our company because it's a small company. How many of you have actually heard of our company? Wow, thanks. You probably saw this too at, I guess, Chicago Airport. So that's all welcome. So thank you. So that's my boss, Eddie Lavigne. So we were for this small company. Today we're going to talk about Wazem landscape a little bit how Istio fits in, right? So we were working from the Istio project. We primarily are part of the embedded function of the Wazem landscape. So you can see Istio in there. I believe Envoy proxy is also in there. Kubernetes is also in there. So Knative is also in there. So that's a couple of surrounding projects related to what we are working on in a daily basis, part of the embedded function. So how many of you know what ServiceMesh is? All right, looks like most of you already know what ServiceMesh is. So in a nutshell, ServiceMesh is a programmable framework to allow you to observe, secure, connect micro services. And this is the ServiceMesh landscape by CNCF. You can see, I guess the biggest news is Istio is a CNCF graduated project. And ServiceMesh architecture, you're probably not surprising, it forms the cycle architecture, right? So the cycle does the magic to help you connect, secure, and observe your micro services. So you don't have to write code in your application to do that. So now I'm going to talk a little bit about ServiceMesh evolution. In 2017, interestingly enough, when LinkedIn won first launch, I believe it's at the KubeCon in Austin, it was the only KubeCon that has a little bit of snow, right? And they announced this project called ConDoIt that essentially proposing, you don't need cycle, why can't you just run the proxy per node? But LinkedIn soon find out the cycle architecture is more mature, it has more advantage around isolation, security, so they switch to the cycle model. If you look at the landscape of ServiceMesh, most of all the projects using on-way proxy as the cycle proxy, so on-way is pretty much the de facto standard for cycle proxy. Now I'm going to pass to Ben to talk a little bit about challenges with cycles. Yeah, and a lot of this stuff is going to be old news to some of you. Cycars have been a contentious topic from day one and we all know what the difficulty is with those, right? You have to actually inject layer seven slash layer four proxy into every workload pod to get all these benefits. That's expensive, right? That kind of increases the budget for each and every app you're going to deploy and it means you have to do things like restart the app to inject, you have to, you know, adopting a ServiceMesh is an expensive thing that requires you to recycle the applications you actually want to handle. And that's just a burden that people have been trying to get away from. So the idea is, hey, maybe we can get rid of some of this complexity, right? Maybe we can remove some of this burden here on the disruption and the burden on the workspace and the applications as well. And people talk of things like, you know, maybe we can do things like move this to user space or move this out of you, move this proxy information and functionality out of user space into kernel space, right? Stuff like security, stuff like policy enforcement. Can we do these things? Just get rid of the user space proxy entirely and do them all in EBPF. Unfortunately, it doesn't quite work because EBPF is not designed to do most of the things that a high level Layer 7 user space proxy can do. Stuff like encryption, just not gonna happen in EBPF. I've done EBPF, I've written EBPF modules. It's really not designed to handle that higher level stuff. Up to Layer 4? Sure. But Layer 7 stuff, it's just not really feasible to actually move all of that stuff out of user space into kernel space. So what can we do about sidecars, right? The difficulty of course with Envoy is, you know, tenancy and figuring out that issue for how to have tenancy, right? If you have a shared proxy, how do you avoid noisy neighbor? How do you avoid churn? How do you avoid all these issues that people have with a shared proxy between workloads? And there's been some research into this, but generally the way you wanna do it is by splitting functionality. All right, thanks Ben. So I'm gonna talk about slicing the layers, right? Because the Layer 7 proxy is not designed for multi-tenancy. So what we come up with the right architecture in the Istio community is slicing the secure overlay layer which is a Layer 3, Layer 4 into a separate layer than the Layer 7 processing layer. So as you can see, this allows us to have a secure overlay layer to be a per node proxy while you can have dedicated Layer 7 proxy for whatever tenant scope that you feel comfortable whether it's per name space or per service account. So in a nutshell, the secure overlay layer is very similar to the per node proxy where LinkD1.org was doing in 2017, but it's only handles the Layer 4 functionality where you potentially feel more comfortable to share with the other applications from different tenancy. So all it does is the Layer 4 here, basic security, mutual TLS tunneling, TCP metrics and logging, and also basic TCP routing. The Layer 7 processing layer, you get all the functions you see in the sidecar today. That's Layer 7, resiliency, traffic, shifting, canary, big upgrades, reach Layer 7 authorization policy, Layer 7 request telemetries, so all that function is a scope to your tenant scope which in this case is based on your application. So you don't have any noise neighbor problem, you don't have any cost attrition problem by having your dedicated Envoy proxy handles Layer 7. Istio, you guys all know Istio. By the way, how many of you are actually using Istio today? All right, how many of you heard of Istio Ambient Service Mesh? All right, very cool. So just a quick update in the community, we launched Ambient in 2022 and in the community we're working very hard to reach Ambient to beta right now. It's still in alpha status. We're trying to close a couple of key functions before we get to beta. Last year we launched Ambient and the founder of Envoy, which is a math client, said this is the right architecture going forward with the separation between Layer 4 and Layer 7 and be able to move in the sidecar outside of your application. So we did launch, this is our launch blog. As if you read the blog, Ambient is essentially focused on simplified operation, reduce cost and be able to improve performance for you. Now I want to show a little bit of progression of wasm in Istio. So when we started with Istio, we started with the mixer component and we were able to support wasm using Envoy filter resources and then we remove our mixer. If you guys know Istio well enough, we added support for wasm around time in the Istio proxy. We started with Solo, was talking about wasm deployment resource and that become a standardized resource with a lot of more work from the community become the wasm plugging resource and now the community is looking at adding wasm plugging resource to Istio Ambient service mesh. So a quick introduction of wasm plugging resource. How many of you actually use wasm plugging resource in Istio? All right, thanks a few of you. So it's actually really easy to use. It's declarative. So you can select which workload the wasm plugging is going to apply to. You can specify its faces, its images. You can set the environment variables. So all that configuration is available for you. What essentially works behind the scene is as a user you deploy wasm plugging resource and it's deployed to your Kubernetes cluster and Istio D monitors wasm plugging resources and pushes the configuration down to the Istio agent which typically runs alongside of your Istio proxy and that proxy could be your Psycop proxy and could be the Waypoint proxy that handles layer seven processing in Istio Ambient service mesh. And if the Istio agent doesn't have the wasm image it's going to go out to OCI registry to register the image and then provide config the proxy which is on way to execute the wasm image at the right time and window that's per your wasm plugging spec. So this is how the sequence work with one, two, three, four, five that I just described. Now a little bit more about wasm and Envoy. So Envoy has wasm extension natively built within Envoy. You can do basic configuration for wasm plugins through Envoy. You can configure your Envoy wasm VM which is runtime that V8 and you can also configure environment variable for your Envoy wasm VM. So that's all possible through Envoy configuration. With that we're going to show a quick demo and apologies because of my machine had some problem from the keynote early on so I couldn't do a live demo for my machine. So luckily I did get this recorded on Friday night before the trip. So what I'm showing is I have a simple project using assembly script. As you can see this project essentially does is adding a simple header. So in this add header commands class and method what we're going to do is we're going to say hello wasm day 2023 North America, KubeCon as part of the response, add this to the response headers. And I'm going to also run this, I'm going to build this, actually I already built this code using the right tool and it produced the wasm binary called optimized wasm and now I'm going to try to run this using Docker. So you can see my Docker compose file really simple. I'm using Envoy, Davy image of Envoy and I'm launching two volumes. One is my Envoy configuration, the other one is the wasm binary. So for the Envoy configuration you can see I have listener, I'm listening on 10,000, a set up of HTTP connection manager and all it does is it returns have a nice day in the body. So that's my HTTP connector filter. I also have a wasm filter which is my HTTP filter and in this wasm filter, I'm setting up runtime.v8 as my runtime and I'm adding a header which runs the optimized wasm file and last of the list I have a router filter which is required for the Envoy filter to be the last one. So as you can see, I'm running Docker compose to start my Envoy and now what I'm doing is I'm going to curl the local host 10,000 port and so you can see here is my hello wasm day 2023, North America, KubeCon. So that's my wasm binary gets executed and you can see have a nice day at the end too. So that's essentially in a nutshell of how Envoy can be work with wasm to execute our wasm runtime. Now I'm going to pass onto Ben to show a more exciting demo about how Envoy is still with ambient work with wasm. Yeah, well I hope it's more exciting because if it doesn't work since it's live we're gonna have problems but it's all good. All right, so let's see if I can. Hopefully this is visible. Can you? Yeah, sorry about that, I should have done that one. Okay, so first what I'm gonna do is I'm gonna try to actually install Istio in ambient mode. I'm gonna try to install it on top of an existing application, show that application works before and after then I'm gonna actually apply a wasm filter to change the behavior of the application without having to restart any of the application pods. So if we look at what I got in this cluster right now it's the standard Istio book info app. Now there's no Istio, there's no Istio namespace, none of Istio's installed, it's just a plain cluster with a couple of web services and I'm gonna go ahead and port forward this guy so we can get to it. And just to kinda show you if you've not seen it it's a simple bookstore app, a couple services, right, a front end app that calls a book info details service and a book info review service and then if you go to a particular page it shows you the details from the details microservice and the reviews and the reviews microservice standard stuff. Right, the interesting thing here is that we've got an Arthur SSN in the details and this is a problem because this is leaking PII and for some reason when we try to tell the team that operates this details app they're like, no, you can't restart it. You can't mess with that, it's a critical app and you can't touch it. So you're like, okay, what do we do? We still gotta do something here. All right, so what I'm gonna go ahead and do is I'm going to make sure I did the restart order. Yes, I'm gonna go ahead and so I've got book info already in there and I'm gonna go ahead and install Istio in ambient mode creating the namespace and just using this thing. Okay, so now we're going to sit here and hopefully this will be fast because I locally loaded the images. So we've installed in this cluster Istio now. So we have the existing book info stuff which has been there for 16 hours and then we've got Istio in ambient mode which is CNI on the agent, Z-Tunnel which is the layer four proxy and an Ingress Gateway and IstioD and that's about it. Now, what I'm gonna do here, can get to it, nope, wrong. What I can do here is I'm gonna go ahead and turn on ambient for that namespace. So all our book info stuff is deployed in default, the default namespace, right? It's all there. So I'm gonna go ahead and now ambient is, Istio is installed in ambient mode but it's not capturing anything yet because we haven't told it what namespaces we want it to start handling the networking for. So we're gonna do that with this label on the namespace of default. Okay, there we go. Now, I'm gonna go ahead and port for it again and we should make sure everything works correctly. Still, after we installed Istio and captured stuff. Do-do-do, all right, no user, all good. And just to prove that it actually worked, let's see if we can actually get some logs. Let's see what's in Istio system. System, yep, okay. And let's look, so these and these, all these, let's see, product page is on Worker 2. So let's look for the Z-tunnel in that node. Okay, which one is that one? That one's ZH, okay, two HH, okay. So we should see something in here. Yep, see there's 9080. So it's actually going through, the traffic is now going through the Z-tunnel after I installed Istio. And you'll notice that none of the app pods have restarted, right? So we went from nothing being captured and redirected through these node level proxies to they're being redirected. That's cool now. So what can we do about this SSN? All right, well, Z-tunnel is layer four. We want to do this at layer seven. We want to actually read the HP request and it redact this thing. It's kind of a monkey patch thing. So let's try that. So the first thing we're going to do is go ahead and apply a waypoint, which is a layer seven proxy. And what that's going to do is in the default namespace next to the workload, it's going to create an Envoy proxy, which is purely for layer seven and which is bound to the service account of the details app. And recall, details here is the one returning the SSN. So now that we've got that, it should be healthy. There it is. Okay, so now what I'm going to do is reload this page to make sure that actually, oh, I've got to reload it again, forward, forward. Now if I reload this page, we should see everything just as it did before. If I check the Envoy logs, you would see that it would be going through Envoy, but we're going to prove that more effectively here by going in and applying this Wasm plugin. Now this Wasm plugin essentially is just a tiny go app that detects VREGX, the SSN in the request body, and then blanks it out, okay? So I'm going to go ahead and apply that. And just to kind of show you what this Wasm plugin is, it is, again, the Wasm plugin resource that Lynn just talked about, it's pulling an OCI image from a repository. It's just going to actually redact that. Okay, so now if I go over here and refresh, whoop, oh, it redacted. Yeah, and just to kind of prove what I'm talking about here, again, go back, look at our actual app pods. None of them are restarted. Didn't have to touch them. I don't often have sidecars either. None of them have sidecars either, right. So we were able to take a Wasm plugin and actually apply it to something without touching it in a pretty effective way, right? Wasm plugins are not new. Envoy integration with Wasm is not new, but adding that to ambient gives you this ability to quickly do things like jump in there and change stuff without having to run afoul of, oh, I don't want to restart this app, right? I don't want to touch this app. It's much more lightweight, low touch. So yeah, that's it. Awesome, that was a super cool demo. One other thing I want to highlight during Ben's demo, as you can see, the waypoint proxy is optional, right? If you just come to Istio Ambient, you need a layer for functionality, you need mutual TLS, you need encryption, you need FIPS compliance, you don't need to deploy waypoint. However, since we're at Wasm, if you need layer seven processing, you could optionally deploy that. So that's super cool. To summarize, Istio supports Wasm natively with PsyCut today. Istio Ambient introduced a new data play mode to allow you to enroll your application into the service mesh without using PsyCuts. You no longer need to recycle your application parts, like Ben showed in the demo, right? There's no PsyCut running alongside of your application part. It's still possible using Ambient to support full future set of existing layers. Proxy, the differences, you run the waypoint proxy outside of your application part. And then what's super neat is you can inject layer seven Envoy Wasm plugin without touching the application part, right? So your application part can stay running. Well, Istio waypoint proxy executes your Wasm images for you within the V8 runtime within Envoy. So with that, I think we have a few minutes for questions. I want to thank you all for attending. And this is the QR code to get to our survey feedback. So if you guys have any questions, we'll be here for two minutes and we'll also stay around a little bit after the talk. First, a big thank you. Questions? I've got a question. This idea of service mesh is always really resonated with me because it's very similar to what I think WebAssembly is trying to do and pull complexity out of your apps and put it on a common rail. Are there plans to adopt the WebAssembly component model? I don't think there are currently in a concrete way, but I think that that's one of, actually I missed that talk earlier. I wanted to go to the component model talk for Wasm, but yeah, I think that's something that definitely as people use these things more, that's something to definitely look into because I think it's a market improvement over the status quo. Yeah, I agree with Ben. I think in our community, that's a new thing. We're trying to learn what it is and how does it apply to service mesh. But for now, I think getting the ambient out, be able to support Wasm within ambient is probably like the first thing we want to focus on and then look at the component model to see how it could potentially impact us. Yeah. That's great. That prompted some questions. Let's go. Great talk, thank you very much. So my question is like a little on the meta side of this. So effectively what you were doing here in this demo, in particular, you were hacking with an application really. So my question is, what is this authorized as an integral part of the application? How I can protect that integrity from somebody coming in, writing Wasm model and basically changing the way my application works? That's a great question. I mean, not everybody have authority to deploy resources like Wasm plugin resources, right? So you typically in Istio, any of the customer resources in Kubernetes, you can set access controls around it. So not everybody can go to a cluster to be able to do, like if you are able to deploy an application part, doesn't mean you can deploy a Wasm plugin resource to be able to targeting a particular application. And the other thing I would say, I believe these customer resources are only applicable within the current namespace you have access to. So if you have access to namespace A, doesn't mean you can deploy Wasm plugin resources to namespace B, and then selecting the application in the namespace. Yeah, and it is a contrived example, right? Just kind of show you visually what's happening. But like, yeah, Kubernetes has RBAC to prevent you from, to let anyone running the cluster set up, who can do what, who can change what, who can apply what to what workload. That's all built into Kubernetes that's existed for a while. This follows that paradigm. The other thing too is that since now that you can deploy Wasm images as OCI, that opens up much more robust things around like, you know, signing those artifacts and making sure that only signed images that actually mutate behavior are deployed in the cluster and being able to prove that kind of thing, right? Those are the, actually moving that stuff into the OCI layer is like a pluggable image. I think it really makes that a lot easier to control than it was before, where it was maybe just an engine X config floating somewhere, right? All right, thank you. Yeah, great question. Thank you. That's a good question. Who's next? Oh, there's a question there. Oh, sorry. So I saw you had a tiny go sort of program that you were compiling. What languages SDKs do you support? Do you have to build out these for everything you want people to be able to build in their language for? Or could you maybe talk a little bit about that? Yeah, I think the, I think the on voice support is pretty robust and pretty much anything that, you know, and rust all those sort of things, whatever is a standardized target. So any wasm binary that can be published as an OCI artifact should work, and any language that targets that should work. We've tried a few things, go is the most common one, but I think some of them they have tried rust. I don't know, but yeah, it's on voice implementation is pretty robust there and it shouldn't require any finagling if you're using a relatively good target. Yeah, we also have a assembly scripts version for the demo that we didn't show, but it's similar functionality, yeah. So maybe a follow-up question to that, and then I'll come to you in the green shirt here. If you had, if you published a wazze spec for this, then wouldn't you get your SDKs for free for all the languages? Yeah, that's probably true, something to look into, yeah. Awesome, here you go. Again, great demo. Can you tell me about a few ways we can troubleshoot a wazze plugin if we create one and we see if something's wrong, what's a good way to troubleshoot those plugins? That's a great question. I can take a step at it. Troubleshooting is actually not the easiest way because when I first tried this, it actually didn't work with Ambient. So I had to troubleshoot him by looking at the on-way configuration and think out what potentially goes wrong. And the other thing I did was I enabled the debug logs for Envoy and then try to think out like the stages we were trying to show in Istio, right? Which stage is failing? Like I have to think out does the binary, was the agent able to download the binary? Was the binary able to get executed in Envoy? Does the IstioD get the wazze plugin resource? Do I have the right access control and privilege to do things? Yeah, it's like different hops in here could be wrong. So I had to, like in the cases I was debugging, I think three and four had some problems. So I have to keep looking into that. I don't know if anyone want to add anything. Pretty much it, right? It's making sure the OCR artifact is actually pulled and pullable if that works. If Envoy says it did that by checking the logs, then at that point it's like, yeah, I burst around info like logs from the actual wazze plugin to see what it's doing. And yeah, where do we see the logs for the wazze plugin? Are they a part of the, are they a part of IstioD? It's part of the Istio proxy log. So if you're running Psyche, it would be part of the Psyche log. If you're running NBN, it would just be the waypoint proxies log. And then there are ways you can enable like debug version for them. But even without debug, you should be able to see some basic logs. I see. Thank you. Okay, time for maybe one more question. Right over there. Hold on. One question. So I think in here, the wazze plugin is running inside Envoy, right? I mean, in Abient Mesh, we also have that Z tunnel. Do we also have a design where the wazze is running Z tunnel maybe? Because that's where it's going to do layer 4 stuff, whereas this is more application stuff happening. Yeah, we don't have any plans. So if you look at this slicing the layers, right, the purpose of Z tunnel is to keep the secure overlay layer very, very minimum. So there is no intention to do any layer 7 processing in Z tunnel. So if you want to execute your wasm binary, you will have to deploy a waypoint proxy for that. And that design principle also allow us to scale Z tunnel to very, very big scale. Yeah, I hope that makes sense. There's no plans right now to do layer 7 is the only thing Envoy supports and only thing it supports processing for doing in layer 4 exclusively in Z tunnel is not planned. Because again, we want to keep it simple, but that could happen. That could work. Yes. All right. I think both presenters are available for questions afterwards. If you want to keep it going, please join me in thanking Lynn and Ben. Thanks everybody.