Service Mesh Interface
Tags: cloudnative, kubernetes, servicemesh, smi
Published: 2021-05-03 04:13:27

### 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
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/74dzbsuy7v44uombw1jy.png)

### 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](https://github.com/servicemeshinterface/smi-sdk-go/blob/main/hack/update-codegen.sh). 

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:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a57043v7n7xh0v9qip1e.png)


The traffic flow between services, pods, or deploys:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kho37ycz6h06ulp3bakk.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x6p5v0bl1kq6t3wciexd.png)


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

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w8z9qw5ft4qjmpb5ghdd.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ik9pqzltmmr0pmkt0gvg.png)


Comparing the application with traffic metrcis:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6t6rbjx0xagxame42epe.png)


The application architecture with DAG:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yqdwq3kn4vnn4tdptu6t.png)


#### 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](https://layer5.io/service-mesh-landscape#smi). You can get more detail of Service mesh productions.

If you want to get more information, please join the [community meeting of Layer5.io](https://calendar.google.com/calendar/u/0/r?cid=bGF5ZXI1LmlvX2VoMmFhOWRwZjFnNDBlbHZvYzc2MmpucGhzQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20) or if you want to be a contributor please join the [Slack channel](https://meshery.io/community/)

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

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