The service mesh architecture, in which monitoring and controlling communication among microservices is implemented as a dedicated layer, independent from the microservices themselves, is gaining momentum among cloud users. Today, users can choose from several service mesh implementations, including Istio (backed up by Google, IBM and Lyft), Linkerd and Linkerd2 (CNCF projects), Consul Connect (from Hashicorp), NGINX mesh, Kong mesh and more. Most recently, at Re:Invent last week AWS introduced its own service mesh, the AWS App Mesh. It is now clear that the service mesh is going to be part of the cloud-native ecosystem in the following years.
The vision: multi-mesh
We at Solo believe that in the near future, many companies will find themselves working with multiple instances of service mesh, and that in many cases this will involve several different service mesh implementations. Possible multi-mesh scenarios include:
- Different groups within the same organization may favor different service mesh offerings, which best fit their specific needs.
- Users may find that one service mesh works better for their on prem workloads, while another mesh is a better fit for their public cloud services.
- Users who work with a multi-cloud may, for example, prefer to work with the AWS App mesh for their services that run on the AWS cloud (where this service is offered free of charge), but use Managed Istio for the ones that run on the Google cloud.
- Users that select — for some reason — to migrate from one service mesh implementation to another may transiently work simultaneously with the ‘old’ and ‘new’ mesh.
The dream multi-mesh: a wish list
We believe that a user would benefit from the experience of a single service mesh, even when they have multiple service meshes under the hood. Our dream multi-mesh will be managed, controlled, and monitored as a single entity. Third-party tools and plugins will be controlled by the multi-mesh, which will transparently apply it to any managed mesh. Importantly, installation, configuration and operation of the multi-mesh must be simple and straightforward, completely hiding the underlying complexity.
To realize this vision, a multi-mesh will have the following properties.
- A flat mesh, which handles communication among services within a mesh and across meshes on equal footing.
- A single pane of glass to monitor and manage all your service meshes, clusters and services.
- Straightforward installation process, in which different meshes are configured to work together.
- A single API for controlling mesh functionalities (such as encryption, telemetry and tracing) and third-party tools that will work with all meshes, even if they come from different implementations.
- Amalgamated logging and tracing, providing a unified view of the application life-cycle across meshes.
- Ability to dynamically group service meshes, e.g to separate testing from production.
SuperGloo will help realize the multi-mesh vision
Last week we at solo announced SuperGloo, the service mesh orchestration platform. SuperGloo is an opinionated abstraction layer, aimed to simplify the installation, management, and operation of any service mesh. At the time of our announcement, SuperGloo supported Istio, Linkred2 and Consul. Today — only a few days after its announcement — we are happy to add the AWS App Mesh to this list.
SuperGloo provides a platform for integration of different service meshes. Today, SuperGloo includes the following features:
- Single-line command for installing any supported service mesh.
- Single-line command for launching advanced features, such as encryption and tracing, on any service mesh.
- An abstraction layer that can be used by any third-party tool as a single interface to any service mesh.
- Integration with Ingress controllers for combined management of north/south and east/west traffic.
SuperGloo is an active open-source project, and we invite the community to join us in extending it to provide the support for true multi-mesh. Please check out the SuperGloo GitHub repo, where you can also find our roadmap.