Kuma, a new universal service mesh

@rucciva, those are very good questions. I think the story is that Kuma is going to be better fit for east-west (mostly L4) traffic, while Kong is a better fit for north-south (mostly L7 traffic). In that sense, the Kuma is part of the network infra, while Kong is more on application side (now the obvious question is, isn't there a lot of application layer API-traffic between services). I think there is some truth in saying Kong focusing on API management. Though, I see Kong being more useful outside REST-APIs in a future, e.g. stronger gRPC story, and better understanding of other (application level) protocols. And at the same time, I don't see Kuma focusing on that. So while there is overlap, I can see them standing on their own legs.

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.

Consul Connect does that too...has for a while

Thank you very much for the answer. I'm looking forward to how kong and kuma will shape future infras and service. I'am also attending the next month kong summit btw.