Buoyant Brings Dynamic Requests to Linkerd Service Mesh Routing
Buoyant today released an update to the open source Linkerd service mesh that makes use of the Kubernetes Gateway application programming interface (API) to add dynamic request capabilities. That capability enables fine-grained control over the routing of individual HTTP and gRPC requests.
In addition, version 2.13 of Linkerd now has a circuit-breaking capability that can be used to dynamically disable overloaded services to provide them the time needed for them to recover.
Buoyant is also adding security and reliability extensions for all Linkerd users via the free tier edition of Buoyant Cloud, a cloud service the company provides for managing instances of Linkerd.
Finally, the company is making available a FIPS-compatible version of Linkerd for government agencies.
Buoyant CEO William Morgan said the Kubernetes Gateway API that was recently added to the container orchestration platform makes it possible to route requests based on HTTP headers, gRPC methods, query parameters or almost any other aspect of the request. This capability, among other things, will enable sticky sessions, user-based A/B testing and canary deployments and the creation of dynamic staging environments.
In general, the Kubernetes Gateway API reduces the amount of configuration code required on a cluster, which Morgan said complements the lightweight approach Bouyant pursued when it initially developed Linkerd as an alternative to more complex service mesh platforms such as Istio.
In addition, service mesh provides a way to manage APIs at scale instead of relying on proxy software or an API gateway alone. More recently, IT organizations have started to appreciate the programmable layer of abstraction that a service mesh creates above lower-level networking and security interfaces. That makes it simpler to provision the mutual Transport Layer Security (TLS) protocol to enable encryption, authentication and identity management.
It’s not clear at what rate organizations are embracing service meshes, but a recent survey from Buoyant finds more than a quarter (28%) of organizations have already swapped out the service mesh platform they initially adopted. Among those that have switched, 80% had been using open source Istio for Kubernetes, now being advanced by Google.
Nearly two-thirds of respondents (63%), however, also note they have yet to deploy a service mesh in a production environment. Another 14% say they have been using one in a production environment for less than six months. The top reason respondents give for employing a service mesh (58%) is the need for end-to-end encryption.
It’s feasible many organizations will wind up employing multiple service meshes. Many developers may prefer Linkerd because it is easier for them to deploy on their own, while some platform engineering teams may opt to deploy Istio to consolidate the management of APIs along with networking and security services at scale.
Regardless of approach, it’s only a matter of time before service meshes become more widely employed in Kubernetes environments. In fact, there is already no shortage of open source and commercial options. The decision as to which one to use will likely come down to the role of the person making the decision as much as the individual capabilities of the service mesh platform itself.
