Containous Unveils Maesh Service Mesh for Kubernetes
Containous today launched Maesh, an open source service mesh optimized for containerized applications running on instances of Kubernetes deployed at the network edge.
Built on top of Traefik, an open source edge router (also known as a reverse proxy service) developed by Containous, Maesh provides an alternative to rival service mesh platforms that are either too heavy to implement at the network edge, says company CEO Emile Vauge.
Maesh monitors and traces application communications within Kubernetes clusters to optimize internal traffic, visualize traffic patterns and secure communication channels. Maesh also supports HTTP and TCP along with traffic management capabilities such as load balancing, retries and fail-overs, circuit breakers and rate limits, and access controls. Maesh is also Service Mesh Interface (SMI)-compliant, a proposed specification for service mesh interoperability on Kubernetes clusters.
The challenge with existing service meshes such as Istio is they are too heavyweight to be applied in edge computing applications, says Vauge. Traefik has already been downloaded 1 billion times, so its ability to manage traffic is already proven, he notes, and Maesh simply extends those capabilities by adding a service mesh.
While not every instance of Kubernetes is going to have enough microservices deployed on it to require a service mesh, Vauge says there is now enough critical mass to warrant employing a service mesh to provide a control plane for microservices on top of a Kubernetes cluster to optimize application performance.
It’s too early to say how the service mesh wars will play out. The Cloud Native Computing Foundation (CNCF), which oversees the development of Kubernetes and associated technologies, thus far has embraced only Envoy as an open source proxy service and Linkerd as a service mesh. In the absence of a single service mesh standard, some organizations may wind up supporting multiple service mesh platforms running on different distributions of Kubernetes. It’s also not clear how the control plane enabled by a service mesh might be extended across multiple Kubernetes clusters. What is clear is that the managing of microservices on Kubernetes clusters has the potential to become very complex, especially as organizations look to increase utilization rates of the infrastructure on which a Kubernetes cluster is deployed.
It may be a while before service meshes for Kubernetes platforms routinely are deployed in production environments. However, the less certainty there is when it comes to service mesh platforms, the less excited enterprise IT organizations will be about potentially getting locked into an open source project that dies on the vine while the rest of the community moves in a different direction. In the meantime, IT organizations would be well-advised to keep an eye on a service mesh debate that is just now beginning to take place in earnest.
