Linkerd Update Simplifies Service Mesh Extensions
The maintainers of the open source Linkerd service mesh project today announced the release of a 2.10 update that makes it simpler to extend the platform.
Linkerd, originally developed by Bouyant, provides a lighter-weight alternative to rival service mesh offerings, such as Istio, for managing application programming interfaces (APIs) in a Kubernetes environment. In fact, with this latest release, Linkerd now weighs in at under 200mb at startup, down from about 500mb in the previous release.
William Morgan, Buoyant CEO, says the latest release is designed to support extensions to the platform that an IT team can create and deploy as they see fit. That approach ultimately allows each IT team to decide how large they ultimately want their service mesh to become, versus having to deploy a service mesh designed for a web-scale company that can afford to hire a small army of site reliability engineers (SREs) to support it, Morgan says.
As part of that effort, Morgan notes that some capabilities in the previous release of Linkerd have now been made available as an extension that IT teams can optionally employ.
The initial set of new Linkerd extensions includes visibility for deploying tools such Prometheus and Grafana; multi-cluster for cross-cluster communication and jaeger for deploying a distributed tracing collector and associated user interface.
This release also extends Linkerd’s seamless, secure multi-cluster support to all TCP connections along with opaque ports to make it easier to apply mTLS to all protocols without having to manually configure them.
Finally, Linkerd enables the Linkerd community to build Linkerd-specific operators and controllers without having to modify the core Linkerd command line interface (CLI).
Morgan said the simpler service mesh becomes to deploy, the more likely it is a development team will employ one to manage application connectivity. Today, most IT teams are employing either proxy software, an API gateway or an ingress controller to manage APIs. A service mesh provides a higher level of abstraction for managing hundreds of APIs.
Most recently, the Linkerd community formed a steering committee made up of end users that employ the service mesh to manage their APIs rather than relying on a committee made up of IT vendors that often have conflicting agendas. Istio was originally developed by Google and IBM, and remains under Google’s control rather than being donated to an industry consortium. Linkerd, in contrast, is being developed under the auspices of the Cloud Native Computing Foundation (CNCF). The CNCF also controls a Kuma service mesh originally developed by Kong, Inc. Organizations using Linkerd in a production environment include Microsoft, H-E-B, EverQuote, HP, Inc. and Elkjøp.
It’s still early days as far as service meshes are concerned. Most organizations are still working to master Kubernetes clusters. It’s even probable many organizations will wind up deploying multiple types of service meshes.
Regardless, it’s clear service meshes will soon have a profound impact on IT, as organizations reevaluate how microservices, and their associated APIs, are managed across heterogeneous networks.
