Buoyant Overhauls Linkerd, Moves to a Simpler Service Mesh Model
Buoyant has completed a total overhaul of its Linkerd service mesh, replacing much of the code base with its previously next-generation service mesh project, Conduit.
The Conduit codebase is lighter and speedier than the Java-based Linkerd, and is more tightly integrated with the Kubernetes container orchestration manager, noted William Morgan, Buoyant CEO. The new Linkerd also represents a fundamental shift in how a service mesh can be architected, one geared more towards the developer, or “service owner,” Morgan noted.
An open source project, Linkerd has been under the stewardship of the Cloud Native Computing Foundation (CNCF) since early 2017.
A big part of the performance improvement has come from ditching the Java Virtual Machine (JVM) that drove Linkerd Mark 1. The new control plane of Linkerd was written in the Go language, making it an easy fit with the Kubernetes development, and data plane proxies were written in Rust, a language known for both its speed and memory safety. Early Conduit use found that the proxies minimized latency to a millisecond.
“The service mesh model is busted in at least two ways,” Morgan explained. First, service meshes such as Linkerd, as well as other offerings such as Istio, tend to be large software packages. “They are all complicated pieces of technology, presented as an all-or-nothing proposition, You either install this big chunk of technology, or you don’t,” Morgan said.
The previous version of Linkerd was built to work across an entire architecture, though the new version can be installed to work on as little as an individual app, or service, as a single “service sidecar,” even without access to the cluster as a whole. Linkerd’s sidecar-first approach potentially provides an organization an easier on-ramp to gradually moving to a microservices-oriented architecture.
The second problem with traditional service technology, Morgan went on to explain, is that it focuses usability on the platform owner, rather than the developer. “It underserves the service owner, and the service owner is the one who actually has to use this technology to get their job done,” Morgan said.
The new Linkerd’s sidecar approach caters first to the service owner, or developer, Morgan said, providing them with automatic observability, reliability, telemetry, and runtime diagnostics, all without any changes to the application code itself. “We give you the ability to see your service, to see exactly where traffic is coming from, and where it is sending traffic,” Morgan said.
Linkerd also offers benefits to the platform manager as well. It can encrypt all service-to-service traffic, for instance, through TLS. It can generate certificates and distribute them to the proxies.
Beyond Buoyant, the Linkerd project has gained use and attracted input from companies such as Salesforce, Walmart, Comcast, CreditKarma, PayPal, and WePay. The Conduit project was started last year as a way of addressing some of the issues and user preferences that the company noticed in the 18 months that Linkerd had been used in production.
Some users were very happy with Linkerd, while others had issues with it, and others weren’t able to use it at all for various reasons, Morgan told an audience at the Kubecon last December in August.
Early Linkerd work also clarified the roles in a cloud native environment.
“We’ve seen this rise of this role that we’ve been calling a ‘service owner,’ which is someone, a developer, who is responsible for building a service, but also for deploying and maintaining it,” Morgan told The New Stack.
Internally, Buoyant has been calling this work “ServiceOps,” which Morgan describes as a cloud-native extension of DevOps. “You don’t own the platform layer, but you own the runtime and development time of the service, which is one piece of the larger business logic,” Morgan said.
Linkerd is not backward compatible to 1.x versions of the software, and a clear migration path for many cases still must be developed, Morgan said. Additional work must also be done to bring version 2.0 to feature parity with 1.0 as well.
While the upgrade path from 1.x to 2.x will be a major upgrade for users, given its new code base, the CNCF anticipated this shift. The open source community around Linkerd however, has committed to supporting both versions of the software for the foreseeable future.
CNCF leaves backward compatibility for the project to decide but we generally recommend they follow semver,” or semantic versioning, wrote Chris Aniszczyk, CNCF Chief Technology Officer. Linkerd is still in the “incubation” stage at CNCF and so changes are expected.
Buoyant and The Cloud Native Computing Foundation are sponsors of The New Stack.
Feature image via Pixabay.
