Service mesh helps solve application-networking challenges when going toward a cloud-native architecture, specifically one that favors smaller, cooperating services like a microservices architecture. As we meet with cloud native technology end users across the world, we find people are indeed putting service mesh into production and starting to see the benefits of doing so. At the same time, we’re seeing the signs that the industry needs a standard service mesh API.
Here are a few reasons that we believe a service mesh API is necessary:
- Currently emerging, differing implementation approaches
- Service mesh is a lower-layer; will build on top and need stability
- Federation of mesh implementations where necessary
- Implementation upgrades
Different implementation approaches
The world of service mesh is just heating up. We have implementations that have been around for a bit like Istio and Linkerd, we have new entrants like AWS App Mesh and Consul, and we have upcoming implementations from other vendors on the not-so-distant horizon. Each of these meshes has their strengths and weaknesses but one thing is for sure: the service mesh world is turbulent and a winner is far from decided.
Adding to this picture is the fact that quite a few organizations already have something that “looks like a service” mesh, likely something they built, and they cannot just tear it out and start from scratch. If you were to go all in on one service mesh at this point in time, you might find that you’ve picked the wrong one. Having a unified API allows you to hedge your bets and start with one implementation and possibly migrate to a different one if needed.
Extending service mesh
Just like Kubernetes is for applications, service mesh is another lower level piece of plumbing that itself should not be directly exposed to developers. Developers should interact with a “platform” of automation tools and workflows that may end up driving the underlying components like Kubernetes and service mesh. In this case, the platform ends up being a set of “glue” technology that configures the pipes and plumbing in order to deliver a platform capability. Service mesh gets 80% of the stated goals of security, observability, resilience and so on. The last 20% needs to be integrated and adapted into an organization’s platform. Building this valuable last-mile, 20% code can only be successful if the underlying 80% is stable and consistent. A nicely defined API at this intersection would help achieve that.
Service-mesh implementation federation
With the multitude of service-mesh implementations currently available and soon to come, you may run into a legitimate situation where multiple mesh technologies are either desirable, economically the right choice, or cannot reasonable be avoided. For example, let’s say you went all in on a single mesh technology today (say, Linkerd). You deploy your applications on premises with this one mesh, build up your workflows around its assumptions and implementation details. Then you decide to go all-in on AWS. You could take Linkerd with you and deploy that (which would be a fine idea!) but AWS offers its service mesh, App Mesh, available across EC2, EKS, Fargate, etc and for free. Oh, and it’s control plane is 100% managed for you. This may be a good reason to take your existing mesh investment and federate it with AWS App Mesh and leverage a unifying mesh API to build your workflows against.
Implementation upgrades
Let’s say you go all in with a single service mesh and then wish to upgrade. As we’ve established earlier, the service-mesh market is still emerging: so are any specific implementations. For each point release from any one mesh implementation, we can expect to see API/assumption changes as well as instability. As these APIs evolve over each release, you need a stable way to consume a mesh and upgrade. Building against a stable, mesh-independent interface can help with this.
How we’re approaching this problem at Solo.io
We’ve been anticipating this situation with the service mesh ecosystem for some while. As we continue to test and confirm our hypotheses against the tremendous community and customer interest/conversations we’ve been having, we’ve been putting into action our plan for how to deal with this. SuperGloo is an open-source project where we are building this unified API for service mesh as well as building on top of this and providing service mesh management capabilities.
With SuperGloo, we’re focusing on a unified API around things like traffic shifting, routing control, unified mesh ingress, security, multi-cluster and more. At the moment, SuperGloo supports Linkerd, Istio, AWS App Mesh with Consul support forthcoming shortly as well as an SDK for adding your own mesh implementations (or to make it easy to quickly add others in the future). This week, we also announced a central management/repository for service mesh called the Service Mesh Hub built upon SuperGloo that helps manage multiple meshes with associated extensions.
With how fast the service-mesh ecosystem is moving, and with #KubeCon right around the corner, keep a close eye on this space!
Originally published at https://medium.com on May 18, 2019.
