Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Buoyant Releases New Kubernetes Service Mesh "Conduit" Written in Rust and Golang

Buoyant Releases New Kubernetes Service Mesh "Conduit" Written in Rust and Golang

This item in japanese

Buoyant, the company behind the JVM-powered Linkerd service mesh, has released "Conduit", a new experimental service mesh for Kubernetes. The Conduit proxy "sidecar" data plane is written in Rust, and the control plane is written in Golang. Conduit is not Linkerd 2.0. -- it is Kubernetes-specific and targets a different use case -- and Buoyant has stated that they will continue to develop, maintain, and provide commercial support for Linkerd.

Interest in the use of service meshes has increased dramatically over the last year, as L7 proxies such as Linkerd and Envoy have been released into open source, and the Istio project was publicly announced in collaboration with Lyft, Google and IBM. The topic has also been discussed at length within conferences, including the recent CNCF CloudNativeCon. Many Internet giants and "unicorn" organisations have been using technology that would now be identified as a service mesh for several years, e.g. Lyft with Envoy, Twitter with Finagle, and Google with Stubby and their Global Software Load Balancer (GSLB). Buoyant state that Linkerd is "the most widely deployed production service mesh in the world" and that it is in use within organisations such as Salesforce, Paypal, Expedia, AOL, and Monzo.

Linkerd was created based on the experience of the Buoyant team's work with Twitter's Finagle RPC framework during their time at this company. As stated in Buoyant's "Introducing Conduit" blog post, an additional learning from the previous 18 months of working with organisations that have adopted Linkerd is that there are deployment models where Linkerd's JVM resource footprint is simply too high.

Linkerd's building blocks -- such as Finagle, Netty, Scala, and the JVM -- allow Linkerd to scale up to incredibly high workloads when given access to increasing amounts of CPU and RAM. However, they are not designed to scale down to environments that have limited resources. This is a particular problem when operating the Linkerd proxy as a "sidecar" process running alongside application code, which is a common pattern within Kubernetes deployments.

Conduit is Buoyant's "next generation" service mesh in which the proxy data plane is written in Rust, and the "simple yet powerful" control plane is written in Go. Buoyant claims that performance has been a primary concern within the development of Conduit -- a single Conduit proxy has a sub-millisecond p99 latency and runs with less than 10mb RSS -- in addition to a focus on security, including implementing Transport Layer Security (TLS) by default for network communication and leveraging Rust's memory safety guarantees.

Several engineers have taken to Twitter to ask what this means for the future of Linkerd, and the official response on the Buoyant Conduit blog post is "in short, very little":

We'll continue to develop, maintain, and provide commercial support for Linkerd, and we're committed to ensuring that our many production Linkerd users remain happy campers.

The post also states that Conduit is not Linkerd 2.0., and instead targets a very specific environment -- Kubernetes -- and does not address any of the wide variety of platforms like AWS ECS or Mesos or integration use cases supported by Linkerd.

More information on Conduit can be found at the project's website and GitHub repository. The Conduit GitHub README clearly states that the project is currently experimental, and only supports HTTP/2 (and is especially well-suited for gRPC).

Rate this Article