Its cool that the whole SDN thing is finally getting the traction it deserves, but I really don't see these various one off service mesh solutions solving the core networking problems in play here.<p>Maybe I'm totally off base, but ever since NSX-T (and to a lesser extend ACI) has started to include their own Istio based service mesh solutions for containers, while also having the ability to virtualize the rest of the networking infrastructure up to (and including, kinda) the core, I just can't seem to think of a use case for another one off service mesh provider.
Really looking forward to trying this out. I get K8s is the bees knees and everything but we have an ECS history that will take time to migrate to K8s. I'm glad to see a modern service mesh not just targeting the collective
Semi-tangential: I found it really interesting that Kong linked to HN/newest in the announcement email they sent out instead of directly to the HN conversation. Clever way to avoid getting their votes penalized, maybe?
The documentation states:<p>>"It can be used natively in Kubernetes via CRDs or via a RESTful API across other environments, and it doesn't require a change to your application's code in order to be used."<p>Sorry if this is naive question but I'm not that up on service meshes. Aren't other service meshes generally implemented as sidecar containers? Why wouldn't those also be considered native? Could someone help me understand the distinction of a native service mesh vs non-native? I'm having a hard time getting my head around it.
This actually looks really promising for the future :)<p>We've been on a move from bare metal to kubernetes, but it's a long-time work in progress (as it has to be when you have over a hundred Microservices).<p>A few months ago I've been evaluating service mesh solutions, and nothing is simultaneously mature and works on mixed bare-metal and k8s environments. With existing routing logic and stuff like that. That's why we ended up using envoy with a custom control plane. This project however, may become a possible good alternative in the future.
Cool news! Just wondering about something. "API Management is Dead", said Kong's CEO in Kong Summit 2018. And then, first Kong GA ship with service mesh capabilities, making it capable for both north-south and east-west (API) traffic management. But now that they released Kuma with Envoy as the data plane, will that means Kong will be focused on being the API Management that they proclaim as being dead? Will the service mesh capability on Kong be removed?
This is the way forward for service meshes. Consul connect is doing something very similar.<p>The early service meshes were all built on top of Kubernetes, due to the fact that k8s/etcd is an easy platform to build control planes on top of (SD, networking, etc. already done) but very few large companies are ready to move everything over to Kubernetes.