Docker and Kubernetes both immediately made sense to me when I found them. They both obviously addressed pain points I've had before and were easily recognizable to me. (Docker lets me share server applications with their environment, and Kubernetes makes sure I always have N replicas of that Docker image running on my hosts.) What are the short and sweet issues that service meshes and control planes each solve? I see a bunch of things listed on Kuma's page, but I thought those were what service meshes did.
So now I need to run a proxy on every machine, and a service mesh, and a control plane for that, which depends on its own other services.... does it ever feel like we need more infra to run our infra than to actually run our stuff?
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.<p>However, the one thing that every service mesh promises is that the clients don't need to do anything. Except that they do. End users need to rip out functionality that is coupled already tightly to the application, such as authentication, "smart" routing and metrics. They need to orchestrate tracing to pass on the headers (how do you know what routes in your application were bad if all you have is a black box!). It needs to play nicely with already built in enterprise wide things.<p>I'm not sure that I'm sold on the universal service mesh unless you have a high level of engineering talent. The benefits are immense but don't expect to see universal service meshes* running at enterprisey companies any time soon.<p>* Universal means the entire company is governed under a service mesh, not the POC running on 3 servers for a random team :)
Funny that, as a Swahili speaker, i wouldn't be able to say this publicly. This is the word for vagina and reminds me of the Japanese city Kumamoto which would roughly translate as hot vagina. But, good luck, the name shouldn't change anything.
I think it's very clever move. Looks like Istio & Envoy is becoming the standard for service mesh and Kong needs to do something about it. Tapping into the Envoy community is definitely a nice try and not everyone likes Istio.<p>If Kuma gains traction, they can later offer additional capabilities in Kuma to swap Envoy with Kong (their API gateway) as my guess is that Kong API gateway is their cash cow at the moment. (of course they can potentially make money from Kuma via enterprise support, training, etc if Kuma goes mainstream).<p>These are purely my guess. From a user point of view, not a bad idea having Kuma in addition to Istio and other open-source/commercial alternatives.<p>Good luck with Kuma!
Was hoping to see Docker Swarm integration but it doesn't seem to have any. Looks like it could be done with a bunch of manual work, just not supported out of the box.