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 an emerging technology aimed at managing, monitoring, and securing microservices applications. It offers real-time visibility and reliability, crucial for large and complex architectures.
Service Mesh provides advanced traffic management, security enforcement, and observability for microservices architectures. It operates at the network level, automatically handling service-to-service communication, and is often used with container orchestration platforms like...
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.