GCP – Traffic Director and gRPC—proxyless services for your service mesh
Lot of organizations turn to service mesh because it solves tedious and complicated networking problems, especially in environments that make heavy use of microservices. It also allows them to manage application networking policies, like load balancing and traffic management policies, in a centralized place. But adopting a service mesh has traditionally meant (1) managing infrastructure (a control plane), and (2) running sidecar proxies (the data plane) that handle networking on behalf of your applications.
We built Traffic Director, a Google Cloud-managed control plane, to solve that first barrier to service mesh adoption—you shouldn’t need to manage yet another piece of infrastructure (the control plane). Today, we’re happy to share a new approach to solving the second problem—you shouldn’t need to manage a fleet of sidecar proxies. With Traffic Director support for proxyless gRPC services, you can bring proxyless gRPC applications to your proxy-based service mesh or even have a fully proxyless service mesh.
Traffic Director support for proxyless gRPC services
Traffic Director’s support for proxyless gRPC services is built on a simple idea: if Traffic Director can configure sidecar proxies to do load balancing on behalf of a gRPC client, why not have it just configure the gRPC client directly?
gRPC, as you may know, is a high performance and feature-rich open-source RPC framework that underpins many of the Google Cloud Platform (GCP) services that you use every day. GCP uses it in the Google Cloud client libraries, which you use to reach services like Cloud Storage, Cloud Pub/Sub and many others. gRPC handles connection management, bidirectional streaming, and other critical networking functions. In short, it’s a great framework for building microservices-based applications.
But, out of the box, gRPC only provides DNS-based name resolution and simple load balancing. For service mesh functionality (for example, dynamically discovering the backends for a service or global proximity-based load balancing), customers have traditionally turned to sidecar proxies. These sidecar proxies deliver powerful service mesh capabilities… but they’re also an additional piece of infrastructure to manage.
gRPC + xDS
To make proxyless gRPC possible, we added xDS API support to the most recent version of gRPC. The xDS APIs are the same open source APIs used by the popular Envoy proxy. They enable xDS control planes (such as Traffic Director) to configure gRPC clients with service information such as endpoint address, health status, priority (based on proximity and capacity) and which policies to use when calling out to the service.
Additionally, we added support for GCP-managed native gRPC health checks for your gRPC applications. Traffic Director collects data from these health checks and uses it to determine the health status of a service’s endpoints (as shown in the image above).
These additions enable you to get the benefits of a service mesh without having to deploy sidecar proxies alongside your gRPC applications.
Getting started with proxyless gRPC
We want to make it as easy as possible for you to get access to the benefits of service mesh. A big part of that is reducing the need for additional infrastructure. And the process of getting started with proxyless gRPC is easy too:
-
Update your gRPC application to the latest version
-
Use the new `xds` gRPC name resolver
-
Add a small bootstrap file
-
Configure services and policies in Traffic Director
More broadly, you can think of proxyless gRPC services as another way of deploying services in your service mesh (similar to services based on sidecar proxies). Traffic Director allows you to deploy both proxy-based and proxyless gRPC services in a service mesh.
We fully expect that customers will run service meshes that include both deployment models. We’ve even made it possible for a single gRPC client to call some services via the proxyless route and others via a sidecar proxy.
When to deploy Traffic Director with proxyless gRPC services
We see three main use cases for the proxyless gRPC approach—simplified gRPC adoption (thanks to a managed networking experience), high performance services in a service mesh, and bringing service mesh to environments where you can’t add sidecar proxies.
Managed networking for simplified gRPC adoption
We talk to customers all the time who are considering adopting gRPC as part of their efforts to modernize their application stack. The benefits of gRPC are clear but, on its own, gRPC doesn’t solve problems like client-side load balancing, service discovery and global failover. Traffic Director’s support for proxyless gRPC services was built to solve these needs, thereby making it easier to adopt gRPC as part of a modernized deployment.
Resource efficiency and performance
Proxies consume resources and those may start to add up as you scale to hundreds or thousands of proxies. Plus, high-performance applications may find it difficult to meet performance targets when sending requests through multiple sidecar proxies (client sidecar proxy, server sidecar proxy, and back again for request/response exchanges).
In our testing, we’ve found that proxyless gRPC can save on networking-related CPU costs compared to sidecar proxies. Benchmarks have shown that introducing sidecar proxies introduces latency due to additional network hops. The proxyless approach promises savings on both of these dimensions.
Finally, we believe that this performance gain will be important for emerging use cases, such as service mesh deployments for telco network functions and 5G/edge computing.
Service mesh for environments where you can’t add sidecar proxies.
We’ve talked to customers who can’t necessarily add sidecar proxies to deployments. Some managed compute environments don’t let you spin up multiple processes (one for the application, one for the proxy) or make changes to an instance’s network stack (for example, using iptables). In such cases, proxyless gRPC applications provide a great way to get the benefits of service mesh.
What’s next?
Enterprise networks are heterogeneous. We built Traffic Director to be flexible so that we can support deployment options that meet your needs. Supported deployment options include Envoy sidecar proxies, Envoy middle/gateway proxies (including our Internal HTTP(S) Load Balancer, which uses Traffic Director under the hood) and, now, proxyless gRPC applications.
This initial release is focused on service discovery and load balancing. We know that service mesh promises a lot more than that—layer 7-based traffic management and security, for example—but we’re excited about this first step. The traffic management capabilities that we’re announcing today, alongside new GCP-managed gRPC health checks, are just one step in making it easy to bring service mesh to your gRPC applications.
We hope you’ll join us and check out the setup guides for Traffic Director with proxyless gRPC services on Compute Engine and Google Kubernetes Engine. To learn more and see Traffic Director’s support for proxyless gRPC services in action, watch our breakout session NET206 on NextOnAir, starting July 28, 2020.
Read More for the details.
