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.
Service Mesh is a dedicated infrastructure layer for handling service-to-service communication across microservices, providing observable and manageable connections for complex applications.
Used primarily in cloud-native environments, Service Meshes enhance microservice architectures by managing traffic, ensuring security, and monitoring operations. With features for load balancing, health checking, and traffic management, they allow teams to focus on developing features rather than...
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.