Service mesh options for Kubernetes keep multiplying. There is now Istio, Linkerd, Consul and new entrants including AWS App Mesh. Naturally, each service mesh solution has its own unique approach. Thus, problems could arise if organizations attempt to navigate between service meshes or operate multiple service meshes simultaneously across multi-cloud environments.
Enter SMI. Solo.io recently partnered with Microsoft and others to introduce Service Mesh Interface (SMI), a vendor-agnostic standard interface for Kubernetes service meshes. We’ve already seen SMI’s use in Solo.io’s SuperGloo project and Service Mesh Hub. But is the rest of the industry ready for a standard service mesh API specification?
Let’s see why Kubernetes service meshes need an interface standard at all. In this post, we go a little deeper to pick apart the details of SMI and explore some sample code. We’ll outline potential benefits and drawbacks and consider how others in the service mesh space are responding.
Read more at:
/Service Ventures Team
Comments