The service mesh itself is very new (since 2016), so it does not have much history. A push for an SMI specification has been done to guide different service mesh providers to adhere to a well-defined API that will allow end users to easily change provider without being locked down to one implementation. The SMI specification fulfills the following key features:

• Provides a standard interface for meshes on Kubernetes
• Provides a basic feature set for common mesh use cases
• Provides flexibility to support new mesh capabilities
• Applies policies such as identity and transport encryption across services
• Captures key metrics such as error rate and latency between services
• Shifts and weighs traffic between different services

SMI defines a set of APIs, such as a collection of Kubernetes Custom Resource Definitions (CRD) and extension API servers, which will allow mesh providers to deliver their implementation.

Think of SMI as an abstract layer on top of different service mesh providers such as Istio, Linkerd, and Consul. The goal of using SMI APIs and seamlessly interchanging the underlying service mesh provider can happen in one of the following two ways:

•  Service mesh providers start using SMI APIs and provide their implementation.
• Build Kubernetes operators to translate SMI into their native APIs.

 The SMI specification is evolving and maintained at https://github.com/deislabs/smi-spec. At the time of writing, the specification is only 2 months old, and it is expected to gain momentum due to the participation of different service providers so that it can arrive at a set of APIs that can then be an abstract layer or a direct API call. 

The specification starts with the following topics, but the list will grow in the future:

• Traffic access control: Configure access to routes based on the identity of a client.
• Traffic specs: Manage traffic at the protocol level.
• Traffic split: Split or mirror the traffic between two services for A/B testing or Canary rollout.
• Traffic metrics: Expose common traffic metrics for use by tools.

The SMI is intended to be a pluggable interface similar to other core Kubernetes APIs, such as NetworkPolicy, Ingress, and CustomMetrics.