Today I will talk about ISTIO and Service Mesh topics. I’m on a learning path these concepts to apply in my job and help some other interesting people on a software architecture and development.
I’m so excited to learn it because I think this maybe change our way to develop microservices, specifically how we can use infrastructure to get more insights about our runtime applications a.k.a metrics, health and routing.
This post intends to be a simple explanation about some Istio features and some comparisons with other tools provided by amazing Netflix OSS components.
I’m a java developer and most of part of my job time I’ve been created solutions with the Java frameworks and libraries. The Spring Framework is an amazing framework to create web applications, also has a brilliant and vibrant ecosystem.
Also, the Spring Cloud Projects provides interesting solutions to helps us, developers, to build distributed applications.
On this post, we will use the Kubernetes as container orchestrator.
I had some experiences coding with Spring Cloud Netflix Projects which integrates the Spring ecosystem with Netflix OSS tools, like Netflix Ribbon, Netflix Hystrix, Netflix Eureka and these projects is really amazing, and makes our developer’s infrastructures tasks so easy, with a couple annotations and some configurations the projects have interesting features like Service Discovery, Client Side Load Balancer and Circuit Breaker.
This kind of application, which uses the Netflix OSS tools, usually handle the network layer inside the application layer. For instance, the circuit breaker feature provided by Hystrix needs to be configured in the application layer. We can see the retrieves calls are handled by our component (application) because we have the Hystrix inside. In the same way, the Ribbon works we need to have in our classpath.
It works generally well but imagines the following situation. Remember the Netflix OSS only works for Java stacks, it uses the Java ecosystem to achieve these features. But now we need to change the application because the application needs to handle more load with minimal resource usage. The Golang fits well in this case.
The microservices advent can help developers to create small and independents application.
We can’t lose these important features in the microservices architectural style.
Because of this situation, the Service Mesh Pattern has been gaining some notation in the development world. Using this pattern we can isolate the Network stack in another container (in the same POD), it is called sidecar container, it will be responsible to handle all network calls independently of the application language has been built.
In this context, Istio as an implementation of service-mesh gives for us some interesting features like Intelligent Routing, Circuit Breaker, and Fault Injection outside of our application, with any code more to achieve these features. It is amazing.
I tried different approaches to install Istio in my cluster, actually, I’m using the Google Kubernetes Engine (GKE) to learn and try Istio features.
I decided to use the Helm installation which one proved easier and fast way to install/delete Istio in my kubernetes cluster. I followed the Istio installation with Helm, you can find the instruction at istio installation guide.
The Helm installation disables the Mutual TLS authentication by default, of course, you can enable using the Helm command line flags.
If you using the Istio 0.8.0 version, the installation automatically spins up a pod which one provides automatic sidecar containers in our PODs, it can make our lives easier because we can mark a namespace to enable sidecar automatically. I used this feature and works very well.
I extremely recommend you to install “infra” services, the Istio refers to this as “add-ons” like Grafana, Prometheus, Service Graph and Jaeger. These add-ons help us to see the cluster metrics, which Istio collects and stores in some these services.
That is all to enable us to play with Istio!!
I’ve created a couple of applications, there are no complex business rules. The idea here is to try the service-to-service communications and get some metrics about these communications. And then I deployed these applications in the Kubernetes cluster, the important thing here is I’ve created the standard Deployments in Kubernetes.
These deployments have a Services which one’s exports the ports, nothing special here. The crucial thing is the Service needs to use the metadata section with the labels called “app” if you forget this the Istio will not work as expected.
Look at the following example:
- name: http
Pay attention to the metadata section.
To Istio work as expected we need to follow some requirements, these requirements can be found here.
After the deployments worked. I decided to try some requests for my services. And like a magic without any configuration, my Grafana instances started to gathering some services metrics. I’m got impressed at this moment because the how fast it is and with a simple yaml configuration I had an almost complete and interesting metrics.
Look at Grafana instance, at this moment I didn’t create any graphics or configuration and the graphics show my whole applications ecosystem.
Also there other interesting services like Jaeger which one allows us to collect tracing between service communications and measure the time of service calls.
Prometheus which one will store our metrics in the time series database, it is a kind of Backend for Grafana. The Prometheus basically will collect the service metrics and store it.
Service Graph which one show our services dependencies in real-time. It is an awesome app.
I’ve started to play a few weeks ago with Istio (Service Mesh) and I think these tools will helps developers and devops guys in different ways. To get insight into the infrastructure, maybe the applications metrics usages. Another important characteristics for me is how Istio collect the application metrics. It is not intrusive and it makes easier to development lifecycle.
Also, these tools can help the companies to innovate faster than ever because it offers awesome implementations like Canaries Deployments, the companies can try your deployments without downtime and with a reasonable safety.
I’m excited to study more about it, in the next weeks I will discover more features and I will share on this blog.
If you can help me, on the journey to learn service mesh please share interesting articles about the topic.