 Hi everybody. I think I am live. Yeah. So today I am so excited to be here and talk to you about ambient and particularly how we have been as a community making ambience so much simple since the initial launch of ambient which I believe was September 7th. We just had the ambient first birthday recently so very nice to meet you all here virtually. I wish could be in person but let's go. So for folks who don't know me my name is Lensa. I've been a very long time contributor to the Istio project since the very first day. I joined solo about two years ago. Right now I'm the head of the open source as solo working primarily on our open source contribution which the biggest contribution is the Istio project. So I've made a lot of contribution to the Istio project. I'm one of the founding TOC and steering committee member. I'm so fortunate still serving on the Istio TOC and steering at the moment. I wrote two books about Istio. My recent book is with Christian poster about Istio ambient explained. So if you're interested in Istio at ambient at very high level about how to get started what are the business value we're providing do check out that book. A little bit fun fact about me is I actually worked at IBM for a very very long time almost close to 20 years before I joined solo. So at my last day while I was at IBM I was of course super sad to living in such a wonderful workplace and a little fun fact about me is I do a lot of patenting and inventing while I was at IBM. So I went to the corporate directory which we call it blue page back there at one point and then I took a screenshot of how many patents I contribute to IBM. So that was 207 so that means I contribute that many numbers of patents to IBM corporation with me as the co-inventor. So a fantastic experience about writing these patent disclosures. So that's a little bit fun fact about me. Now I want to shift your attention to talk about ambient. So I mentioned September 7 last year we launched ambient as an Istio community. It was an extremely special day for us. We were able to introduce a new data plane mode for Istio without sidecar. So we wrote a great blog which a few of us are the co-author of the blog to introduce to everybody why we introduce ambient. What problem are we solving and what's the new architecture particularly with the layering of architecture of ambient. So if you haven't seen it I highly recommend you after the session check out this blog out there. So I won't spend a minute to talk about challenges with sidecars. Many of you actually already know so raise your hand if you feel like you already know all the challenges of the sidecars in the chat. I love to see that see if you agree with me. So the first is the operation challenging. You have to inject that sidecar. When you first deploy your application you're probably using Kubernetes you don't have that sidecar. So you have to inject that sidecar. And then what we're seeing in the community is you may also already have a sidecar container that's not on wave proxy. You may also have a unique container for your application pod. And we start to see there are sequence issues and most most likely life cycle management issues between your own unit container your own sidecar container that's different than what is your inject for you with the is your innate and is your sidecar proxy that may causing you some problems. And also as your application coming up and down there may be life cycle sequence issue between the is your proxy with your application pod. This is why exist a whole there is a parameter and annotation card hold application until proxy is ready. I remember I was driving for that in the is your community because a lot of our user was asking for it. And then the other thing is there's a lot of CVE comes with envoy proxy. So we tends to release a lot of CVE and ask you to restart your application to pick up the newer version of is your proxy. We don't support Kubernetes jobs. We don't support our server send first protocols. So these are the different challenges related to transparency of the cycle. And the other thing is incremental adoption. Right. Most of our users are actually using is your because they love mutual TLS right. They want to use is your to secure their communication between their applications. They want to rely on is your to manage the the certificates for their application pods in these simple scenarios when you just need is your for mutual TLS. Unfortunately, you still have to run is your proxy the entire cycle. Right. Because we don't have a simple version of the cycle to allow you just using the layer for function particularly mutual TLS function of the cycle. The third challenging with cycle I would say is the resources challenges. And we try to mediate that challenging with the introduction of cycle resource. You guys probably all see Carl Stonis tweet about when we first introduced cycle resourcing is your how it was helping his company to dramatically reduce CPU and RAM right for for the proxy and for is your day. We've also seen a lot of what we use a complaining about is your proxy cycle resources requirements was overly excessive. We've seen people complaining about remove that before resource limits for the cycle. So these are the different challenges with cycle that some of you. I know most of you are perfectly happy with the cycle. But some of you may you know hold back over adopting is still because of the cycle challenges we have. And that's exactly why we introduce is your ambient service mesh. So in a nutshell what is ambient service mesh. It's the new cyclist data plane mode that we introduced in Istio. What's really cool about it's your ambient is what's left thing the architecture into two layers the layer for layer that focus on providing a zero trust security tunnel for you. And then there's a layer seven layer if you do need a layer seven functionality from our service mesh then you can optionally deploy the waypoint proxy. And what's even exciting since the initial launch is Istio ambient service mesh started as an experimental branch and was merged in master in Istio 1.18 and remaining alpha in 1.19 and we're working really really hard to drive to the next phase which is beta. I can't tell you which release is going to be. If you want to find out more details I'd encourage you to join the ambient developer meeting because everything is changing rapidly with a lot of contributors collaborating on ambient. And then let me quickly summarize the key benefits of ambient right the first benefits which I think it's the most important benefit is simplified operations right ambient enables us to not needing to restart your application part as you enroll into ambient right as you you don't need to restart also for picking up a cve from either layer four or layer seven from ambient service mesh so that's super cool and the other thing is ambient is also designed to save cost for you right we talk about excessive provision resources of the cycle proxy right so that's what ambient is designed for and we have some preliminary numbers which I will share in a little bit about that and last but not least ambient is designed to improve performance for you particularly in the cases if you are only needing ambient for layer seven the zeal trust tunnel primarily for mutual tls and simple authorization policies. You guys are probably all familiar with this diagram and so essentially there are a z tunnel is deployed as a demon sets onto every single node of your kubernetes cluster and it manages the paths enrolled into ambient and it can manage multiple of them which is super cool so ambient mesh provide a shared per node z tunnel to provide a zeal trust tunnel if essentially z tunnel kind of assume the identity of the paths currently running on the same node and one thing I want to point out this is not super obvious to everybody is if you do have layer four policy on your paths that you want to enforce even if your client is in the same node the co-located z tunnel will continue to enforce the layer four policy for you so in this example c3 on the right side is the client and if it's trying to reach out the server one or two even though they are co-located the authorization policy for layer four will continue to be enforced for co-located paths just a little bit dive a little bit deeper into z tunnel architecture by the way this is a picture from the blog john that wrote about z tunnel so do check that out if you're interested in learning a little bit more about z tunnel so when z tunnel comes up z tunnel is serving as a xds client it's also serving as a ca client in this case z tunnel as a xds client would establish secure connection to is your d on 15012 and ask hey can I get my xds configuration and is your d will recognize oh you are a z tunnel instead of a cycle or instead of a waypoint proxy and this is your xds configuration and then and then z tunnel is going to act as a ca client and ask hey can you give me search for this particular application a or application x that i'm i'm managing on co-located on my node and then is your d is going to check oh are you really allowed to represent this particular application is this application a has pod that's co-located on your particular z tunnel's node it is if it's so then let me hand you off you know send you the search and means the search for you so that's uh essentially how the z tunnel architecture works so uh when we first uh designed z tunnel we actually started z tunnel with the pre-programmed envoy proxy and it wasn't the idea I remember back then uh about a year ago there was like three person on the team uh in the community can debugging the z tunnel configuration when z tunnel was written in envoy proxy it was uh super complicated uh with uh with z tunnel handling um configuration for multiple co-located application parts so we started thinking about you know how do we simplify uh the situation right so is your d it generates envoy configuration and sending this huge xds configuration only three people in the community can understand and um and envoy execute the configuration so uh if you guys don't know envoy is not meant for human it's really meant for machine uh this is a famous quote uh from yua one of my favorite co-worker um and also from rob salmon hey he gave a wonderful presentation in two years ago now uh talk about you know what envoy here's uh you know all these wonderful configurations of envoy the truth is uh the z tunnel envoy configuration back then when it was initially launched it's way more complicated than any of the envoy configurations in sci-car because of the fact that needs to have configuration for all the co-located parts so that made the team the community start to you know back to the drawing board about you know is envoy the right configuration for z tunnel you know what if we just send the necessary the absolutely the necessary configuration to the z tunnel without you know render it in the exact format that envoy needs that would allow us to save um a lot of money right because a lot of our user pay uh the network cost between the data plane to the control plane and also potentially um save memory and cpu um by sending way less data down so uh we start to think about as a community what is absolute necessary for the zero trust tunnel right so definitely it needs the co-located workload uh information right the name the parts uh the namespace the service account does it support edgeball you know what's the status what ip does it have or does it even have a waypoint proxy because z tunnel needs to think out where is the next hop it's sending so it's important you know whether it has the waypoint proxy also does it have any layer for policies for the workloads and you know what are the services uh they belong to so these are the it's uh absolute necessary information for z tunnel and that's actually not true well z tunnel needs to know not only the co-located workload it actually needs to have visibility into all the workloads uh regardless whether they are part of the ambient or not this is because uh a client uh here c1 or cq could potentially send in requests to any workloads right whether they are inside of the istio or whether they are inside of ambient uh that's completely reasonable allowed um all right so um so we start to think about you know what configuration z tunnel really needs right and that narrows down to the configuration protocol between z tunnel and the control plane istio d and this is the example rather simplified example of what the workload configuration looks like uh based on what z tunnel really needs and minimum needs and the protocol indicates whether it's tcp or edge ball so in the moment you add your workload uh through uh label namespace the istio io data plane ambience we are going to the control plane is going to flip the protocol into edge ball and send the updated configuration to z tunnel and if you have any policy particularly layer for policy apply to your workload istio d is going to associate your policy with that particular workload and also send the updated configuration uh down to z tunnel so with that this is uh results much simplified workload xds configuration that's so much simple to read and debug if you agree uh raise your hand in the chat somehow let me know you know the workload configuration compare with the on-way configuration you had to read in the past it's like 100x simplified in my opinion and it's so much less resource from istio d to generate the xds configuration for z tunnel and reduce the network cost right because some of you might pay for that between z tunnel and istio d all right um so the next question we start to ask in the community is uh what about z tunnel implementation now that we have a configuration protocol defined right so uh i believe john did a lot of work on this uh he had a prototype of a z tunnel written in goland and he also did the initial prototype of z tunnel written in rust and as a community we finally decided on rust due to its high performance low resource utilization and a very battle tested library and it can support work stealing in fact john actually did a uh a test a scale test recently where he set up ambient on very large scale hypothetically in a sense but with a large scale on that particular note z tunnel coming with just 500 megabit of ram so it's unbelievable so hopefully you see at this point you see how we really simplify z tunnel from implementation and also the configuration perspective right so now we're going to ship to talk about waypoint simplification a little bit right um so when we initially introduce waypoint uh waypoint was only on a service account sculpt so that's great um but um what if you your tenant scope is really namespace right i know a lot of users they are you know you desire tenant space is namespace instead of service account so we made a lot of simplification to waypoint also so that not only we support service account but also support namespace scope for waypoint so it depends on whichever you feel comfortable as a tenant scope for layer seven processing you can choose to use either waypoint sculpt for service account or namespace in order to deploy a waypoint proxy it's you can deploy it's really simple you use the experimental command to generate your kubernetes gateway resource or you can just create the resource yourself i would recommend you use the command to have an example and then tweak it as needed if if so so for example in this example it's super important to point out the gateway class name is it's your waypoint so so that's to let the gateway controller for the waypoint controller to know to deploy a waypoint instead of a deploy is your gateway right and then the listener is 15008 because that's support for edgebone so so the example here is deploy a waypoint that's namespace scope and if you want to have a service account sculpt waypoint you just add a simple annotation to tell us what the service account is for so one change we made is waypoint actually has its own service account now so it's super important to let us know what service account this is for just to help you a little bit more understanding waypoint architecture so this is a diagram from john and myself published your blog on waypoint so i do check out that blog if you're interested to know a little bit more about waypoint so in a nutshell when you create the gateway resource to deploy your waypoints using kubectl apply command it's your d is going to serve as the waypoint controller and then sees the gateway resource with the is your waypoint as the gateway class name and then it would automatically deploy the waypoint proxy for you based on the gateway resource and then your waypoint it's going to be very similar as the cycle except it's not running as a psychology application pod right it's it's going to have its own ca client it's going to have its own xds client it's going to have needing xds config from it's your d so it's going to first establish a secure connection to it's your d and ask hey can i get my certificate signed right because the waypoint as we mentioned it's going to have its own identity and and history is going to you know check the token and sign the search for waypoint and then the waypoint can begin to ask for xds configuration from is your control plane so that's a nutshell of how waypoint works now i want to start you telling you guys the story how we decided to why we started to looking at simplify the waypoint right so we started looking at how can we simplify waypoint configuration again back to the story there was maybe five person can understand waypoint config when we initially launched waypoint because it was super hard with i think there was like two internal listeners super complex config so we started looking into how we can simplify the waypoint config by should we apply export to annotation and cycle resource like cycle does right because you know every single waypoint they're not going to need reach out to every single other services and workloads in the cluster so maybe we could look into these configuration from user to give us a hint so just to get you familiar with the cycle configuration so typically you apply export to configuration right as a result from service producer you're going to reduce some of the configuration you'll see in this case you know the purple cycle and blue cycle from namespace two and then as a service consumer you typically apply the cycle resource which specify you know what are the egress connections you can reach out to in doing so you effectively reduce your configuration further right so if you apply that to namespace one and two essentially what you are essentially seeing is a simplified configuration where within your namespace waypoint you can only see what's deployed in your namespace for example in this case namespace one only sees the red and yellow so we start to think about you know do we ask user to add these configurations right but the reality is most of the user actually don't like you add these configurations right and creating cycle resources that's a hustle for user to learn so we decided you know what if we just introduce a destination only waypoint from a waypoint perspective it needs to only to know the end point the paths the workloads it's managed by that particular waypoint whether it's namespace or service account scope right so by introducing destination waypoint we are really able to simplify the waypoint configuration to focus on only the relevant paths and workloads that are relevant to the waypoint and what's the benefit to bring to our user is we eliminate the need for cycle and export to for waypoint right so you no longer needs to worry about those configurations I hope you like that give us a thumbs up in the chat if you do like that waypoint simplification so we also did a little bit calculation of a simple example of using cycle resource was using waypoint right the configuration what's coming down is waypoint has less than one percent of the configuration comparing with cycle using the same 25 deployments with 10 paths in the example so that's how much configuration we were able to reduce through this destination only waypoint the other thing about waypoint I want to highlight is policy enforcement for longest time Istio has server side source side policy and also destination side policies it's super confusing to our user and then they have to check out the logs on the source on the destination side to find out you know what's going wrong and they have to check the configuration also so with destination only waypoint we're having all the policy enforced on the destination regardless whether it's route policy or regardless whether it's authorization policy so it's so much easy for our user to understand read the logs and looking at the configuration just in one place it's also super important in a mixed environment whether you are running your client outside of the mesh or inside of the mesh when the policy is always on the server side so you are guaranteed to have the policy enforced which before when some of the policy on the client side that you'll be surprised why are they not working so this is the power of the destination only waypoint egress waypoint it's under construction so join us in the ambient dev channel and the ambient weekly meeting to learn a little bit more as we develop egress waypoint lots of not the least I want to quickly go over some of the resource savings study we've done with small scale with three deployments we've noticed 90% saving on layer four and 75% saving on layer four and layer seven we also increased the scale to a little bit more to 150 parts and we're seeing consistent savings so we do want to do more tests on thousands of parts and the even larger scale stay tuned for that you might be wondering what about cycle so cycle will continue to be support you can interrupt between cycle to pause in ambient so so there are maybe certain scenario you will continue to use cycle for now so I do want to show these scenarios to you I think I'm running out of time so I'm going to wrap up just the key takeaway for my talk is the ambient is the new data plane introduced in istio and zetano and waypoint we have been drastically simplified both of them since the initial launch and they are designed to scale with very minimal configuration with that I'm going to stop sharing and I will be taking questions if you have on the note on the on the chat box so do let me know if you enjoy my session or if you have any questions I will be there thank you all so much and try the ambient and give us feedback