TNS
VOXPOP
What news from AWS re:Invent last week will have the most impact on you?
Amazon Q, an AI chatbot for explaining how AWS works.
0%
Super-fast S3 Express storage.
0%
New Graviton 4 processor instances.
0%
Emily Freeman leaving AWS.
0%
I don't use AWS, so none of this will affect me.
0%
Service Mesh

Kuma: Kong’s Simpler Service Mesh, for VMs and Kubernetes

An introduction to Kong's new service mesh, Kuma.
Nov 25th, 2019 2:18pm by
Featued image for: Kuma: Kong’s Simpler Service Mesh, for VMs and Kubernetes

Portworx sponsored The New Stack’s coverage of KubeCon+CloudNativeCon North America 2019.

“I don’t like the name ‘service mesh,’” was about the first thing out Kong Chief Technology Officer Marco Palladino’s mouth when asked about the company’s new open source service mesh, Kuma, released in September and showcased during a Day Zero event at KubeCon+CloudNativeCon North America 2019, held in San Diego last week. “The real issue is about connectivity.”

Palladino said there are two reasons he dislikes the name “service mesh.” First of all, the new name implies that it’s something entirely new that’s never been seen before. Secondly, it makes it sound like a “service mesh” — in other words, a sidecar proxy system for managing ingresses and egresses between applications — is only useful if you have a mesh of services. Neither, he said, are entirely true. 

Kong built and released Kuma for a couple reasons, Palladino said. First of all, it’s related to Kong’s core API gateway product. Both API gateways and service meshes are a way to control and secure communications between services and between applications and end-users. The difference is in how they do so: API gateways are a separate layer in the infrastructure that sits between the user and the services, while a service mesh is created using sidecar proxies that are attached to individual containers, forming a ‘mesh’ rather than a separate layer. “Service mesh is obviously an extension of what people use Kong for,” Palladino said. 

First Kong looked at existing service mesh options, but decided to build separate service mesh — though it is based on Envoy. The goal, Palladino said, was to create something that would work both in a distributed, containerized application running on Kubernetes but would also be useful for the many companies still running on virtual machines. The company calls Kuma a universal service mesh that companies can use for legacy applications as well as new, cloud native applications. 

Another advantage of using Kuma over other service mesh options, Palladino said, is the advanced user interface. Other service meshes have immature control planes that make it too complex. Lastly, Kong wanted to ensure support for multi-tenancy, something that many other service meshes lack. 

Kuma, Palladino hopes, is a service mesh tailored to the realities of enterprise organizations. The type of company that is still at the beginning of the Kubernetes maturity journey, with hundreds of teams moving at a different pace and with different skill levels. 

“Kuma is a very simple application to run and deploy,” Palladino said. “There is only one moving part. You can scale Kuma horizontally. It’s easy to operate. You can support every team from one control plane.”

There are already companies using Kuma in production, include one large European telecommunications company.  

Feature image by Alexas_Fotos from Pixabay.

KubeCon+CloudNativeCon is a sponsor of The New Stack.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.