 Hi everyone. My name is Megan Yahya. I am product manager for GRPC at Google. Today I'm happy to be talking to you about service measures with GRPC and XDS protocol. So let's first talk about GRPC and microservices. So I'm assuming a lot of you are familiar with GRPC, but let's talk about why GRPC is the appropriate way of communication between microservices in a service mesh. So GRPC is a very high-performance and efficient protocol. So if you know already, it's based on HTTP2 and is very compatible with protobufs. And that is super important in microservices. Because when we are talking about microservices, we are talking about a great amount of east-west traffic versus the north-south traffic. So the magnitude of east-west traffic is much, much bigger than the north-south traffic. And that makes it a lot important to make sure that these communications are as performant as possible. The other value that a lot of customers are seeking when they adopt GRPC is the fact that GRPC is supported in a lot of languages, in 13 languages at the moment. And why it matters is because when you break down your monolith, or when you start writing a cloud-native application, it's usually because you want to leverage the value that different languages bring to the table. So you might have Python, you might have Java, you might have C++, you might have a lot of different languages as part of the same organization. And it's important for these languages to call each other. So the fact that GRPC supports all these languages makes it easy and reduces a lot of code that your developers would otherwise have to write by just auto-generating this code for the clients and services. GRPC, as I mentioned, is compatible with Protobufs. And of course, there are several values of Protobufs. Like if you're familiar with it, you basically have to write the service definition first. And that creates a single source of truth for your service. And it makes the API documentation generation easier. And it makes getting into agreement with different teams easier. So there are a lot of different values for it, Protobufs. And of course, with GRPC, there are additional features like deadlines, cancellation, and support for interceptors. So GRPC already has high industry adoption for the reasons that I mentioned in the previous slide. But let's talk about GRPC applications inside the service mesh, right? So today they're like, if assume you want to deploy your GRPC application as part of a service mesh that you have chosen, right? But so you would still need some way to provide service discovery, load balancing, security, and all that, right? So because these features, they don't come as part of GRPC, at least until today. And that's a topic that I'm going to cover today. So let's think about a typical service mesh that's out there today. And they're mainly running with sidecar proxies, right? So you're, for example, you're familiar with Istio, right? Like their envoy-based sidecar proxies, which is basically you have this data plane that is this proxy that's running next to your application. And that data plane is intercepting all the traffic and is communicating with the control plane. So the sidecar proxy, which is in this case, envoy, for example, for Istio, they are receiving the configurations from this service mesh control plane. And they're helping your GRPC service to route its calls and they provide observability and all the other features. But your GRPC application, it's not even aware that it is part of this service mesh. It's just doing whatever it was doing before. And it's the envoy, which is intercepting the traffic and applying the policies to that request. So this is what a GRPC application looks like in a service mesh today, next to side, if it's deployed next to sidecar proxies. But then it has limitations, right? So if you're using these sidecar proxies, sidecar proxies are just like any other binary, right? So if you're deploying all these binaries in your mesh, there's, of course, performance overhead. There's been a bunch of benchmarks and all of them show significant overhead that is caused in terms of number of requests per seconds that can be made between your services in case that you have the proxy or you don't have the proxy, right? So there's a lot of latency that is applied because of the sidecar proxies. There is CPU cost overhead, of course. And then one of the other important parts for some of the customers is the security part, right? So because when you have these sidecar proxies, the sidecar proxies in charge of terminating the secure connection and your application is actually talking plain text. And for some organizations, this is not that acceptable. So, and of course, with the binaries, you have to manage the binaries, you should provide health checks for the binaries, you should upgrade them, and anything that applies to the life cycle management of these binaries. So let's talk about what we've built just recently, right? So what we have built is GRVC service mesh, but in a proxy manner. So there are no proxies needed because we have built the data plane functionality into GRVC itself. So what it means is that now with this new product that we have launched, your GRVC application can just easily become part of the service mesh, assuming you have a control plane that understands XDS and can talk to this GRVC services. And it can just receive the policies directly from the control plane. So no sidecar proxies needed, no unvoiced. And yeah, you get all the value with the service measures, you get the load balancing and service discovery and the observability and etc. So let's talk about XDS a little bit because I hear mentioned that like GRVC services talking to the control plane, but you might ask, okay, how is it talking to the control plane? And that is true XDS APIs. And you might ask, okay, what is XDS APIs? XDS APIs is a bunch of data plane APIs that that were basically invented by by the Envoy team. So when they launched Envoy, the XDS API was the way to configure your Envoy's. And it's quite an Envoy is quite popular today, and it's used in many open source projects. And on top of that, XDS is also open. And there's a lot of values to XDS. It is extensible, it has strong community support and all that makes this makes made it the right choice for us for this service mesh integration in GRVC. So so exactly the same way that Envoy is talking to the control plane using XDS APIs. GRVC is now able to talk to the control plane using the same XDS APIs. So let's talk about XDS and GRVC. So you can just build a GRVC channel with XDS resolver and resolve a scheme. So it's not any different from the DNS really, like instead of the previous version, you just put XDS column, and and that takes care of it. And the other change that you have to make with this setup in order to make your application able to talk to the control plane is providing a bootstrap file. So and all the bootstrap file is doing is just providing your a GRVC server with information about a GRVC service with information about where is this control plane, right? So where should it initiate this connection to. So once you provide that bootstrap, that's it. Like now you can now your GRVC application is part of the service mesh, and you don't need to deploy anything else. It's it's very too easy. It makes it very easy to adopt to adopt service mesh for customers. And the other cool part is that you don't have to like, if, for example, you have some applications who still not support this or or some features that are not available, etc, you might just choose to migrate slowly, like by having some communications through Proxyless channel and some communications through Proxy channel, like still keep your envoy there. So this hybrid model is also supported. But of course, like everything else, there's some limitations with our product today. So one of it is the feature gap with envoy, right? So of course, envoy has been there for a longer time. So we're still trying to catch up with all the features that envoy has. And I'm going to talk about that in more detail in a few slides down. And then the other part is all the ecosystem around envoy filters, right? So you might say, oh, but envoy has this cool filters and observability tools. We are trying to catch up with those as well. So GRPC already has interceptors, and it also has the open census integration. So that that covers part of it. But we're in process of making it better and better. And then, of course, you might say, okay, GRPC applications need some changes, right? So you need to upgrade your GRPC, you need to provide the good strap, etc. So the challenge with upgrading, etc, it usually applies to more legacy applications. So if you're a modern application, you just, you already have great CI CD pipelines, so it's not a big deal. And then there is another downside today, which is limited language support. So the stuff we have learned so far is it just supported in this number of languages, which are, which we have realized is the most popular languages in the service mesh today. So here's the current status. So we first released the first version in June 2020. And then the features that are currently supported are basically ability to do service discovery and load balancing, and also route matching and traffic splitting. And we have a bunch of other features in development that are just about to be launched, like, for example, we have timeout, circuit breaking, or we are also working on the security to provide, like, TLS and MTLS using the control plane policies, basically, and also working on some observability features and XDS integration. So this is a link here that you can basically browse to, and it will provide you with the latest updates on our features, like where we are, and we show the features upcoming, et cetera. So you might ask, okay, how, like, you're providing the data plane, like, which is your PC? So how about control plane? Where should I get my control plane to get started? So today, Google Cloud's traffic director, which is a service mesh control plane is super compatible with this product that we have launched. So it provides you with all these service mesh functionalities and, like, ability to do load balancing and routing and automatic failovers. And it works across GC and GKE. So this works out of the box today. You can just go ahead and use it right away. But of course, we know, like, there are other control planes that are popular, like Istio. And we have done some experimental work to see how it works. And there is a test tier you can browse to and try it out. But unfortunately, we don't yet officially support this, but we have plans to, in the future, support this in a more official way. So, and then there is also, there's a Go control plane. There is an issue that's been created. And we would be happy to see more progress on that ticket to get this open source control plane compatible with the GRPC Proxilus service mesh. Here are some resources if you just want, if you're interested and want to get started on this. So these are the GRFCs. Like, you can, you can see what the features that are in development or existing ones. And then you can have that link that shows you all the features. And if you're just in the beginning and trying to learn more of the concepts about control plane versus data plane and all those keywords, you can try some of these links in this slide. So that is it. Like, I'm really glad I got a chance to talk to you all. So I'm looking forward to hearing all your questions. Thank you.