 OK, for those that are there, we don't have any slides and we don't have any video. So the goal here is just to have an open Q&A with Harvey and myself. So I don't know, do you want us to give a brief intro, Harvey, of who you are? And then I can do the same. So I'm Harvey Tuch. I work at Google on my platforms. So I'm interested in taking Envoy and making it to that in our organization and also supporting Envoy as an open source project. I'm a senior maintainer. I've been heavily involved in Envoy in a number of areas, mostly around APIs, the FDS protocol, as well as security and some amounts of just basic infrastructure and so on. Matt. Thanks. My name is Matt Klein. I'm a software engineer at Lyft, where I started the Envoy proxy project about five and a half years ago and then led it through open source a bit over four years ago. And now I split my time about 50%, 60% of my time is open source work around Envoy and CNCF and the cloud native ecosystem. And then the other 50% of my time is infrastructure leadership at Lyft. So again, this is really an open-ended Q&A. So happy to talk about just about anything. So there's a Q&A box that's, I think, that you can answer questions or you can ask questions in. And we can wait for some questions and just go from there. So hopefully folks will have a question. Feel free to type away. I guess if we don't have any questions in a manner or two, we can cede it with some other questions. Let's see if there's. All right, first question. Are there any plans to introducing quick or HDP-3 support into Envoy? Would you like to take that? Herbie, or would you like me to? I think you're better off taking that one. I mean, I think the answer is yes. I think for me, I'm more afraid of the exact status of where we are, because we had a question that previous maintainers separate around the documentation and stability and examples. And I think that's what the community is really looking to actually understand right now. Sure. So obviously, quick and HDP-3, at least the IETF version, is still in the process of being ratified. I think it's very close. Quick obviously came out of Google, so Google has been using quick and production for quite some time. We're very fortunate with Envoy, where the team that shipped quick at Google also works on Envoy. And historically, the way that the code worked is it was part of the Chromium code base, so it was already open source. But in the interest of making it easier to consume in Chrome as well as Envoy, as well as other projects, it's been moved out to a different library called and there's a team of people that have been working on integrating that into Envoy for actually quite some time. I think they've been working on it for six or nine months. And I believe it's very close to an MVP. I think there are people that are actually standing it up now. And I think one of the maintainers, Greg, is actually working on it now, not at Google. So I think there are people that are pretty actively working on it. We don't have documentation yet, but the support is planned. It'll support the old Google Quick. It'll support the IATF Quick. Oops, sorry, my phone is beeping. But it will, you know. Could everyone mute themselves? Who's on the conference bridge? Yeah, I just closed mine. Maybe it wasn't mine. Anyhow, so it is coming. And I think that hopefully we'll have some documented support soon. So let's see. So next question is, are either of you involved in the Windows port of Envoy? Neither of us is really involved. Happy to give a brief status update there, but I'm not sure if that's something that you want to talk to you earlier if you want me to take that one too. Yeah, I think the Envoy, for the definitive sort of status, I recommend looking at watching the EnvoyCon 2020 talk on this and this is a lot on YouTube right now. I think we now have pretty significant progress there. It's sitting here. It's, most of the tests are actually passing. There's still a backlog of tests which need to pass. There's a bit of work being done on tooling and CI to make sure it's possible to actually make maintainable significant investment from VMware and Microsoft. I don't know if anyone's actually using it in production yet. Matt, have you? I think the answer is probably not because the current implementation because of the edge triggered versus level triggered situation that doesn't perform very well. So I think it is functionally complete, meaning it has all the features, but it does not perform well. And that's just related to how event triggering works within Windows and the team is working on that currently. So I think their goal is by the end of the year to have something that performs well for a beta version. All right, let's see. New to CNCF, what is Envoy? That's probably a good thing to cover. I don't know. You want to give like a 60 second overview, Harvey, of what is Envoy? Oh, I don't know. I mean, what's the picture on the website? Envoy is a cloud native service mesh proxy or something like that. But basically what I think of Envoy is actually is given a number of different respects. It provides some L4, L7 load balancing and proxying a data plane for this. It's a central component of many service meshes. So you'll see it as part of things like Istio. And also it's used in a number of just like very bespoke applications like, for example, building edge load balancers for very large organizations or cloud native companies. One thing I like to think about, the perspective I like to take of Envoy is it's really is a platform and it's what really distinguishes it from many of the other proxies and load balances in this space is its extensibility. It has both an extensible data plane with various extension points. And also a control plane built around open APIs. And these are the XPS protocol APIs and protocol that you may hear about in association with Envoy and things like Istio. And this is where one of the power of Envoy comes about in that it enables entire ecosystems of extensions and other components such as control planes and management servers to interoperate with it. So yeah, I don't know. I'm sure Matt, as the founder, you have a particular take as well, right? Sure, no. I think that was a great overview. I think what I typically say to this question is if you're looking for projects that it's most similar to, it's gonna be most similar to other software load balancers like Nginx and HAProxy. That's the most similar thing that you would compare it to. And Envoy has become very popular because of a bunch of the features around how it does configuration and extensibility and the community that we've built. But at the end of the day, it's a software load balancer. All right, let's see. Next question. I have a file access log question. I am currently using the file access log in my filter for a GRPC service and it's creating thousands of access logs per minute. Is there a way to limit that? Yes, there are various ways of limiting it. I would take a look at what Envoy calls runtime support, which basically allows you to do stable sampling. So you can sample access logs, I think, to one in a million or one in 10,000. And there's various filters that you can use to limit the log output. Mark that one answered. Let's see, answer answered live. And let's see. Next one. Let's see, what are your favorite or the most interesting uses of XDS Relay? I'll talk briefly and then I'll let Harvey talk also. So XDS Relay for those that don't know, it's basically an XDS caching proxy. So you could think of it as like varnish for XDS and a bunch of the problems that people have when they're trying to run Envoy or other XDS compliant proxies is it can be difficult to write control planes. It's just it's not super simple. So our goal with that project is to make it easier for people to write scalable control planes similar to how people frequently run CDNs in front of their HTTP origin servers. We believe that there's an opportunity to have a common caching layer that can offer distributed systems best practices around things like back pressure and rate limiting and all of those things. And then also more advanced functionality around things like subsetting or implementing incremental XDS and things like that. So the project is in early stages we're currently deploying it in production at Lyft right now and we're hoping to get more people involved but I'll let Harvey answer too because he's interested in all this API stuff. Yeah, I would definitely say one of the compelling use cases that I think is a pretty high priority in XDS Relay roadmap is this idea of bridging state-of-the-world updates which very relatively simple configuration pipelines and control planes can speak and dealing with the nuances around Delta and even on-demand XDS updates. I don't think that's like their immediate goal. I think the XDS protocol itself is actually starting to build in more capabilities and first class support for cashability as we go for scalability. And you can see this in things like I'm very recently at TTL was introduced which is pretty important from that perspective but also we have a new sort of URL based naming scheme inside XDS which will be capable of really modeling XDS resource names as cash keys and make things like XDS Relay that much easier to use and more effective. I think XDS Relay and things like this are going to be super important as we talk about scale out uses of XDS and areas when such as, for example, Edge XDS. So when things like Onboard Mobile adopts XDS which it doesn't today but as it does this kind of application of XDS Relay as well as other more traditional CDN kind of where methods are distributed in caching the caching resources will be I think pretty important. Yeah, I mean, I think it's kind of like a Swiss Army knife essentially of control playing capabilities which can be used for this fan out capability. That's the way I see it. Yeah. All right, next question. Is there a plan to incorporate latency based load balancing like Linker, Ds, EW, MA? I don't know of anyone that has been interested in implementing this so far. All of Envoy's load balancing systems are actually pluggable so it wouldn't be terribly hard for someone to implement this. We just need someone to come forward and do so. I think my experience with the latency based load balancing systems is that, you know, I mean they add a bunch of complexity and it's not clear that they add enough value to warrant the complexity but we would certainly be open to having those be implemented if there's people that would want to implement them. Let's see, next time. Any tips if I want or need to write a control plane for Envoy from scratch? I'll let Harvey take that one. Yeah, but I think you definitely almost certainly want to use something like go control playing or Java control playing as your basic transports like library for handling and obviously depends upon which language you intend to use to implement your control play. But this is essentially what many of the users in the community have converged around and there's a lot of code there for reuse that many of the hard lessons have been solved there. Another question obviously is like, you know, why do you want to build a control plane and there's many good reasons to building another control plane particularly when folks have, you know, in-house control planes for existing hardware or software load balancers in their adopting Envoy. But there is also a number of open source and commercial control plate offerings as a service. And so I'm just saying that full space is probably very important before, you know, embarking on this effort. But I would definitely start by taking a look at one of those libraries. Matt, do you have any other suggestions? No, I think I would just echo the same thing which is I would really not recommend writing a control plane from scratch at this point. I think between the API gateway solutions and the service mesh solutions that are out there, I would really recommend starting from something open source even if it requires it to be customized. Next question, where do you stand on the SPIR integration? I don't know really what that means. So if the person that asked that wants to clarify, I think when it comes to SPIFI and SPIR, Envoy doesn't really have any direct dependencies on things like Kubernetes or SPIFI and SPIR. It's a pretty generic solution, you know, that can interoperate with different certificate providers and different ways of specifying principles and RBAC rules and all of those things. So I think we're very open to obviously integrating with different authentication authorization providers and it's a pretty pluggable system. So I think we're open to it. I don't know, did you have anything to add there, Hermie? No, I don't think so. I mean, other than to point out that, yeah, as you pointed out, like as I mentioned before, you know, part of Envoy's extensibility extends to things like certificate providers and we have a recently added mechanism to sort of very flexibly add in additional sources of certificate providers. Right, next question. Are there interesting public overlaps using OpenAPI and Envoy? I can answer this. I'm not sure if this is something that you know about. Hermie, if you wanna answer this at all or do you want me to take this? So I think from an OpenAPI perspective, I'm not an expert. I don't think there are any explicit overlaps right now. What I will say is that Envoy does, I would say quite a lot already with API transcoding. So particularly around GRPC to JSON and things like that. And I think there's an entire ecosystem brewing particularly around Protobuf and GRPC APIs of how annotations can be added to APIs to allow them to be shared across different ecosystems. So whether that be something like Swagger or OpenAPI or GRPC and automatic conversion between GRPC and JSON and YAML. So I don't know that Envoy at least initially would be involved in this, but I do think that over time we're gonna see more convergence in how people define APIs. I think there'll be an increased movement towards IDL. And then I think as people move towards IDL, I believe that we can, one of the complaints against IDL based APIs is they tend to be harder to consume. Like it requires more tooling and a bit more expertise. And I think that Envoy can help bridge the gap between people that are, may potentially used to using curl based, REST APIs and how we can programmatically define them and then have them be more accessible to developers. So yeah, let's see. Let's see, we already talked about the Windows port. So I think that's ongoing. I'm thinking that they're gonna have something by the end of the year, hopefully that's beta ready. So hopefully it's already feature ready, but it's not production performance ready. So that will be coming. It's a question on how broad the adoption of remote mode is outside of land. So there's no one else using it so far that I know of. And to be clear with Envoy Mobile, we open sourced it really at the very beginning before there wasn't really anything. So it was developed in the open. So we are finishing our production rollout by the end of the year. So if you're using Lyft, most rides and functionality now are already going over Envoy Mobile. We've had a lot of quite a bit of interest from other large companies. I can't speak to any of them now, but I'm expecting broader adoption in 2021, but we'll have to see how it goes. I'm still very bullish on the technology. I think the goal of the project, which is to share the networking stack everywhere tends to resonate with people. And this comes back to actually what we were talking about before about the open API aspect, which is I think when you look at defining APIs and look at them end-to-end from the client to the server, I think there's very interesting functionality that we can provide if we own the end-to-end networking stack. Yeah, very exciting announcement that it transferred to the Envoy proxy organization just the other day, right? Yeah, yeah, that happened now. So now it's along with Envoy. And I would expect us to use that over time to better integrate the CI systems of both projects. Hopefully make things better. Um, let's see. Any plan to support additional languages natively beyond C++ without using WebAssembly? I don't know, that's something that you've probably been thinking about Harvey, if you wanna take that one. Yeah, so I think, I mean, we've seen over time, unofficially there has been other attempts to build things like Go filters and this kind of thing. I think WebAssembly is probably one of the key places that most of the community is gonna head towards because it provides a very stable interface and the ABI for building these kinds of integrations and it's kind of, you know, highly aligned with the idea of multi-language support. We have opened a tracking issue around rust use in Envoy. And this is a place where I think if anyone's interested in contributing, we would definitely be interested in trying to see what's possible. It's unclear whether we would be able to offer, for example, the same level of sort of integration as existing C++ extensions to Rust code, largely because of this problem of, you know, essentially foreign function interface, you know, Rust is a more like C like abstraction level and it's kind of hard to make it work well with C++ and there's just generally an open issue in the Rust community around that, but we're definitely interested in, you know, potential novel uses of Rust. I mean, one thing I would point out is that we actually have a pretty large array of extensibility options in Envoy now and that folks approaching, you know, building an extension for Envoy can choose between, you know, things like the traditional C++ native filters. We have WebAssembly. We have things like WebAssembly with no VM, which allows you to write C++ filters against the stable WebAssembly ABI. We also have Lure, obviously, we have things like network-based filters, which you can be also a very attractive design, point of the design space. And so examples of these include things like already in Envoy XOrthC is actually a protocol which is used to build a whole bunch of integrations beyond just, let's say, authorization because you're basically able to intercept requests and operate on their headers. And going forward, we have actually right now in the process, this great contribution from Greg Grail, which is going to be around as an external processing filter, which will essentially allow you to build a filter which is able to participate in the full Envoy request and response life cycle as a GRPC service. And so obviously that means anything that you implement, which sits behind a GRPC stub for this service, can actually then provide this functionality. So that's actually a pretty interesting and novel space for multi-language support and so on. Yep, I think in general, just to summarize, I don't think we're opposed to having other languages, right? It's like if someone actually wanted to figure out how to upstream, go filters or whatever else, we're not opposed to it, but it's pretty hard to actually make this work. It's a substantial amount of effort. And it's unclear that someone's gonna be willing to do that. So I think it really depends on the overall community and ecosystem. And my experience has been that for the vast majority of use cases when rubber meets the road, C++ works, Lua works, and I think WebAssembly will end up working for most people. So I'm just skeptical that people will actually put up the work other than Rust because I think Rust is the future. Okay, let's see, there's another question here. Sorry, if this is a vague question, we manually set up Envoy for two services, Envoy egress, Envoy ingress. We have seen upstream connect error or disconnect before headers. When under load, we are seeing the error occurrence decrease when we increase the cluster connect timeout. Is it a good idea to keep the connect timeout to be the same for all services? Any idea or guideline about what is happening? To be honest, it's really hard to comment or debug this type of thing remotely over conference video. So I would encourage you to either file an issue or hop into Envoy Slack. I would say in general, from what you're saying is that it's not surprising to me that under load, things take longer to connect and you might have to raise the timeouts. So at the end of the day, with a lot of the timeouts that you can set in Envoy, you're trying to balance performance with overall availability. And the only way to really tune that is gonna be to look at your particular use case and do low testing and figure out what type of error budget you are comfortable with depending on the load that you're taking. We're out of questions. Feel free to type in some more. Apparently there's another page. I think these are covered in this other page. Oh yeah, no, I think I've filtered all of the answered questions. So I think we've done them all. Yeah, I think so. Maybe I'll see you to question then, Matt. What are you most excited for in the coming year in Envoy? What am I most excited for? I think I'm excited for WebAssembly. I really do think that is the future of extensibility. So I am very excited for that one. And I'm excited for Quick and HQP3. Excited for I think a bunch of the work that we're gonna do in the Envoy mobile space. I'm excited for our general continued focus on security. So I think that's something where we've made great strides and there's always more to do. It's a very messy space. I think those are the things that come to mind. I will turn it around and ask you the same question. Yeah, I would definitely agree with you on that space. I mean, just generally extensibility in general, I think we're gonna see a continued growth in terms of extensibility in many different levels, whether it's how people are building Envoy extensions, it's how we're constructing the API and making that built around the concept of extensibility unless a few are sort of baked in concepts, I think. And generally sort of a bit gung-o about what I'm currently involved in around trying to improve things like scalability, cashability, federation support, this kind of stuff in XDS sort of trying to open it up to a wider audience. And I think it'll be very interesting to see other, the XDS ecosystem grow as a whole as we see additional proxies and data plane components jump on board. And I think that's, we definitely will see in the previous year we saw GIPC join. I think we're gonna see quite a few more folks come on board in 2021. So yeah, those are things that I'm definitely very excited about. And I think like on the security front, I'm very interested to see more, what will be exciting to see more folks and companies sort of getting involved and contributing there because I think we're starting to see this happening and it's actually really great to see security becoming a sort of common responsibility in something which many companies are sort of giving back to the onboard community with. Yeah. Let's see. What efficiency gains has Lyft made by implementing Envoy? You know, that's a tough one to answer, right? Because I'm not sure what efficiency this person's talking about. Are we talking about like compute efficiency or person efficiency? And to be honest, it's really hard to answer that because Envoy was developed relatively early on in, at Lyft to solve a bunch of problems around the microservice rollout and it certainly satisfied those goals. But at this point Envoy is so intertwined with everything that Lyft does. It's hard to go back five years and understand what it would mean to unwind that. I mean, it's not really possible. So I think that at least from the initial goals we started the project five and a half years ago, it was honestly mostly around developer productivity. It wasn't really around like machine performance. And I think the goal was to make it easier to do the microservice rollout. And I think from that perspective, the microservice rollout went from being stalled to being successful. So I think I would measure it more on the developer productivity side of things. So let's see. Has anyone put Envoy Proxy in front of the Kubernetes API server? Don't know. Do you know Harvey? Don't know. Let's see. Could you discuss some of the differences between Envoy and Istio? Would you like to take that one, Harvey? There's a lot from folks at Google who are ramping up an Envoy because the two are sometimes sort of treated synonymously. And so the way I would describe this is Istio is a complete service mesh offering. And Envoy is the data plane component there. It's the sidecar proxy and also using things like the Edge sort of egressing rest proxy that is used as a building block as part of Istio. So Istio includes many other things beyond just Envoy in terms of things like a CA, a policy engine, configuration and control management system. So all these things are sort of what constitutes Istio. So you could think of Envoy as being a single proxy which you would have like it's in a single node or a single lexic part in Istio. And Istio is really the whole network, the comprehensive service mesh offering there. Yeah. Anything to add, Matto? No. I think it's the control plane versus data plane discussion. And I think Envoy is unbiased with becoming the de facto data plane but we see lots of different control planes on top. Yeah. Let's see, are there any sample Go filters which we can use as a template? So like I said before, there's no upstream Go filter support. There have been a couple of projects that have done it. I know that Sillium has done it but it's not upstream. I think there's a couple other companies that have done it but nothing is upstream. I know that they're working on a tiny Go web assembly runtime so that might be an option but other than that, I don't think there's anything really out there. I think we're almost out of time. So let's see, we can take another couple. Is there any integration between Envoy and EBPF? Not directly but if you look at Sillium, again, they're doing a lot of stuff with EBPF and Envoy so I would look at them. And trying to look through if anything we can do quick. I don't know. What are the weirdest and surprising use cases of Envoy that you've seen? I don't know. Is there anything that we can end on that? Is there anything that comes to mind with you? Harvey? Trying to think. Weirdest and most surprising. Well, I'm not sure if I have any super surprising ones. One thing I will notice is as you browse the web increasingly these days or use certain platforms, you may occasionally see no healthy upstreams and you notice Envoy popping up in various places which you wouldn't expect. Yeah, I think I would say the same thing. It's just, it's everywhere, right? And so it's like it's used in telecom and internet and like finance and it's just all over the place. So I think the most surprising thing for me is just how widely it's been deployed and it's deployed all over the place from service mesh to internal load balancer to API gateway. So from a project perspective, it's really fantastic to see all that growth. So I think we're about at time. So for all of these other questions, I think there's an Envoy chat room and CNCF Slack. There's an Envoy Slack. Happy to answer questions there. So thank you. Okay, all right, bye.