 Can you tell us a little bit about the roadmap for Envoy in the months ahead? Okay, so so I'm always really a community-driven project. So we don't have any like specific feature Roadmap saying like this will be landed in like 1.21 1.22 or anything like that Anyone are welcome to contribute to the project and to drive each features by their own. So We do have some roadmap for specific features like The two big area right now happening is the HTTP 3 support Google is heavily invested in that And another area is the WebAssembly extensions That was like Invested from a couple years ago now. It's in the still in the alpha stage it's because of the both the extension mechanism is in the in its early day and the WebAssembly Ecosystem is also in its early day We're trying to stabilize this make it more usable for you for our users. That's also driven by It's your community as well So we are as that way we have invested in that as well Thank you Have you guys done any like a performance testing for the wasm environment versus like a native C++ filter? So the that's a good good question. So the WebAssembly performance is like a very well-asked It really depends on the situation. I would say I do see if you have like very simple Filter that might be I think it's a half performance performance of the C++ stuff It's really depends on how you do that like if you have more like small string copies It really degrade the performance If you're just like doing some stats around the the traffic with a WebAssembly, it's not that bad And the glue code between WebAssembly and Envoy is not really well tuned like there's a lot of copy We just want to make it work. So yeah, those are things that could be improved in the future So it really depends on the on the use case I guess I have a follow-up question then For the the low-level ABI for Envoy, are you guys Are you guys going to use the wasm ABI as you're considered stable Internal ABI are you are you going to like finalize an internal design and then stick with that? So the the wasm ABI that Envoy interacts with WebAssembly modules called proxy wasm That's in like separate github project We're trying to stabilize that but I think the version right now is 0.1 or 0.2 I think so It will be stabilized over the time at this moment We don't it's not really stable right now because there's more use case We might change that to adopt a real use case. We don't we don't want to lock ourselves to some specific ABI Which is not used anywhere else so That's a current state, but we're trying to make that as stable as possible in the future, okay, cool because I just asked because I Asked a question in the Envoy slide yesterday about using like the C++ DLL kind of system For the dynamic like for example loading a filter instead of using wasm We could point to an external C++ plugin And then we might not have the negative performance effects, but I believe I think Matt mentioned something about Finalizing the stable ABI inside of Envoy before we ever get to that. Yeah, so I would say the current wasm ABI is still like Should be stable more stable than the what Envoy C++ filter API because we don't version that we don't do any have any back But back word compatibility assurance on that that can be changed anytime and The filters in the Envoy mainstream report if you use any API we do test on all of them So we do updates how they use those like filter API extension API But if you have your own in-house Once then when you upgrade Envoy you might need to change your code to adopt you like new version Like when Envoy have the filter API changes That should be like less likely if you use the web WebAssembly API to do the interaction with Envoy Cool. Thank you very much So questions from more of a user perspective Envoy has a very fast release Pipeline where the versions are released every quarter and after a year. They're usually deprecated For most companies when the main competitor engines is barely releasing anything There is a high toll here on maintenance and upgrading versions. Is there any thoughts done around this this issue? So your so the question is about the Envoy release cycle is very fast and it's hard to maintain over the time So So I think we we increase increase the supports cycle to One year right now every stable version have one one years supported for a secretific stuff so I think that's that's what that wasn't the case in like a couple years ago. We only support like Lat latest release and only master So, yeah there and we try to make the we have the compatibility policy about the deprecated like we only remove deprecated fielding In two radius We do have some sort of that are you saying that is still very high Yes, so Antique you might know it us as a company behind company Pokemon go Our clusters are there for over four years It's really hard for us to now go and deploy a new version with all the testing and everything and the guarantee that nothing will Break when you are deploying a new version versus the engines that we were using before that to be honest We haven't changed a version through all the life So the well the answer to that will be As a project we are also short of the resources to maintain older versions like over a year if So if there's a if you have resources or anyone else other comes you have resource Can like contribute and made a commitment to the project. So you're welcome to do so Like maintain older version more longer supported You can contact me or contact in the voice lag to make that proposal and have the Enough resources funded there. We can make it happen. But the reality is we don't have unlimited resource. So There's from project maintenance perspective. We don't have enough maintenance to keep the that support for like two years or like support more versions So, yeah, that's well something to think about even one stable version that Once for a year, it's good enough. Can I ask another question? Sure. So if you're asking for the So there's there's a like different like there's people asking for like People want a new feature to land it in a stable version faster So they they want the only one to deploy stable versions So it's I think it you don't have to really like upgrade to the latest stable version every quarter because the support cycle is It's one year. You can upgrade like every two versions and you still have some sort of compatibility Because we removed if we get a stuff we remove the API stability is more longer than one release So it's you can build your own strategy on that. Yeah, and I totally get it It's at least for a year back It's very important to have all the new updates of the new feature at all the great work that everybody is doing Another question is more around the go control plane So we do have a problem with go control planes release cycles not aligned with envoy release cycles For example, currently the last version from go control plane Produces a deprecated error because it wasn't update with the latest. Is there any thinking on aligning them? So it's kind of or a wish list and a question I must say So previously the The data plane and the actual server code in the control plane. We're all versioned together In the current months We're actually working on a release plan where the data plane and the code will be versioned separately And we will we are targeting a 1.0 shortly So hopefully those problems will no longer be an issue for people We've had a lot of requests to get that and we just haven't had the bandwidth to manage release cycles like that since it's such a small-scale project Yeah, no, definitely. Yeah, we are we are working to fix that Okay anyone else Let me check if I have any online questions If you haven't no more questions, so I can wrap up quickly. All right Well, thanks everybody for attending and yeah, please drop a review on the sketch app and enjoy the conference Thank you, everyone. Yeah, I'm still around if you want to ask me a question privately Welcome to do so. Thank you