ARMO for Google Traffic Director gRPC Proxyless Services

In its latest announcement of Traffic Director’s support for gRPC Proxyless services in service mesh Google addresses the well-known (yet less spoken of) trade offs for using sidecars to handle networking on behalf of your applications.

These tradeoffs include performance and resources requirements constraints, the need to manage yet another infrastructure element, and ability to connect with traditional services which may be out of the mesh. As Srini Polavarapu and Stewart Reichling wrote in their blog: “You shouldn’t need to manage a fleet of sidecar proxies”. Google took a significant step towards enabling high-performance, cross-environment network control through the Traffic Director by adding xDS API Support to the latest version of gRPC and support for GCP-Managed gRPC health checks.Since the xDS APIs are also used by Envoy proxy, which is by far the most prevalent open source sidecar project out there, this addition now enables customers to choose their preferred mode of operation based on what best fits their environment, and also to mix and match both sidecar-based and proxyless services under a single networking orchestration, load balancing and traffic management policies. All done under a single Google Traffic Director.

The main reason customers should be encouraged by this new development is that it enables service mesh networking capabilities in places that could not be implemented with the traditional proxy-based approach. First, in environments which require resource efficiency and performance such as 5G Telco network functions which are mentioned in the Google Cloud Blog, or other latency sensitive applications. Second, environments that do not allow for sidecar insertion like some of the managed computing environments or hybrid environments for which configuring a sidecar is a complex task.

In addition,it will also saves you money. As Stewart and Sirini write: “we’ve found thatproxyless gRPC can save on networking-related CPU costs compared to sidecarproxies. Benchmarks have shown that introducing sidecar proxies introduceslatency due to additional network hops. The proxyless approach promises savingson both of these dimensions. “

In this new addition to gRPC Google addresses a key need for many developments and organizations around the ease and flexibility of networking, but there is still a need to cover the security aspect of such environments, and doing it in a proxyless manner as well is needed in order to reap the claimed benefits (no sense in removing sidecars from networking and bringing them back for security).

As a unified security control plane for Service Mesh which is proxyless by design,we are excited by the opportunity this new development by Google presents customers in terms of traffic shaping and load balancing, and Cyber Armor customers will be able to benefit from that change instantly due to architectural similarity. After all, Cyber Armor focus since inception has been solving the security aspect of exactly such environments, with the notion of protecting microservices from within. For example, establishing TLS and microservices identities in environments with high throughput that could not afford the “node-sidecar-node” added latency of the sidecar model, or protecting microservices in environments where the customers have no ability to add another layer of infrastructure like Envoy.

DevOps and Development teams that wish to work across both proxy-based and proxyless services, establishing microservices identities, preventing malware attacks on Microservices and creating  micro-segmentation and data access policies seamlessly, can utilize Cyber Armor by installing the Cyber Armor plug-in for their existing CI/CD tools. Once installed, Cyber Armor maps each microservice that goes through the CI/CD and assure only valid authenticated services run,communicate and access data, regardless to whether their networking is managed through a proxy or via the newly announced gRPC proxyless mode.