Updated January 12, 2018
Linkerd, a project hosted by The Cloud Native Computing Foundation, is an open source service mesh for cloud-native applications. Created by Buoyant founders William Morgan and Oliver Gould in 2016, Linkerd brings reliability, security, and flexibility to cloud-native applications without requiring complex integration.
Linkerd is the most widely deployed service mesh in the world, and has been in production for more than 18 months. It has powered trillions of requests at companies like Salesforce, Paypal, Expedia, FOX, and AOL.
The service mesh is a critical component of the cloud native stack. Application uptime and site reliability for cloud native applications fundamentally depends on runtime service-to-service communication. Linkerd allows operators to manage that communication at scale, improving application reliability without tying it to a particular set of libraries or implementations.
Companies around the world use Linkerd in production to power their software infrastructure, including Salesforce, Paypal, Expedia, FOX, AOL, Monzo, CreditKarma, Zooz, ForeSee, Olark, Houghton Mifflin Harcourt, the National Center for Biotechnology Information, Douban, NextVR, and many more.
Linkerd provides a consistent, uniform layer of visibility, reliability, and control across a microservice application. It adds global service instrumentation (latency and success rates, distributed tracing), reliability semantics, (latency-aware load balancing, connection pooling, automatic retries and circuit breaking), and security features such as transparent TLS encryption. Linkerd integrates directly with orchestrated environments such as Kubernetes (example) and DC/OS (demo), and it supports a variety of service discovery systems such as ZooKeeper, Consul, and etcd.
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. Its goal is to move service communication out of the realm of the invisible, implied infrastructure, and into the role of a first-class member of the ecosystem—where it can be monitored, managed and controlled. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
The service mesh is a networking model that sits at a layer of abstraction above TCP/IP. It assumes that the underlying Layer 3/Layer 4 network is present and generally capable of delivering bytes from point to point, though it does not assume perfect reliability.
Rather than packets and connections, the service mesh operates at the level of requests and services. The service mesh has a significant goal beyond “just move the data”: it provides a uniform, application-wide point for introducing visibility and control into the application runtime.
In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior.
Web applications have had to manage the complexity of service communication since the early 2000s, and the origins of the service mesh model can be traced in the evolution of these applications over the past decade and a half. With cloud native, service mesh functionality has shifted to the networking layer.
Istio is an open platform to connect, manage, and secure microservices. Linkerd is an open source service mesh for cloud native applications. Istio and Linkerd can work together, with Istio acting as a control plane across Linkerd instances.
Linkerd’s Istio integration is experimental and currently supports routing rules, ingress, egress, and metrics. Support for fault injection, destination policy, route policy, ACLs, and auth are coming soon.
Linkerd and Conduit are both open source service meshes and have the same goals: to add reliability, security, and flexibility to cloud native applications by transparently managing the runtime communication between services.
While Linkerd supports a wide variety of environments (including Kubernetes, Mesos, Consul, and ZooKeeper), Conduit is explicitly focused on Kubernetes. Kubernetes users will find that Conduit requires significantly fewer resources and significantly less configuration overhead than Linkerd.
For educational, technical and case study presentations about Linkerd, check out:
As a CNCF hosted project, Linkerd is part of a neutral community aligned with technical interests to help companies move to cloud native deployment models and help developers deliver on the promise of microservices and cloud native applications at scale. As Linkerd grows, CNCF is helping build its community, marketing and documentation efforts. CNCF also assists with marketing and documentation efforts. For more, read “Linkerd joins CNCF.”
Linkerd is an incubation level project, under the CNCF Graduation Criteria v1.0. The CNCF Graduation Criteria by the TOC provides every CNCF project an associated maturity level of either inception, incubating or graduated, which allows CNCF to review projects at different maturity levels to advance the development of cloud native technology and services. As an incubating project, Linkerd must have documentation that it is being used successfully in production by at least three independent end users, have a healthy number of committers, and demonstrate a substantial ongoing flow of commits and merged contributions.
Linkerd competes with Envoy, in the sense that both projects are L5/L7 network proxies with some overlap in functionality. However, the deployment models are typically different, with Linkerd acting as a full-fledged service mesh, and Envoy requiring an additional control plane (e.g. Istio) to act as a service mesh. Additionally, Linkerd features commercial support and has seen wide production usage across a variety of environments.
The cloud native ecosystem is still nascent and quickly evolving. CNCF recognizes that many promising technologies are emerging, some better suited for certain workloads, use cases or environments. CNCF’s goal is help many rising technologies mature. In this respect, we expect to have overlapping projects in some cases.