0

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?

1

I would say that Istio is the de facto standard for Service Mesh. It is launched by both Google and IBM.

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 so you should study what “Xs” it offers. 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 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 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.

  • 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 Jan 29 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.