Kuma, a new universal service mesh | Hacker News Reader

Kuma, a new universal service mesh

kuma.io

61 pointsUkiahSmith31 comments

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.

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?

So many service meshes these days, how would this differ from Istio which seems to be the hot topic alongside Kubernetes?

Unlike Istio, this is built to work natively with minimal dependencies on every platform, not exclusively on Kubernetes, which means it can support both new greenfield applications and existing VM-based apps, so that networking policies that would typically be available only on K8s for new apps, can be applied on existing workload today. That, and it’s meant to be easier to use, which is another big problem with existing Service Mesh implementations.

Can you use Kuma and Istio together if you already have Istio in one environment?

Interesting point, would love to know as well. And I echo meddlepal’s sentiment since there are so many options it can feel overwhelming. But for someone who still have services on bare metal, would folks agree that this is a good product to explore?

Y'all emailed me without me giving you my email address. Please don't do that

Does CAN-SPAM Apply here?

The documentation states:

>"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.

The other service mesh are indeed native in Kubernetes. What Kuma emphasize as being different with others is the "via a RESTful API across other environments", so it support both orchestrated container environment and legacy environment.

Thanks for the clarification, that really helps differentiate the offering. Cheers.

So does Consul Connect, right?

Yes, it does

This actually looks really promising for the future :)

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.

anyone else randomly got added to their mailing list?

Yep

Yes.

Yes. ...that was very annoying.

How did they do that, exactly?

Scraping and storing email addresses is how it usually happens, but most companies recognize it as illegal.

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?

@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.

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.

Kuma means vagina in Swahili, vagina.io is kinda funny.

...and bear in Japanese, I reckon. I guess every short word means something in at least one language!

In Greek, it's a "pregnant thing" or "swollen thing". Homer uses it to describe waves.

This is the way forward for service meshes. Consul connect is doing something very similar.

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.

Finally a service mesh that runs natively on K8s and VMs.

I wonder what dependencies they require for VM-based installations?

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

Yet Another Service Mesh.

Yet Another YASM. YAY!

Reply on news.ycombinator.com