<p>I would say that <a href="https://istio.io/" rel="nofollow noreferrer">Istio</a> is the de facto standard for Service Mesh. It is launched by both Google and IBM.</p>

<ul>
<li><p><a href="https://cloud.google.com/blog/products/networking/welcome-to-the-service-mesh-era-introducing-a-new-istio-blog-post-series" rel="nofollow noreferrer">Welcome to the service mesh era: Introducing a new Istio blog post series</a></p></li>
<li><p><a href="https://www.ibm.com/blogs/cloud-computing/2018/07/31/ibm-google-open-community-istio-microservices/" rel="nofollow noreferrer">IBM, Google Cloud and the open community launch Istio 1.0 to bring microservices to the enterprise</a></p></li>
</ul>

CC BY-SA 4.0
2019-01-28T20:14:56.197Z
2019-01-28T20:14:56.197Z
Jonas
<p>In general you are going to find the best support for “an X” on Kubernetes by looking at what “X” projects are members of the same software foundation so governed by the same organisation. Kubernetes is part of the <a href="https://www.cncf.io/" rel="nofollow noreferrer">Cloud Native Computing Foundation</a> so you should study what <a href="https://www.cncf.io/projects/" rel="nofollow noreferrer">“Xs” it offers</a>. In the case of service mesh CNCF has Linkerd. </p>

<p>At this point in time though as other answers point out there is a lot of momentum around itsio. This <a href="https://istio.io/docs/concepts/what-is-istio/#envoy" rel="nofollow noreferrer">uses Envoy</a> which is a top level CNCF project to actually shape the traffic between your containers. That is reassuring as we would not expect k8s to suddenly break Envoy at a minor release so we might expect itiso to be able to keep up to date with k8s. That’s a guess though. </p>

<p>You should also consider whether there is a “service mesh like” tech for that stack you use already. If for example you are a Java shop doing microservice like a lot of big firms then you are probably using spring boot and spring cloud. In which case spring cloud already had a bunch of components that offer the same benefits as a mesh but do it in a more traditional way (libraries embeds in your app). By way of example <a href="https://access.redhat.com/documentation/en-us/reference_architectures/2017/html-single/spring_boot_microservices_on_red_hat_openshift_container_platform_3/index" rel="nofollow noreferrer">here</a> is an architecture demo of how to port a java spring cloud airline booking microservices demo app onto openshift Kubernetes. In that doc they mention itsio but actually they stick with spring cloud ribbon, eureka and zuul. Spring cloud also has distributed tracing etc. </p>

<p>This then leads to three choices if you’re a java shop. In order of more conservative first:</p>

<ol>
<li>If your writing Spring Boot microservices stick with Spring Cloud. Developers can run it all as “just java” in their laptop and will take responsibility for it all working well on k8s as it’s “obviously” something they should master. </li>
<li>Deploy Linkerd as it’s an established CNCF project so the most mature option </li>
<li>Deploy itsio which went to v1.0 relatively recently but is likely to mature fast. </li>
</ol>

<p>The smart money if you have the time is to try out all three. </p>

CC BY-SA 4.0
2019-01-29T08:45:35.180Z
I should add that there is a rule of thumb “use smart clients and dumb pipes” which things like itsio appear to violate. This means a friend who has been the service manager at a very large and mature microservices platform is suspicious of new service mesh technologies. I have tried to put the trade offs into this answer in particular if you deploy “magic pipes” and they give errors your dev team is going to expect you to fix it every single time. If you give them dumb pipes (vanilla k8s) and let them install libraries into they apps that do “smart client logic” they will take ownership.
simbo1905
CC BY-SA 4.0
2019-01-29T08:32:32.130Z
2019-04-03T02:37:44.727Z
2019-04-03T02:37:44.727Z
simbo1905
<p>The industry appears to have chosen the de facto standards for containers (docker) and orchestration (kubernetes) but this doesn't appear to be the case for the options for implementing a service mesh.</p>

<p>Are there some good standards to follow when choosing from the available options for implementing a service mesh? </p>

<containers><microservices><consul><orchestration>
Is there a good standard to follow when choosing a service mesh for your microservice application?
Wunderbread
# Is there a good standard to follow when choosing a service mesh for your microservice application?

(Asked by: username_0 on 2019-01-28)

The industry appears to have chosen the de facto standards for containers (docker) and orchestration (kubernetes) but this doesn't appear to be the case for the options for implementing a service mesh.

Are there some good standards to follow when choosing from the available options for implementing a service mesh?

**Tags:** containers, microservices, consul, orchestration


---

## 2 answers

### Answer by username_1 on 2019-01-28. Score: 1

I would say that [Istio](https://istio.io/) is the de facto standard for Service Mesh. It is launched by both Google and IBM.

* [Welcome to the service mesh era: Introducing a new Istio blog post series](https://cloud.google.com/blog/products/networking/welcome-to-the-service-mesh-era-introducing-a-new-istio-blog-post-series)
* [IBM, Google Cloud and the open community launch Istio 1.0 to bring microservices to the enterprise](https://www.ibm.com/blogs/cloud-computing/2018/07/31/ibm-google-open-community-istio-microservices/)


---

### Answer by username_2 on 2019-01-29. Score: 0

In general you are going to find the best support for “an X” on Kubernetes by looking at what “X” projects are members of the same software foundation so governed by the same organisation. Kubernetes is part of the [Cloud Native Computing Foundation](https://www.cncf.io/) so you should study what [“Xs” it offers](https://www.cncf.io/projects/). In the case of service mesh CNCF has Linkerd.

At this point in time though as other answers point out there is a lot of momentum around itsio. This [uses Envoy](https://istio.io/docs/concepts/what-is-istio/#envoy) which is a top level CNCF project to actually shape the traffic between your containers. That is reassuring as we would not expect k8s to suddenly break Envoy at a minor release so we might expect itiso to be able to keep up to date with k8s. That’s a guess though.

You should also consider whether there is a “service mesh like” tech for that stack you use already. If for example you are a Java shop doing microservice like a lot of big firms then you are probably using spring boot and spring cloud. In which case spring cloud already had a bunch of components that offer the same benefits as a mesh but do it in a more traditional way (libraries embeds in your app). By way of example [here](https://access.redhat.com/documentation/en-us/reference_architectures/2017/html-single/spring_boot_microservices_on_red_hat_openshift_container_platform_3/index) is an architecture demo of how to port a java spring cloud airline booking microservices demo app onto openshift Kubernetes. In that doc they mention itsio but actually they stick with spring cloud ribbon, eureka and zuul. Spring cloud also has distributed tracing etc.

This then leads to three choices if you’re a java shop. In order of more conservative first:

1. If your writing Spring Boot microservices stick with Spring Cloud. Developers can run it all as “just java” in their laptop and will take responsibility for it all working well on k8s as it’s “obviously” something they should master.
2. Deploy Linkerd as it’s an established CNCF project so the most mature option
3. Deploy itsio which went to v1.0 relatively recently but is likely to mature fast.

The smart money if you have the time is to try out all three.

> **Comments:**
> **username_2**: I should add that there is a rule of thumb “use smart clients and dumb pipes” which things like itsio appear to violate. This means a friend who has been the service manager at a very large and mature microservices platform is suspicious of new service mesh technologies. I have tried to put the trade offs into this answer in particular if you deploy “magic pipes” and they give errors your dev team is going to expect you to fix it every single time. If you give them dumb pipes (vanilla k8s) and let them install libraries into they apps that do “smart client logic” they will take ownership.  

---

