 Hello everyone, my name is Christopher. I'm a software engineer at Kong and if you are an Envoy user and your sidecar is getting a little bit too heavy, by the end of the stock you'll know what to do with it. And if you are a service mesh vendor, you'll know how to prevent it. Okay, so how do we get high resource usage in Envoy anyway? So Envoy will usually be connected to a control plane and using XDS protocol. It will request resources and if you don't do anything fancy, usually what will happen is that Envoy will pull the state of the whole world. So everything that is happening in your mesh. So this is fine when you have just a couple of services but when you start running hundreds or even thousands of resources of services, then Envoy will pull all of that in every single request. And this can be really heavy on the CPU and memory and network usage. Okay, so what can we do about this? Well, microservices usually just talk to a couple of their neighbors. So what we can do is we can lie to Envoy and only tell it about those services. So in Kuma what we can do is we can use this setting called auto reachable services. And what that will do is combined with mesh traffic permissions, so policies that tell which service can talk to which service, this will trim the configuration and reduce the resource usage. In Istio there is a setting called sidecar.egress and that setting will tell the sidecar which services it should consume. And in console there is a setting called service intentions and this is pretty much the same as in Kuma. You define who can talk to whom and the configuration will be trimmed that way. Okay, but what about gateways or like utility services that talk to pretty much everything inside your mesh? So Envoy has different modes of exchanging resources. So we have the state of the world update that I mentioned but there is also Delta XDS. And in Delta XDS Envoy will only request the difference in resources from the previous request. So in Kuma service mesh you can use KDS Delta enabled setting. This only works for Kuma related resources for now but we're planning on releasing support for XDS resources as well. In Istio there is a setting called Istio Delta XDS that will enable it but it will only use the Delta XDS API. It doesn't actually send any data. And in console this is enabled by default so you don't have to do anything there. Okay, but can we do even more? Can we like get rid of the things that we don't need that are occupying memory. So yes Envoy introduced on-demand XDS which is another mode of exchanging resources and this is an HTTP filter that during a request will Envoy will ask the control plane for the configuration and then the request will continue normally. This only happens on the first request and then Envoy will track this service for some time and if you don't call this service again it will remove it from the memory thus freeing resources. Okay, so this is really good but this is not implemented in any of the meshes yet but it should be because this will greatly reduce the resource usage in this case. But you can play with a demo of on-demand XDS at my GitHub page. You can scan this code and there are other resources related to this topic as well. Thank you very much and have a great conference.