Service Mesh Interface

What's the Service mesh interface(SMI)?

A standard interface(Not only specification but also implement) for service mesh features on Kubernetes. To be honest, I do not care about who built this command standard, so, I would not introduce more on this.

Why we need the Service mesh interface?

There too many service-mesh productions have been come from the community or private company. If we release a command standard, the end-user can with the standard format configuration work on different service-mesh production.

As we know, this makes more sense. The user binding by the provider is not good news.

What are the features provide by SMI?

• A standard interface for service mesh features on Kubernetes
• Define the basic feature set for the most common service mesh use cases

Features(document)	Feature(implement)	Crds	Source-code	Description
Traffic policy	traffic access	access.smi-spec.io v1alpha3	https://github.com/servicemeshinterface/smi-sdk-go/tree/main/pkg/apis/access	Apply policies like identity and transport encryption across services
Traffic telemetry	traffic metrics	metrics.smi-spec.io v1alpha2	https://github.com/servicemeshinterface/smi-sdk-go/tree/main/pkg/apis/metrics	Capture key metrics like error rate and latency between services
Traffic management	traffic split	split.smi-spec.io v1alpha4	https://github.com/servicemeshinterface/smi-sdk-go/tree/main/pkg/apis/split	Shift traffic between different services

Notice
There exist traffic spec object. This object is a corporation of traffic access these two features results on Traffic policy

Service Mesh Interface Compliance

For development

As you can see, this project above uses the code-generator. In my personal opinion, this project is a simple example project which told us how to use code-generator of Kubernetes.

And also includes:

• client-gen
• informer-gen
• lister-gen

Every developer of the Cloud-native industry should learn how to use that. But this may not good news for the software industry if all developers dependent on those automation scripts.

The situation of using service-mesh of my

We all know Service-mesh is complex and has so many features, but I believe that we only just need one or two features of service-mesh in many situations.

So, we should confirm that after the applications were deployed on Kubernetes, what's the most important for us.

• mTLS communicate between applications?
• Applications metrics without change code?
• The traffic flow working status?
• Out-of-box A/B or canary deploy?
• More flexible traffic management?

We can not say that we need them all without thinking and testing. Because the cost value is deep and not professional. If Cloud-native is not decreasing the cost value, it will lose its value.

So, I just make the choice to tack traffic flow without changing the application's code.

The out-of-box feature we can use to monitor what happened in the cluster:

The traffic flow between services, pods, or deploys:

The out-of-box feature of tracking the traffic flow:

Comparing the application with traffic metrcis:

The application architecture with DAG:

Subconclusion

Those out-of-box features can solve the problems of daily working because you can see everything of your application traffic flow. Even though you are not familiar with Cloud-native. And we do not need to enable the traffic management feature, which can increase the complexity in some situations.

Conclusion

When I try to learn how to use istio+ingress or linkerd2+ingress, lots of things make me confused, but Linkerd2 makes things easier and this my personal idea may not have any sense to other people.

So, on service-mesh, I believe we should control the cost value and focus on the small and simple, not the powerful and complex situation and design.

But the common standard of service-mesh is a good way to decrease learn the cost of the end-users and give more community a chance to do more useful tools(I guess there will exist tools that can auto-create manifest for your application traffic specification and policy soon.)The more active and low technology threshold ecosystem I guess.

Finally

The page cover is my dog called Happy, and he is 13 years old, so smart he is.

The picture source from layer5.io community's smi-landscape. You can get more detail of Service mesh productions.

If you want to get more information, please join the community meeting of Layer5.io or if you want to be a contributor please join the Slack channel

SMI official website:
https://smi-spec.io

And there a service-mesh comparison website includes more detail:
https://servicemesh.es