Why the pioneer of the service mesh category is also the project with a radically different approach

The service mesh market is feeling particularly crowded these days, with the number of distinct projects reaching into the double digits-including, in some cases, multiple projects from the same company. But it's not a particularly diverse one. Under the hood, many of these projects seem to blend together, building on the same technology and promising the same things, with little actual practical differentiation.

In this dreary landscape, Linkerd stands apart. The project that pioneered the service mesh category is also the one taking a very different approach, with a dedicated data plane "micro-proxy" and a contrarian focus on doing not as much but as little as possible.

What makes Linkerd so different? It comes down to the project's core design philosophy: that a service mesh should be simple, light, and secure above all else. This philosophy stands in stark contrast to the broader service mesh trends of accumulating features and machinery as rapidly as possible, no matter the cost. Ultimately, Linkerd is predicated on the belief that when it comes to critical infrastructure, less really is more.

A contrarian stance against complexity

The most remarkable difference between Linkerd and other projects may be the amount of operational complexity it introduces to the system. This should come as no surprise as the project is fixated on keeping this cost to a bare minimum.

What does reducing operational complexity entail? Of course, minimizing configuration and tuning is a big part: Linkerd is the only service mesh today that in its default configuration can be dropped into an existing application and have the application simploy continue functioning. But it also extends to advanced features such as transparent mutual TLS, which Linkerd enables by default without disturbing the application.

More importantly is Linkerd's focus on providing diagnostic and introspective tools to its operators. Operability, after all, requires developing a mental model of what the system is doing, and here Linkerd provides a variety of powerful tools that allow operators to understand exactly what is happening under the hood. For example, Linkerd's control plane itself runs on its data plane, allowing the same powerful observability tools that it provides for diagnosing application behavior to be used on Linkerd itself.

This desire for operational simplicity is also what drives another unique feature for Linkerd: rather than building on Envoy, as many other projects do, Linkerd uses a specialized "micro-proxy" called Linked2-proxy.

Linkerd2-proxy, the ultralight "micro-proxy"

Key to Linkerd's simplicity and performance is its unique data plane implementation, a "micro-proxy" called simply Linkerd2-proxy. Written in Rust and specifically designed for the service mesh use case, Linkerd2-proxy sits on the bleeding edge of modern asynchronous network programming, leveraging the advances of the flourishing Rust networking ecosystem to deliver incredible performance.

In contrast to general-purpose proxies such as NGINX, Envoy, or Apache, Linkerd2-proxy does only one thing: it acts as a service mesh "sidecar", relaying requests to and from a single instance of an application. This laser-like focus on a specific use case allows Linkerd2-proxy to be extremely fast, extremely small, and extremely secure- of course, at the expense of general applicability.

Linkerd2-proxy is also key to Linkerd's simplicity: it is designed to be an "implementation detail" that is not exposed to users directly, and for the vast majority of common cases to require no independent configuration or tuning. Unlike Envoy-based systems, Linkerd2-proxy allows Linkerd to just work out of the box and to avoid complex, configuration-heavy and error-prone maintenance. (To learn more about Linkerd2-proxy, see Why Linkerd doesn't use Envoy.)

The choice of Rust for Linkerd2-proxy also provides a strong foundation for another critical goal: security.

Security from the data plane up

Linkerd's emphasis on security is also unique in the murky waters of the service mesh ecosystem.

This focus starts at the data plane layer, where the choice of Rust for Linkerd2-proxy allows Linkerd to neatly sidestep an entire class of security vulnerabilities endemic to C and C++ programs: flaws in memory usage that allow for buffer overflow exploits and other critical vulnerabilities. Rust's strong guarantees about memory safety and its (in)famous "borrow checker" allow for compile-time verification of proper memory usage, rather than the after-the-fact mea culpa approach of C and C++ proxies. These guarantees are vital at the data plane layer, which is, after all, where customer data flows, whether it be financial transactions, health information, or other sensitive data.

Linkerd's approach to security extends from the data plane to its holistic focus on simplicity. The reality of any complex software system is that humans, not software, are the source of many exploits. Linkerd's core belief is that complexity is antithetical to security, and that a system that requires extra effort to secure, or that provides security only via complex configuration, is inherently insecure.

Thus, Linkerd has taken a "security by default" approach, where even advanced features such as mutual TLS are enabled by default, without requiring configuration or tuning.

The future of the service mesh

Today, organizations such as Microsoft, Nordstrom, HEB, Expedia, and many more rely on Linkerd to play a mission-critical role in their software stacks, and adoption continues to compound. And while the present of the service mesh may still be over-hyped and over-marketed, the future, optimistically, is a boring one. Once the buzz and excitement of the service mesh ecosystem finally die down, we hope to advance to a state of maturity wherein a service mesh is simply something that one installs without fanfare before getting on with the important stuff.

As with all infrastructure software, the true value of the service mesh lies not in what it does but in what it enables. A service mesh is a critical step towards building reliable, agile, and secure cloud native platforms, but it's certainly not the final one. The true future of the service mesh thus lies in the tooling that can be built on top of it. This nascent but fast-blossoming field includes incredibly exciting and innovative projects, ranging from progressive deployment tools such as Flagger to global Kubernetes platform health dashboards such as Buoyant Cloud. Seen through the lens of these projects, the future of the service mesh is, as they say, so bright you got to wear shades.

##

About the Author

William is the co-founder and CEO of Buoyant, the creator of the open source service mesh project Linkerd. Prior to Buoyant, he was an infrastructure engineer at Twitter, where he helped move Twitter from a failing monolithic Ruby on Rails app to a highly distributed, fault-tolerant microservice architecture. He was a software engineer at Powerset, Microsoft, and Adap.tv, a research scientist at MITRE, and holds an MS in computer science from Stanford University.