
Kuma, a new universal service mesh - UkiahSmith
https://kuma.io/docs/0.1.0/
======
AcerbicZero
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.

------
nodefortytwo
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

------
adrianpike
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?

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

~~~
fosk
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.

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

~~~
Confusedcius
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?

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

~~~
beckingz
Does CAN-SPAM Apply here?

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

~~~
rucciva
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.

~~~
pamtelp
So does Consul Connect, right?

~~~
rucciva
Yes, it does

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

------
moimikey
anyone else randomly got added to their mailing list?

~~~
tomjohnson3
Yes. ...that was very annoying.

How did they do that, exactly?

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

------
rucciva
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?

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

~~~
rucciva
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.

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

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

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

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

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

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

------
meddlepal
Yet Another Service Mesh.

~~~
_nhynes
Yet Another YASM. YAY!

