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.
>"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."
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.
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).
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.
How did they do that, exactly?
API management being dead, yes that was a bold statement. Perhaps the message was a bit strong, especially if taken literally. If seen as a marketing, e.g. Kong pushing forward on the future with upcoming offering(s) of service mesh, being strongly investing on developing (perhaps even defining) the concepts of the meshes, it is perhaps closer to truth.
Will the service mesh capability on Kong be removed?
I am sure it is a very debatable. Having Kuma and Kong offering service mesh, makes the message Kong (the company) is sending a bit confusing. I believe the Kuma's service mesh story is stronger and more focused than that of Kong. In that sense, it could be that the service mesh capability in Kong may be removed in future. It is certainly possible to keep it around too, at least some parts of it, perhaps the automatic mutual TLS part (e.g. the connection between two Kong nodes on same cluster being mTLS secured), but I guess it might be reasonable to think that Kong is not going to push on areas where Kuma shines. So some overlap, I think, but still somewhat clear. Of course, if there is a lot to gain with removal of service mesh from Kong, then it is reasonable to remove it. I can think about it making Kong focus clearer, some of the complexities from code can be removed. I would perhaps deliver stronger (tcp/udp) stream story with Kong (I know L4), and removing mesh parts could improve that.
But we'll see. Of course a lot of landscape in orchestration and service meshes is still somewhat seeking the form — especially on deployment side (outside the big players). There is a long legacy on all of this, SOAP/WS-*, MQ, service busses, REST-APIs, gRPC, and now meshes.
I hope, this clears up some of the confusion, and not just adds to it, :-).
PS. I work for Kong (mostly on open source Kong product) as an engineer. In general, I feel that there is a period of confusion and the message will get clearer. It is rather natural with products like these, especially when talking about future technologies. I see service meshes as a future technology for a lot of us, perhaps you are already there, and if you are, thanks for pioneering! Sometimes we just need to wait for a better answers.
The views here are my personal views. A good place to clear up the confusion is Kong Summit next month at San Francisco.
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.
I wonder what dependencies they require for VM-based installations?