What is our primary use case?
It's a service mesh. The basic challenge with any form of microservices, especially with multi-cluster setups, is having a unified dashboard where you can see all the workloads and what's happening.
Kuma is the only service mesh that offers a global view for all the workloads and all the clusters running within the mesh. It also produces a global DNS entry within the cluster, which is recognized by each and every data plane.
This DNS entry is available across the mesh, and without doing anything extra, we can route your traffic seamlessly to any of the clusters.
What needs improvement?
There are a number of areas where Kong Kuma can improve. One is in terms of product delivery, such as Helm charts. There are a lot of gaps in the Helm charts currently.
Another is in terms of the default monitoring and logging setup. It is not as production-ready as it could be. By default, Kuma comes with Loki, Yagger, and Prometheus to monitor the control plane and data plane, but the unified dashboarding and logging solution should be closer to production-grade. It is good for trying out the product, but I would not recommend taking it to production without setting up your own monitoring and logging solution.
Additionally, Kuma recently released Fivecarless Mesh, which was built on top of Envoy. The challenge with this is that it adds overhead. If you want to run 100 containers in production, you will actually need to run 200 containers because you need to run one sidecar container per pod.
Overall, I think Kong Kuma is a moderate product, but I would not personally recommend it for production use.
For how long have I used the solution?
I have been using it for two years.
What do I think about the stability of the solution?
It is a stable solution, but there are more choices in the market. There are not a lot of monitoring choices.
My first preference will be if I'm running a product, I should be able to monitor it. I should be able to audit everything that is happening inside this product. So, that will be my priority, and I personally feel those things are not accurately mapped.
What do I think about the scalability of the solution?
It is a scalable product. However, there are some places where Kuma goes for the public endpoint.
For example, I want to try something with my internal load balancer. I don't want to use a public load balancer. So those things right now are difficult to configure.
I need to know the complete Kubernetes architecture in all those things, and resources, and then only I can create it.
And it is scalable. Like other products, we can literally add more and more clusters to it, and it works seamlessly. The only thing is having a sidecar in the previous version, which was a real bottleneck.
How was the initial setup?
The initial setup is complicated. Although Kuma has its own CLI, CTL, and they say to use their CLI, if I have to build a generic solution, my personal preference would be to use Helm or another similar solution other than Kuma.
If you have your own library CLI, it becomes hard for others to adopt it. For example, if I have to write some automation, infrastructure automation, I can't just use Kuma. I have to change my code to use Kuma's CTL, which is unfair because it doesn't make sense. It doesn't fit with my current automation structure. I have to do something extra, something additional, which I really don't like.
It should be something that is seamless and integrates seamlessly with the current landscape. I should not have to do something extra to build or configure any product properly.
In short, I would prefer one-click installation and one-click configuration rather than doing all the testing and debugging here and there.
It is self-managed. But the instances, normally, for my personal research also, I use cloud providers because it makes my life easy.
What's my experience with pricing, setup cost, and licensing?
I have tried for my personal research and all those things. I have tried only the open-source version. So, for me, it was always free.
What other advice do I have?
I won't suggest going with Kuma because it has both the versions, open-source and closed-source versions.
Now, the challenge with this is the lack of community for open source support is just the one company that is doing it.
But if I compare it with other products like Istio, which have a full fleet of community and log developers behind it. Like any product, success or failure depends mostly on how many of the community people you can engage.
So, there are better products and more competitive products that have a bigger community. So, if I look at all these factors, I won't suggest it.
Even if you can evaluate the product, you will not be sure when the bug is going to affect you or what is going to happen.
Overall, I would rate the solution a six out of ten. The challenge with open-source versions of service meshes is that they often lack SSO integration. Kuma was no exception last year. To implement basic user access, you had to use an external proxy solution like Euronext. This is a major inconvenience for enterprise-grade companies.
Another issue I had with Kuma was the documentation. It was unclear and confusing, especially when it came to gateway resources. I couldn't find any documentation on how to customize Helm charts, either.
Kuma creates most of its resources with public endpoints by default, even though you may not need them. For example, if you have one cluster in Chicago and another in Virginia, and you want to communicate between them within the same AWS account, Kuma will create a public load balancer or use a public IP by default. If you want to communicate over a VPN or internal network, you have to manually hack the configuration.
Which deployment model are you using for this solution?
Hybrid Cloud
