Service mesh is an infrastructure design in which all of a system’s services are accompanied by proxies and logic management components. Often used with microservice orchestrators like kubernetes,  if you want to learn more about kubernetes go check out this article. And if you want to learn more about Istio, go check out this article, before diving into this article.

Service mesh offers granular control over your infrastructure network, allowing for smoother deployments, extra security, and observability on all your traffic. These features are useful for fast development rate in agile environment and allow developers to focus on the feature of their application.

Service mesh allows for teams to quickly understand an infrastructure due to standardization of policies. Allowing big infrastructure to easily manage turnover and lose of knowledge.

A couple of service mesh implementation exist like Isitio, Linkerd, Consul, and Kong. We will focus today on Istio which was introduced by Google and IBM in 2017 and is the most featureful service mesh.

Istio is a service mesh that is made up of two planes: the data plane and the control plane.

Service mesh architecture: The data plane

In a service mesh this plane is composed of all services of an application. These services are accompanied by a userspace proxy, the most common one being Envoy.

These proxies relay incoming traffic to the container actually serving the application. This means that when an incoming request arrives it first goes into the proxy and then in the actual application container.

You might be wondering why add an extra network hop? What can possibly be the gain for adding some latency? Why is service mesh adding an extra hop? The answer is: the control plane can aggregate all the data received by the proxies.

Service mesh architecture: The control plane

In a service mesh, this plane’s purpose is to define the behaviour of the data plane and it’s what makes a service mesh so useful. The control plane is aware of all the proxies and thus offers traffic management, security and observability.


Traffic management

The first feature of Istio allows you to control the flow of traffic to and from your microservice. Per example Istio allows to configure the flow on a service level by allowing you to set a percentage of traffic to send to a specific version.

This feature is called canary release which allows smoother deployment in production, and rollback in case of an issue.

Canery deployment-1

The scheme above demonstrates how Istio manages a canary release in which 90% of user traffic will be sent to App V1 but 10% will be sent to App V2.

In a service mesh the traffic passes by the proxy, which is is aware of HTTP error. Istio can be configured to retry if it receives one of these errors. This is very useful for developers because they do not have to implement a retry policy in the code and helps them build resiliency in a services' architecture. It can easily be added with the following code:

attempts: 5
perTryTimeout: 2s



Second of all, in a microservice architecture a lot of traffic flows between all the services, which offers an opportunity for malicious parties to intercept it if not secured. With a service mesh you can configure mTLS (Mutual TLS) between all proxies thus securing traffic. Istio manages encryption between proxies. The only traffic that will not be secured will be between the proxy and the application container. Istio offers this feature by default.




Finally, one of the best features of service mesh is observability. Having an intermediate proxy allows for a service mesh to trace every request. Allowing for detailed telemetry for all service communications. Empowering developers to troubleshoot, maintain, and optimize their applications.

During a canary release you can observe live network traffic on Kiali which is buit-in with Istio, and therefore take immediate action.


You can see above a network graph of the service mesh of an application that is currently testing review v2 by mirroring incoming traffic from V1 to V2. You can see on the right side an analysis of HTTP requests. All of this live!


Service mesh is getting more and more traction due to Kubernetes, and can work in hybrid environment with VM and other computing resources. It can solve business issues for complex environment offering granular control over your infrastructure, for the cost of extra latency and configuration.

Go check out Istio and test it out. Istio is available in beta with GKE.

If you want to learn more about service mesh I invite you to go check out, and if you want more examples of Istio go check out.

If you are interested in learning more about microservice and Kubernetes, go check out our blog.