Istio vs Service Mesh Interface

Question

I would have a conceptual question. I can not figure it out how Istio and Service Mesh Interface come together.

Service Mesh Interface' goal is to have a standard way of defining service mesh related features (traffic split, metrics collection, etc..). To able to to this, Service Mesh Interface provides different CRDs (for example: metrics.smi-spec.io).

However, Istio has its own CRDs and API extensions.

I am confused a bit. Is Istio using under the hood the APIs (for example the metrics.smi-spec.io) provided by the Service Mesh Interface? Or what is the connection between these two?

Answer 1

SMI brings in a minimal set of specification as a foundation of a service mesh. But despite that they abstain from describing SMI as

"the extent of what it means to be a Service Mesh, but rather a generally useful subset."

Tools (which should be) implementing these specs (like console, linkerd, istio, aws-appmesh) are not limited to stay in these "boundaries". Every tool may also implement other specs and furthermore create its own CRDs.

Since SMI is a relatively new specification there is currently not enough impact. But there are also different interests against SMI. For this we have to know who is behind all these tools and specs.

Istio is the current de facto standard for service meshes with Google & RH/IBM behind it. SMI however is an initiative led by Microsoft. It is hardly surprising that vendors of a de facto tool are not happy with a socialization of the principles their tool uses, since it broadens the market and supports competition.

So yes and no: according to SMI istio (does not but) should implement their provided interfaces.

But currently they have their own implementations. E.g. for traffic access/split etc. (defined by SMI) istio has its own CRD-creations like VirtualServices, DestinationRules.

Nonetheless SMI provides an adapter (smi-adapter-istio) to bridge the current gap between their specification and istios implementation.

To compress all that into a few words: SMI wants to become (or already is) a CNI spec and standardize the service mesh landscape. Istio is the current de facto standard and is not happy with that.