Istio: “A service mesh solves some major problems in the management of service-to-service communication, but not all”

JAXenter: How would you explain the concept of service meshes in a few words to someone who is not familiar with it?

Patrick Arnold: A service mesh is an infrastructure component that manages service-to-service communication in the network. It is integrated directly into the application. The main task of a service mesh is therefore to enable, but also to prevent communication between different components. The general functions of a service mesh often include load balancing, encryption of service-to-service communication, circuit breakers and fault injection. Because the service mesh has such a good insight into the traffic of the application, it often also provides interfaces for metric data. In a service mesh, requests between microservices are transmitted via proxies in their own infrastructure layer. For this reason, individual proxies that make up a service mesh are sometimes called “sidecars” because they are executed in parallel to, and not within, each service.

JAXenter: Which advantages can users leverage by using a service mesh?

Patrick Arnold: A service mesh solves some major problems in managing the service to service communication, but not all. Some advantages of a service network are:

• Facilitation of communication between different microservices or even containers
• Easier diagnosis of communication errors, as they occur on the own infrastructure layer and can therefore also be better monitored.
• Enables faster development, testing and deployment of an application.
• Offers us some security features out of the box like encryption, authentication and authorization.
• Sidecar containers, which are placed next to the actual application, offer insights into the application and the traffic without programmatic connections.
• Offers the possibility to use modern deployment strategies without much effort.

JAXenter: Are there any disadvantages?

Patrick Arnold: With all pros there are, of course, always cons:

• With the additional sidecar and management components, you naturally have more runtime artifacts, which also require resources.
• Likewise, with the routing of traffic and the use of a service mesh, each application has a few more hoops. The reason for this is the sidecar, which has to be run through each time the application is called.
• Increased complexity due to an additional infrastructure layer.

JAXenter: Can you share some best practices that have proven useful?

Patrick Arnold: Especially for Istio, I would not identify anything as best practices. As a Feature Team, you shouldn’t really notice much except for the routing definition and the deployment of Istio. However, there are a few points that can help to establish a service mesh layer on your microservices:

• Using the auto injection of the sidecar proxies – with some service meshes, such as Istio, this option is available. If it isn’t, I would still recommend automating the injection instead of doing it manually.
• Focus on automation – Here you should definitely deal with the topic of Infrastructure as a Service. If there should be a failure or malfunction in the control plane, you can set it up again in the shortest possible time.
• Monitoring and tracing via any services – due to the strong distribution of the application, it is essential to use the service mesh interfaces to set up comprehensive monitoring and tracing. Only then nothing special has to be implemented within the application, because everything is taken over by the sidecar.
• For the beginning a small namespace & feature by feature – as with most introductions of new technologies you should first start with a relatively small namespace to gain experience. Using the full feature set at the beginning can also present some challenges, so use feature by feature.

JAXenter: Istio is not the only service mesh out there, there is also Linkerd or solo.io for example. Are they real competitors?

Patrick Arnold: So technologically, Linkerd is definitely a dangerous competitor for Istio. Unfortunately the community is much smaller & there are also less contributors. Also behind Istio are two huge IT companies, IBM and Google, who of course want to run their open source project. Solo.io follows another exciting approach. After the release of Microsoft’s “Service Mesh Interface” initiative I heard about solo.io for the first time. Your service mesh hub allows you to provision and operate different service meshes. I think you will definitely hear some exciting news about it here in the next weeks and months.

JAXenter: With Istio, Kubernetes is often not far away. Is Istio destined to be the de facto Service Mesh for Kubernetes?

Patrick Arnold: Definitely, I think Istio is currently enjoying the widest spread among service meshes. Usually it’s also the case at conferences that when it comes to service mesh, Istio’s language is usually the same. Istio is now supported on almost every Kubernetes platform. For me it is already the “quasi” standard.