This presentation by Eric Anderson, a gRPC maintainer, discusses the interaction between gRPC and various service mesh architectures. It begins by defining service meshes as infrastructure layers that enhance service-to-service communication by handling encryption, load balancing, observability, and resiliency, thereby decoupling these concerns from application code. While gRPC, which relies on HTTP/2, is generally compatible with service meshes, the optimal choice of mesh architecture depends on specific use cases and priorities (e.g., ease of deployment, features, performance).
The talk explores several architectures: no mesh, gateway, daemon set, sidecar, and proxyless. A key distinction is made between Layer 4 (connection-based) and Layer 7 (application-aware) proxies, highlighting how HTTP/2's single connection per client makes L4 load balancing less effective for gRPC. L7 proxies or native gRPC L7 load balancing become crucial for heavy gRPC workloads. The presentation emphasizes that the primary benefit of HTTP/2's connection reuse in a mesh is to mitigate the overhead of expensive TLS security handshakes. Proxyless architectures are suggested for performance-sensitive, gRPC-heavy environments, as they eliminate proxy-induced latency, though they might offer fewer features. The concept of hybrid meshes (e.g., Google Cloud Service Mesh) that allow optional proxyless deployments is also introduced. Finally, the discussion touches on HTTP/3 (QUIC), noting its potential for faster handshakes but practical limitations for authenticated gRPC due to replay attack concerns.
Service Meshes and gRPC: Architectural Deep Dive
0:07 What is a Service Mesh? An infrastructure layer that enhances service-to-service communication by handling encryption, load balancing, observability, and resiliency, decoupling these from application code.
0:37 gRPC Compatibility: gRPC generally works with service meshes as it requires HTTP/2, which is commonly supported. The best mesh depends on specific problems you're trying to solve (e.g., deployment ease, features, performance).
No Mesh (0:02:01): Direct service communication, but suffers from load balancing issues, lack of security, and slow policy updates (requiring application redeployment).
Gateway (Proxy between client/server) (0:02:38): Provides good load balancing and quick policy updates without client/server redeployment, but typically lacks security.
Daemon Set (Proxy per node) (0:03:16): First service mesh architecture; a proxy runs on each node, shared by pods. It enforces mutual TLS encryption and restricts service access.
Sidecar (Proxy per pod) (0:03:44): A proxy runs alongside each pod. Offers better resource allocation for high-traffic applications but shares pod resources, potentially complicating deployment.
Proxyless (0:04:30, 0:09:24): The application directly implements service mesh features, removing the need for an external proxy. Ideal for gRPC-heavy and performance-sensitive services.
L4 Proxies (Network/Transport layer): More efficient, operate at IP/TCP level, and only load balance connections.
L7 Proxies (Application layer): More feature-rich, operate at the HTTP level (and other protocols), and can load balance individual requests (per RPC).
6:53 gRPC's HTTP/2 Impact: HTTP/2 uses a single connection for many requests. L4 proxies, which load balance connections, are less effective for gRPC as they result in less frequent load balancing. L7 proxies or gRPC's native L7 load balancing (e.g., via headless services or waypoints in Istio) are often necessary for heavy gRPC clients to ensure better distribution to backends.
8:55 Security and HTTP/2: The reuse of HTTP/2 connections in service meshes is primarily driven by the high cost of TLS handshakes for secure communication. Reusing connections avoids repeated expensive handshakes.
9:24 Proxyless Benefits: Recommended for performance-sensitive gRPC services because proxies add latency. It allows for incremental deployment and direct implementation of mesh features within gRPC.
10:41 Hybrid Mesh Models: Some cloud service meshes (like Google Cloud Service Mesh) support both proxied (sidecar) and proxyless deployments within a single mesh, offering flexibility for different workloads.
12:34 HTTP/3 (QUIC) and gRPC: While HTTP/3 offers faster handshakes (0-RTT/1-RTT), 0-RTT is rarely usable for authenticated gRPC (e.g., POST requests) due to replay attack concerns. HTTP/3 is more beneficial for mobile and internet traffic than for data center internal communication. gRPC does not natively support HTTP/3 yet, though some proxies might.
15:32 Versioning and Schema Updates: Service mesh architectures have minimal impact on gRPC schema updates, which are primarily application-level concerns. However, meshes provide tools for A/B testing and canary deployments.
19:28 Why Use Sidecars? Sidecar models remain valuable for environments with mixed traffic (gRPC and other protocols like REST) or for integrating legacy applications that cannot implement mesh features directly. This trades some resource cost and latency for broader compatibility and centralized management.
21:26 Authentication in gRPC Meshes: Service-to-service authentication can often be performed once per connection, allowing connections to be reused and minimizing repeated authentication overhead.