We are using the Istio framework as the service mesh for our microservices. We use it as a load balancer for the network traffic that is coming in.
We have HTTP traffic that is coming into our service, and this traffic has to go to multiple other services. Typically, in microservice, you have a class of servers that need to talk to each other. There is a proxy server that talks to these servers on the mesh layer.
The load balancing, service application, and monitoring of the life of the service are valuable features. We use it for authentication of call services, load balancing the calls among the service providers on service instances, and monitoring the health of the services.
For our use case that we applied it to, there were graph queues and the calls that were coming in. There were the things that we couldn't apply at the time, but it kind of worked.
We have used it in active development for roughly about eight to nine months.
Our traffic volume was not like a billion calls per second or something like that. We subjected it to very moderate traffic. It worked quite well for the traffic volume that we had. We didn't have to do anything differently.
It is scalable. In terms of service scale and integration with Kubernetes, we are quite happy with the clusters of this setup and how Istio inter-played with them. We don't have traffic similar to the internet, such as for social networking, but we do have traffic that is significant in terms of our internal stuff, and it still scaled quite well.
As you set up these new clusters, you can see that it balances the load quite well and registers itself. Otherwise, you'll have to do all of this work manually when you bring up a new service. You have to let the load balancer know where the new service is and then divert traffic to that. All this is, kind of, handled for you, which saves quite a bit of effort on our end.
These things are clearly driven by traffic volumes. As we bring more and more services into the farm, then, of course, these things will have a bearing on how many instances run Istio. At the moment, pretty much all of them run Istio, and we are happy with it. We are not planning to get off the network. It has, kind of, worked for us if you look at what we've done so far.
We are a software vendor. We have a self-help kind of model. We use this model for everything that we do at work, not just for Istio. We pretty much deal with all issues ourselves. We don't go for external tech support. There is enough knowledge in the public domain that you can use. The forums where such issues are discussed work quite well.
As far as load balancing is concerned, previous applications that we were using were more around Apigee and stuff like that. These are paid services that cost quite a bit of money. We moved them to the Istio framework. In this particular project, we started from scratch, and we are happy with the amount of effort it has saved. We didn't have to shift from something else.
There are two notions. One of these was the sidecar deployment. Based on what I remember, the deployment was pretty easy for us. It was not as it was made out to be. It worked out quite well.
Typically with such software, you have to go through a little bit of an upgrade of your engineering staff because only then you can make a design choice. You have to train your team in terms of understanding the feature sets quite well and applying those feature sets. Orienting the team towards something like this takes a little bit of time, but otherwise, it was pretty easy.
It is on the less expensive side. It provides a significant saving for us in terms of cost and other things. It is open-source. We just download it from the open-source framework and use it.
As with all evaluations, it depends on what you are benchmarking it against. When we look at how we evaluated it and how we arrived at it, in our case, it worked out quite well.
There is no pricing involved because we are using open-source. We simply download it and then incorporate it into our code. Now, from that perspective, if the company has a good number of developers who are willing to read, understand, and adapt to the culture of innovation, this doesn't become an issue. These are the things that people will have to do. No matter which tool you use, you will have to eventually get to these things.
The control plane of Istio understands the backend service plane or the data plane. It actually discovers it, configures it, and then puts the certificate in a proper place.
I would rate Istio an eight out of ten.
