Linkerd became the first service mesh project to attain graduated status within the Cloud Native Computing Foundation, but that doesn't mean its maintainers are planning a vacation.
The project known now as Linkerd is actually the second incarnation of a service mesh first launched in 2016, built on Java and used to orchestrate virtual machines. Linkerd's creators, some of whom hailed from Twitter, coined the term service mesh at that time to refer to a web of proxy machines that carry out network management functions, overseen by a centralized control plane.
As Kubernetes, microservices and container orchestration overtook enterprise IT infrastructure between 2016 and 2018, the appeal of service mesh grew within mainstream organizations as a way to cope with the complexity of network management in cloud-native distributed systems. Linkerd 2, initially called Conduit, was introduced in 2017 to support Kubernetes-based service mesh.
Other graduated projects within the Cloud Native Computing Foundation (CNCF) include staples of open source cloud native computing, such as Kubernetes itself, etcd service discovery, Prometheus monitoring and Open Policy Agent for governance and security automation. Graduation requires vetting by the CNCF technical oversight committee, which assesses the project's fitness for enterprise use as well as the health of its contributor community.
William Morgan
"They're looking for signs of maturity, and signs of community longevity," said William Morgan, CEO of Buoyant.io, Linkerd's commercial backer. "They're looking for ways to say that if you're an end user and you're adopting this project, can you rely on this being around? Is it worth investing in?"
Linkerd service mesh roadmap targets Istio
Linkerd service mesh maintainers have had to work since 2017 to close technical feature gaps with their biggest rival project in Istio, launched the same year by engineers at IBM, Google and Lyft specifically for Kubernetes.
Four years ago, Istio boasted some advanced security features that Linkerd didn't, such as support for application-level network security policies. Linkerd version 2.10 earlier this year added application-level authentication support, and as of the next version 2.11 release, the project will support application-level authorization policies. These policies will govern network access permissions precisely at the microservice level, rather than tying them more broadly to shared infrastructure components.
Some Istio maintainers are also working on VM support, which other service meshes such as HashiCorp Consul already support. In the coming year, Linkerd's service mesh proxies will also run on virtual machines outside Kubernetes clusters, in a sense bringing the project's history full circle to where Linkerd 1 began.
"The control plane will probably always be bound to Kubernetes, but the mesh will span off-cluster resources," in future versions of Linkerd, Morgan said.
Finally, Buoyant also launched the public beta of Buoyant Cloud earlier this month, joining a growing trend in service mesh SaaS. No general availability date has been set for Buoyant Cloud yet, and Morgan declined to specify how many beta users have signed on.
'A service mesh by breakfast'
Istio still has the largest contributor community among open source service mesh projects and a substantial user base. Despite Istio's early notoriety, however, it has also encountered technical hurdles and the project lost some of its cachet in the open source community after Google decided not to donate it to the CNCF last year.
Linkerd's ease of use, in the meantime, began to win it enterprise users and contributors, including Microsoft and HP. In January, project maintainers established the Linkerd Steering Committee, to broaden the governance of the project well beyond its original creators at Buoyant.
It stands today as a successful grassroots effort.
Linkerd didn't come from a big company with infinite marketing and partnership resources. All the momentum has come from the project itself, word of mouth, and a clear vision for ease of use.
William MorganCEO, Buoyant
"Linkerd didn't come from a big company with infinite marketing and partnership resources," Morgan said. "All the momentum has come from the project itself, word of mouth and a clear vision for ease of use."
Entain, a sports betting corporation in Australia, is typical among Linkerd's recent enterprise adopters. The firm began transitioning to Kubernetes and container-based microservices three years ago to hasten product development but needed to find an easier way last year to maintain the speedy performance of its previous monolith for its sports data trading platform.
Initially, the firm used the native Kubernetes load-balancer to balance gRPC protocol network connections among its microservices, but this became difficult to manage at scale.
"One of the dark, evil aspects of doing Kubernetes and gRPC is the default mechanisms for Kubernetes for load balancing, if you've got a pretty heavy processing application, can burn you pretty easily," said Steve Gray, head of trading solutions at Entain.
Kubernetes was originally designed for web applications, and those have different characteristics than the trading application Entain needed to support. Web apps often disconnect and reconnect, and the Kubernetes load balancer is optimized by default to support that behavior.
Initially, this meant that Entain's steady but heavy gRPC traffic from its trading application was "cooking one server at a time" rather than being spread evenly across the cluster, Gray said.
The lone DevOps engineer on Gray's team was able to modify the load balancer to mitigate this problem. That clearly wasn't going to be sustainable long term, however, as the number of microservices grew to more than 300 spread over thousands of container instances, according to Gray.
"I like to put 100% of my energy into the stuff that makes us unique and interesting, and this was just operational hygiene code, that we shouldn't have to worry about," Gray said.
Entain's DevOps engineer began looking for a service mesh. The Kubernetes load-balancing problem had led to cluster failure already, and the company needed to address the problem quickly. Here, as with many Linkerd users, the project's easy setup won out over the more advanced but complex Istio.
"We did the entire Linkerd conversion in the space of about eight hours for the entire platform in production," Gray said. "[The DevOps engineer] started off in the middle of night, all night, and then by breakfast time, we were going on a service mesh."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
William Morgan
