Rust is a systems language originally created by Mozilla to power parts of its experimental Servo browser engine. Once highly experimental and little used, Rust has become dramatically more stable and mature in recent years and is now used in a wide variety of settings, from databases to operating systems to web applications and far beyond. And developers seem to really love it.

You may be surprised to find out that the venerable Rust has established a substantial toehold here at CNCF as well. In fact, two of our incubating rojects, TiKV and Linkerd, and of our sandbox projects, OpenEBS, have essential components written in Rust and both projects would be profoundly different—and potentially less successful—in another language.

In this post, I’d like to shed light on how TiKV and Linkerd are contributing to the Rust ecosystem.

TiKV

TiKV is a distributed, transactional key-value database originally created by the company PingCAP. Its core concepts are drawn from the venerable Google Spanner and Apache HBase and it’s primarily used to provide lower-level key/value—the “KV” in “TiKV”—storage for higher-level databases, such as TiDB.

In addition to the core repo, the TiKV project has contributed a number of libraries to the Rust ecosystem:

PingCAP’s blog has also featured some highly regarded articles on Rust, including The Rust Compilation Model Calamity and Why did we choose Rust over Golang or C/C++ to develop TiKV? If you’re like me and excited about witnessing a new generation of databases written in Rust, you should really keep tabs on TiKV and its contributions to the Rust ecosystem.

Linkerd

Linkerd is a service mesh that’s relentlessly focused on simplicity and user-friendliness. If you’ve ever felt frustrated or overwhelmed by the complexity of other service mesh technologies, I cannot recommend the breath of fresh air that is the Linkerd Getting Started guide more highly. And in case you missed it, Linkerd had a huge 2019 and is continuing apace in 2020.

Arguably the most important component of Linkerd is its service proxy, which lives alongside your services in the same Kubernetes Pod and handles all network traffic to and from the service. Services proxies are hard to write because they need to be fast, they need to be safe, and they need to have the smallest memory footprint that’s commensurate with speed and safety.

The Linkerd creators opted for Rust for the Linkerd service proxy. Why did they make this choice? I reached out to Linkerd co-creator Oliver Gould to provide the breakdown:

When we started building Linkerd ~5 years ago, some of our first prototypes were actually in Rust (well before the language hit 1.0). Unfortunately, at the time, it wasn’t mature enough for our needs, so Linkerd’s first implementation grew out of Twitter’s Scala ecosystem. As we were working on Linkerd 1.x, Rust’s Tokio runtime started to take shape and was especially promising for building something like a proxy. So in early 2017 we set out to start rewriting Linkerd with a Go control plane and a Rust data plane. Tokio (with its sister projects, Tower & Hyper) made this all possible by extending Rust’s safe, correct memory model with asynchronous networking building blocks. These same building blocks are now being used in a variety of performance-sensitive use cases outside of Linkerd, and we’ve built a great community of contributors around both projects. If this is interesting to you, please come get involved!

In terms of contributions back to the Rust ecosystem, Linkerd has upstreamed core components to Tower and Tokio, such as Linkerd’s load balancer and Tokio’s tracing module.

In addition, the project also undertook a security audit of the rustls library (sponsored by CNCF). As the name suggests, rustls is a transport security layer (TLS) library for Rust that’s used by the Linkerd proxy for its mutual TLS (mTLS) feature, which is crucial to the security guarantees that the Linkerd service mesh provides. You can see the result of the audit in this PDF. Cure53, the firm responsible for security audits of several other CNCF projects, was “unable to uncover any application-breaking security flaws.” A sterling result if I say so myself!

OpenEBS

OpenEBS is a container-attached (CAS) and container-native storage system that enables you to easily manage Persistent Volumes in Kubernetes. The data plane for OpenEBS, MayaStor, is one of OpenEBS’ core components and written in Rust. Here’s what Even Powell, CEO of MayaData, the company that originally created OpenEBS, had to say about the choice of Rust:

Due to its (almost) shared-nothing design in the data path, Rust is an ideal fit if you want to avoid accidentally moving or sending data between cores. To integrate with the Poll Mode Drivers (PMDs), Data Plane Development Kit (DPDK), or Storage Performance Development Kit (SPDK), we’ve implemented a simple reactor that enables us to integrate with other Rust projects, such as tonic-rs (a gRPC implementation that’s Rust native, unlike grpc-rs from PingCAP) while also adhering to strict rules for working with PMDs. With Rust, those rules are actually enforced by the compiler.

More to come?

I’m a huge fan of Rust myself, though I’ve really only dabbled in it. I have my fingers crossed that TiKV and Linkerd are just the beginning and that we’ll see a whole lot more Rust in the cloud native universe, be that in the form of new CNCF projects written in Rust, existing projects porting components into Rust, or new Rust client libraries for existing systems.

And if you’re curious about all of the programming languages in use amongst CNCF’s many projects, stay tuned for an upcoming blog post on precisely that topic.