 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
With the newest edition of the gRPC protocol, microservices-based systems will no longer need separate stand-alone service mesh sidecars, noted Megan Yahya, Google’s product manager for gRPC, in her talk at KubeCon+CloudNativeCon EU earlier this month.
Instead, for those already using gRPC, they can extend the service directly to the control plane, and have it take over the work formerly done through proxy services, such as the Cloud Native Computing Foundation’s Envoy, one of the most popular sidecar proxies in use today.
Created at Google and released in 2016, gRPC is a super low-latency http/2-based remote call procedure (RPC) that allows a service or application make a call to a resource over the network as if it were a local entity. This can be really useful for microservices that create a lot of network chatter by passing messages to each other (“east-west traffic” in data center parlance). And by supporting a dozen or so programming languages, gRPC allows services written in different languages to communicate with one another, without the need for one-off glue code.
In a typical service mesh deployment, each application gets a sidecar proxy, which intercepts all the traffic going to the application, filtering it using the policies it gets from the control plane. This stand-alone sidecar approach has its limitations, however: Additional overhead would come from any add-on software such as a proxy server, as would additional maintenance, and upkeep. Another problem: No end-to-end security, as in most cases traffic is terminated at the sidecar, and relayed back to the app itself in cleartext.
Recent editions of gRPC come with the ability to process requests directly from the control plane, eliminating the need for sidecar proxies, Yahya pointed out. It can support a range of service mesh duties, including load balancing and service discovery. This is done thanks to its use of the XDS data plane APIs, first developed by the Envoy team.
The XDS support allows the application itself to talk directly to the control plane, rather than having a sidecar as a go-between. Instead of installing Envoy, the app developer would just add a gRPC channel with an “xds” resolver scheme. A boot file is also needed to point the app to the control plane. Ezy Pezy.
In her presentation, Yahya admits that the gRPC still has a way to go in covering all the features currently offered by Envoy. The tooling around Envoy, especially around third-party filters, is more mature.
The first version of gRPC To support this functionality came with v1.30.0 in June 2020. The current version, v1.35.00 supports service discovery, load balancing, traffic splitting and route matching. Future features will include time-outs, circuit breaking, and TLS and MLS support for the control plane, as well as observability features.
Out of the box, it works well with Google Cloud’s Traffic Director service mesh and has experimental (no documentation) support of Istio, Google’s own open source control plane software.
Check out the whole presentation here:
