Service Mesh Interface(SMI)

3 min readSep 6, 2020

Introduction

With huge enterprise interest in Service Mesh technologies, it's no surprise industry has seen exponential growth in the new offerings in this area. Enterprise has to choose between available Service Mesh offerings, which can sometimes result in vendor lock-in. So it’s time to have a Service Mesh Interface(SMI) specification which will help to standardize, build portability and interoperability between different vendor offerings. Keeping this in mind Microsoft and other leading Cloud Providers introduced Service Mesh Interface(SMI) specification for Kubernetes in 2019 KubeCon (CNCF Cloud Native Conference). Quickly SMI has been adopted as CNCF sandbox project. In this story I will highlight the goal of SMI, the main components(APIs), and key players and technologies behind it. If you are new to Service Mesh, highly recommend you read my story on Service Mesh here.

Service Mesh Interface(SMI) Goals:

Provide a common, portable set of service mesh APIs which a Kubernetes user can use in a provider agnostic manner.
Provide a standard interface for service meshes on Kubernetes
A basic feature set for the most common service mesh use cases
Flexibility to support new service mesh capabilities over time
Space for the ecosystem to innovate with service mesh technology

SMI Components

The SMI is specified as a collection of Kubernetes APIs via Kubernetes Custom Resource Definitions (CRD) and Extension API Servers. These APIs can be installed onto any Kubernetes cluster and manipulated using standard tools. In its current version Specification includes the following four APIs:

Traffic Access Control —

The Traffic Access Control API describes a resource to configure access to specific pods and routes based on the identity of a client for locking down applications to only allowed users and services.

Traffic Split —

The Traffic Split API describes a resource to incrementally direct percentages of traffic between various services to assist in building out canary rollouts.

Traffic Specs —

The Traffic Specs API describes a set of resources to define how traffic looks on a per-protocol basis. These resources work in concert with access control and other types of policy to manage traffic at a protocol level.

Traffic Metrics —

The Traffic Metrics API exposes common traffic metrics for use by tools such as dashboards and auto scalers.

SMI Key Players

Below is a list of key Service Mesh offerings that have included support for SMI specification.

Consul Connect*: service segmentation (consul.io/docs/connect)
Flagger: progressive delivery operator (flagger.app)
Istio*: connect, secure, control, observe (servicemeshinterface/smi-adapter-istio)
Linkerd: ultralight service mesh (linkerd.io)
Maesh: simpler service mesh (mae.sh)
Meshery: the service mesh management plane (layer5.io/meshery)
Rio: application deployment engine (rio.io)
Service Mesh Hub: unified dashboard (solo.io/products/service-mesh-hub)
Open Service Mesh: lightweight and extensible cloud-native service mesh (openservicemesh.io)

Final Thoughts

The growth and success of a new technology are about developing standards that help widen adoption and participation. Having standards and specifications helps build healthy competition and more choices for the Enterprises. This will also lead to innovation and new features that can be leveraged across different vendor offerings. Service Mesh is a growing area and having a standard specification is the right move for this technology. This is still a new specification on the path to playing an important role in the service mesh industry.

Disclaimer: This is a personal blog. The opinions expressed here represent my own and not those of my current or any previous employers.