The Creators of Linkerd
Creators of Linkerd
In the open source world, good governance makes for good projects, and for Linkerd it also serves as an act of commitment to users. As such, the service mesh project today created a steering committee.
Steering committee’s are nothing new to the cloud native space where community is a key, if not the most important, component of an open-source project. These committees typically focus exclusively on either technical matters like election rules, codes of conduct, and release procedures or non-technical tasks like “speaking for the project” or “ownership of the web domain.”
Linkerd has different plans for its steering committee that are not so black or white. William Morgan, CEO of Buoyant and one of Linkerd’s creators, explained in a blog post that the Linkerd Steering Committee has one simple goal: to ensure that Linkerd meets the needs of its current and future users. Thus, rather than representing vendors, Linkerd’s steering committee members represents Linkerd users.
“We are focused primarily on serving the needs of our end users to further increase the reliability, security, and observability of their platforms … and that focus on simplicity and empathy for our end user has guided us in a unique direction,” Morgan said in an interview with SDxCentral.
According to Morgan, the formation of the committee is directly related to project growth. And as the community has grown, so to has the task of gathering, collating, and prioritizing feedback. The steering committee will serve as the “voice of the user” to help maintainers prioritize immediate problems for current and future adopters. It also opens a new door for end users to get involved with the project, sharing with the committee what they’re seeing in their own systems today, and what they’d like to see in the future.
There was no service mesh before Linkerd. Buoyant coined the term with the launch of its open source network proxy platform in 2016 – about the same time that Kubernetes began to gain momentum – and was adopted as a hosted project within the Cloud Native Computing Foundation (CNCF) in 2017.
A service mesh routes requests between microservices, acting as a dedicated layer for managing, controlling, and monitoring service-to-service communication within an application, and makes a power couple when working with a container orchestration platform like Kubernetes.
Naturally, this caught the attention of Kubernetes creator Google, who jumped on the service mesh trend when it, IBM, and Lyft launched Istio in 2017. Istio was established to provide developers with visibility into microservices without the need to change application code. At the time, Istio was lining up in a similar fashion to be the de facto service mesh implementation, especially for Kubernetes-based container deployments.
That was before Google snubbed the open source community with its decision to dock the Istio service mesh project within the newly formed Open Usage Commons (OUC) group. The space has since stalled as vendors and organizations have worked through the licensing impact of Google’s decision.
“Google and IBM and the Istio kind of vendors have poured a tremendous amount of marketing money into that project trying to make it happen, and what’s been most remarkable, in my view, is that it hasn’t seemed to have paid off,” Morgan said. “Instead, Istio spawned this whole service mesh ecosystem with all these projects that all sound the same, and meanwhile, Linkerd’s over here in the corner with a fraction of the funding, a fraction of the marketing investment, but still getting more users every day.”
However, it’s worth noting that Buoyant remains the main source of code commits to Linkerd. A recent Stackalytics report showed that Buoyant engineers are by and large the most active contributors to the project with 991 commits, representing 80.4% of the total number.
The same goes for Istio, though to a lesser extent, as Google is the top contributor to the project with 1705 commits, representing 53% of the total, according to the report.
While the service mesh space remains messy, the underlying technology continues to solidify. Many of the most widely used service mesh platforms are actually user planes running on top of the Envoy data plane.
Istio’s success has been bolstered by its link to the Envoy service proxy. Envoy was originally created by Lyft in 2015. It was developed as a service mesh substrate that provides common utilities such as service discovery, load balancing, rate limiting, circuit breaking, stats, logging, and tracing to heterogeneous application architectures. Basically, Envoy acts as the data plane, while Istio is the control plane.
Unlike Istio, Linkerd uses its own proxy. Morgan said this was because Envoy is complex, likening Envoy to a general purpose Swiss Army knife.
“What we needed with Linkerd is not a Swiss Army knife, we needed a needle, something very small, very thin, very light,” he explained. “And that’s why we ended up investing in Linkerd2-proxy. It doesn’t even have a good name, it’s not this general purpose thing, it’s just this very specific tool that we needed to sit at the sidecar level to be really light, really fast, and most importantly, really simple. Ultimately, simplicity is the thing that determines whether the adopter of the service mesh can actually run this thing feasibly in production or do they need a team of people to maintain it.”
Morgan said it is because of this simplicity that the majority of Linkerd adopters today are coming from Istio. “They started with Istio, got the value prop of the service mesh, and they were like, ‘wait a minute, this just can’t be right, it’s really complicated, is there something else?’” he said. “It’s not necessarily my preferred way of getting adopters, but it seems to be working for us.”