ISTIO

Istio Service Mesh

Introduction

Istio is nothing but the implementation of Service mesh. What is a Service mesh then! Service Mesh is a solution that manages communication between microservices. However, in which way, the service mesh is different from the existing services used for communication in microservices, is what we are going to discuss in this article.

Some drawbacks with the existing microservices architecture

There is no any robust endpoint available for each microservice to have an effective communication with each other. With Istio’s endpoint configuration, for example for a webserver, it allows us to establish an effective and robust communications with all the other related services.
When it comes to security, we typically have firewall and proxies configured outside the cluster to filter or restrict the unwanted access to our microservices cluster. However, inside the cluster, the services can communicate freely without any restrictions that makes the cluster insecure.
Microservices also need retry logic to automatically retry the connection when one of the microservices are unreachable. One another challenge is with the metrics collection and tracing errors, request counts etc. Therefore, we may need to add a monitoring logic to provide those data to the monitoring solutions like Prometheus. All these logics should be added additionally to each services that results in much effort and adds more complexity to the services.

Service Mesh in solving the problems

In order to get rid of all the above challenges, we can implement Service Mesh with sidecar pattern. We can separate all the non-business logics from the microservices and should keep them in a sidecar container and call it as sidecar proxy.
Since it is a third party application, anyone who manages the cluster can easily configure the same. Moreover, developers can predominantly focus and spend more time on actual business logics. Service mesh has a control plane that automatically injects the proxy in every microservice pod.

Traffic Split feature

Concisely, Traffic Split is very much similar to the Canary deployment. When you make some changes to your application and release a new version, you may have some bugs and that could result in breaking the production application when deployed.
Even if you tested the new version thoroughly but still unsure about its flawless working, you can use Traffic Split to send your new version changes to only 10% of the application requests and the old standard version can serve the remaining 90% of the requests.

Working of Istio

Service Mesh is just a pattern or paradigm and Istio is one of its implementations. Istio uses envoy proxies (which the service mesh implementations generally use). The control plane components of Istio is Istiod that manages and injects the envoy proxies in each microservice pods. In earlier versions of Istio (prior to v1.5), the bundle of components like Pilot, Galley, Citadel and Mixer were separate. In the versions after v1.5 those components are embedded inside the istiod control plane.

Some other features of Istio

• Configuration
• Service discovery
• Certificate management
• Gather telemetry data
Istio has internal registry for services and their endpoints. Moreover, the endpoints configuration is dynamic that helps new microservice to register automatically.

Conclusion

Whenever user sends a request, it hits the Istio Gateway that evaluates the virtual service rule and routes the traffic to the microservice endpoint where the requests are being forwarded to the envoy proxy followed by the traffic routed to the service and vice versa. This is in high-level the traffic flows through Istio.