Why Proxyless Service Mesh Could Replace Sidecars: A Hands‑On Istio Demo

Service Mesh Overview

Service Mesh is no longer a new concept; it has become a core part of cloud‑native architectures for handling traffic management, fault recovery, load balancing, and gradual releases without changing application code.

Istio Evolution

In 2016, Buoyant released Linkerd and Lyft released Envoy, marking the birth year of Service Mesh. In 2017, Google, IBM, and Lyft launched Istio, introducing a dedicated control plane that unified traffic control. Istio 1.0 made the platform production‑ready, and Istio 1.5 consolidated components into a single binary istiod, removing the Mixer.

Proxyless Service Mesh Architecture

Proxyless Mesh removes the sidecar proxy and implements the data‑plane as an SDK embedded in the application process. The control plane remains istiod, while the data‑plane communicates with it via the xDS protocol.

xDS protocol details: https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol

In a sidecar‑free setup, an Istio Agent generates a bootstrap file for the gRPC library, tells it how to reach istiod, provides certificates, and acts as an xDS proxy to fetch and rotate those certificates.

gRPC Proxyless Mesh documentation: https://istio.io/latest/blog/2021/proxyless-grpc/

Advantages and Disadvantages of Proxyless Mesh

Performance : Direct point‑to‑point calls reduce latency compared with sidecar routing.

Stability : Single‑process topology simplifies debugging.

Cost : No sidecar means lower resource consumption.

Framework Integration : Existing SDK‑based frameworks can be reused.

Drawbacks include the need for language‑specific SDKs and reduced upgrade flexibility, as changes require code modifications rather than sidecar swaps.

Demo: Enabling Proxyless Mesh for a Spring Cloud Application

Prerequisites

Enable MSE service governance and create an Alibaba Cloud ASM Istio instance for the target Kubernetes cluster.

Step 1 – Deploy Services

Deploy a Spring Cloud Java service and a multi‑language Go service. The Java service can call the Go service using the same RestTemplate pattern as it would call another Spring Cloud service:

restTemplate.getForObject("http://go-sc-a/A", String.class)

Step 2 – Enable xDS via Environment Variable

Set the following environment variable to activate the MSE Agent’s xDS support: profile.micro.service.envoy.xds.enable = true – Enables xDS protocol for service governance.

Step 3 – Verify Connectivity

After the configuration, the Spring Cloud service can reach the Go service without any code changes: ~ curl localhost:20003/go Output shows the request flowing from the Java Spring Cloud instance through the Service Mesh to the Go service.

Conversely, the Go service can call the Spring Cloud service:

~ curl localhost:8085/java

Conclusion

The demo demonstrates that a Spring Cloud application can gain Proxyless Mesh capabilities simply by enabling MSE governance, without modifying application code. Current limitations include support only for basic service discovery and DestinationRule subsets, but combined with MSE traffic management, full‑link gray releases and tag‑based routing are achievable.