Buoyant Unfurls Beta of Linkerd Managed Service
Buoyant today added a service for managing instances of the open source Linkerd service mesh that is based on agent software it has developed.
Buoyant CEO William Morgan says that while Linkerd is easier to deploy than other service mesh offerings, there are many organizations that would still prefer to rely on a managed service to manage a service mesh on an ongoing basis if for no other reason than to conserve scarce internal IT resources.
Service meshes are gaining traction in Kubernetes environments as both a means to simplify the management of application programming interfaces (APIs) and abstract away the underlying complexity associated with programmatically invoking networking services and simultaneously encrypting connections.
Linkerd relies on a set of “micro-proxies” written in the Rust programming language to ensure scalability without introducing undue complexity to the user. The managed service provided by Buoyant, available in private beta, is an extension of a Buoyant Cloud platform that provides a control plane for managing multiple instances of Linkerd. That service automates tasks such as upgrades, installations and rollbacks.
Competition between service mesh platforms revolves around two core issues. The Linkerd service mesh is lighter-weight than, for example, Istio. That makes it simpler for a developer to implement. The other issue is to what degree a service mesh might need to be applied to both cloud-native and legacy application environments. Linkerd and Istio are optimized for Kubernetes clusters. Linkerd is a project managed under the auspices of the Cloud Native Computing Foundation (CNCF), which is also considering a petition for the open source Istio projects to also become a service mesh advanced alongside both Linkerd and Kuma, a service mesh that runs across both Kubernetes clusters and virtual machines.
A recent survey published by 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 the open source Istio platform. It’s still early days as far as service mesh adoption is concerned—nearly two-thirds of respondents (63%) say 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.
Overall, survey respondents identified ease of use and installation (25%), the extent of feature set (20%), simplicity (10%) and resource consumption (10%) as the top criteria they consider for implementing a service mesh.
It’s not clear when service mesh adoption will cross the proverbial chasm in the enterprise, but as Kubernetes clusters become more widely adopted, the number of organizations that need to employ a service mesh as an alternative to proxy software or a traditional API gateway will increase. Many of those organizations may even find themselves employing multiple types of service meshes as different projects evolve. In the meantime, competition among service mesh providers looking to rally early adopters to their platform will only intensify in the months ahead.
