Take a look at this article to get a look at how service mesh architecture has made Istio a stand-out tool in microservices infrastructures.

Microservices are great but they are also a pain to maintain. With so many moving components, microservices make it difficult to maintain and identify the bottlenecks. The mindset has to be changed and applications need to be designed for failure.

Applications are split into multiple smaller services and they should be interconnected. They should know where the other services live and how to connect with them. They should be consistent and highly available. The connections should be intelligent and configurable. These services should be secured, traffic between services should be encrypted, requests should be properly authorized and authenticated. Since these services scale up and down autonomously, it is important to monitor and observe them for any issues, errors, exceptions, time lag, and other things.

Back in 2017, I was solving many of those distributed-systems challenges using Spring Cloud with Netflix OSS; you can check out my Bootstrapping microservice project here. But Netflix OSS is for Java developers mostly and microservices can be implemented in a variety of frameworks/languages, so we should be able to handle those challenges outside the application level.

So can the infrastructure help out with communication issues that distributed system brings?

Istio, the Game-Changer

Istio is a service mesh for distributed application architectures, especially the ones that you run on the cloud with Kubernetes.

Istio is the coolest kid on the DevOps block and the tool that we need in our toolbox to address most of the communication issues for distributed applications.

Istio provides the following functionality in a distributed application architecture:

• Service discovery — Traditionally provided by platforms like Netflix Eureka or Consul.
• Automatic load balancing — You might have used Netflix Zuul for this.
• Routing, circuit breaking, retries, fail-overs, fault injection — Think of Netflix Ribbon, Hytrix and so on.
• Policy enforcement for access control, rate limiting, A/B testing, traffic splits, and quotas — Again you might have used Zuul to do some of these.
• Metrics, logs, and traces — Think of ELK
• Secure service-to-service communication — Replacing the manual TLS configuration
• Authentication and Authorization — good by Spring Security

Bootstrapping a Service Mesh Project

I am maintaining an open-source project that provides solutions for common communication challenges. The idea of this project is to provide you with bootstrap for your next distributed system architecture. This project will definitely help you to get an understanding of how to solve distributed application challenges using Istio and save you a lot of time in setting up your next service mesh.

I have prepared the application example to simulate different issues where we could solve all issues step by step in an educative way.

We will see how to secure the communication within the cluster, open the circuit breaker to not send the request to a failed service, monitor external calls, see load balancing in action, add fault injection, manage traffic to different version of the app, secure access to use the JWT token, write custom logs, and, finally how to monitor your application using Kibana, Kiali, and Jagger.

I have recorded some screencasts presenting the project. Check it out!

Conclusion

Distributed systems are complex with many moving parts and demand good observability tooling and centralized control of the communication between the applications. In this article, we have presented an opensource project that solves most of the distributed application challenges, defining strategies and performing actions on an Istio based microservices application.

Enough talking, check out the project here.