As IT organizations begin to deploy microservices at scale on Kubernetes clusters, many of them are discovering the need for a service mesh to more easily manage them. Buoyant, at the Kubecon + CloudNativeCon 2017 conference, unveiled what it describes as the first service mesh for Kubernetes clusters.
Company CEO William Morgan says the Conduit open source project builds on the work Buoyant and the open source community did to create Linkerd, a service mesh for Docker containers that is now one of the projects administered by the Cloud Native Computing Foundation (CNCF). Conduit, however, is a more streamlined implementation of service mesh that is significantly faster. Buoyant claims a single Conduit proxy has a sub-millisecond p99 latency.
The concepts behind a service mesh are not especially new. Ever since the dawn of service-oriented architectures (SOA) there’s been a need to manage collections of individual services using, for example, a proxy server. Microservices based on containers make that requirement a more pressing challenge because of the sheer number of microservices being deployed and maintained. Arguably, the main difference between a service mesh and previous approaches to this problem based on web services architectures is that a service mesh is much lighter-weight in terms of the resources it consumes.
Morgan says that in the case of Conduit, that goal was achieved by deciding to develop the service mesh using RUST, a programming environment for writing secure applications in memory that enable an isolated Conduit proxy to only require 10MB of memory, and the control plane in Go. The approach means that issues such as cyberattacks based on buffer overflows are a nonissue, he says.
Conduit relies on Kubernetes to provide authorization and authentication and ensure that transport layer between services is encrypted. Conduit is also designed to integrate with third-party logging and audit tools to provide greater visibility into microservices deployed on Kubernetes. Developers can also make use of gRPC plugins to extend the functionality of Conduit.
Buoyant is pledging to continue to support and develop Linkerd. But Morgan notes that as the open source community continues to gain more expertise with service meshes, it is probable there will be multiple alternatives for some time to come. In fact, Google, IBM and Lyft are backing an alternative service mesh dubbed Istio.
Morgan says there will always be a need for service mesh spanning multiple container orchestration engines. But for organizations that standardize on Kubernetes there will be a preference for service mesh specifically optimized for that class of container clusters. Rather than replacing Layer 3 and Layer 4 networking technologies, Morgan says a service mesh is focused squarely on application services.
Building, deploying and managing microservices at scale is not for the faint of IT heart. But as technologies such as service meshes mature, many of the frameworks that IT organizations relied on to manage application services are being reinvented in ways that makes them applicable in a microservices architecture. The issue now is determining which of the various service meshes available best fits the strategic direction any IT organization sees itself heading next.