Kong is muscling its Kuma service mesh platform into an increasingly complex ecosystem that has seen a number of new entrants and options spring up over the past few months.

The company claims that Kuma is “a universal service mesh.” Kong CTO and co-founder Marco Palladino explained this means that unlike most of the service mesh options on the market, Kuma is designed to work within and outside of the Kubernetes ecosystem. He said this includes virtual machines (VMs), containers, legacy environments, and in Kubernetes.

Kuma includes a universal control plane that is based on the Envoy service proxy. It combines a data plane and advanced control plane to allow users to set permissions, expose metrics, and set routing rules using native custom resource definitions (CRDs) or a RESTful API. Palladino explained that most of the first round of service mesh platforms lacked a mature control plane that required a lot of manual work or customization.

“We want 90% of use cases to be easy to use and can be up to speed quickly,” he explained. “For the other 10% we have a policy in place to allow the user to go deeper,” adding that despite being designed for ease-of-use, “Kuma is meant for enterprises, not hobbyists.”

Kuma features include software-defined security that enables mutual transport layer security (mTLS) authentication for all Layer 4 traffic; the ability to implement tracing and logging that allows for better analysis of metrics; and traffic control capabilities like circuit breakers and health check to boost Layer 4 routing.

Palladino said that Kuma’s ability to secure the underlying network provides for reliability and deeper observability without having to change any code.

“We tried hard to form a very gradual learning curve for Kuma,” Palladino said. “It does not drown a developer early on. But it also does not prevent that developer to go more advanced. We do provide a policy to configure the low-level proxy data plane for advanced users.”

Kuma also taps into Kong’s self-named open source platform API gateway. That gateway manages the flow of information between an organization and various methods of deploying modern microservices.

Kuma joins a growing number of service mesh options that are claiming to make it easier to support the deployment of microservices.

“Everyone is telling us that they want to use a service mesh, but there are really none out there that are easy to use and really targeted at enterprise operations,” Palladino said. “Many are focused on Kubernetes but that is the end of the journey for many enterprises. We provide a product that allows them to have a service mesh that can be implemented early and can support their migration.”

One service mesh platform that has gained attention is Istio. It sits at the network level and uses a substrate for microservices development and maintenance. This allows for the decoupling of management from application development.

Palladino said that Istio has helped shine some light on the space, but that it remains “very complex and has lots of moving parts. It runs well on Kubernetes, but not everyone is running Kubernetes.”

He said this focus also impacts other options like Linkerd and Containous’ recently launched Maesh platform.

“Maesh, Linkerd, and any control plane mesh are hyper-focused on Kubernetes,” Palladino explained. “They are only going to be adopted when an enterprise adopts Kubernetes. We enable that transition to Kubernetes by getting security and observability set up earlier in the process.”

There are also efforts to align interoperability among service mesh platforms. One of those is being led by Microsoft, which earlier this year spearheaded the launch of the Service Mesh Interface (SMI) specification. This is targeted at providing developers with interoperability across different service mesh technologies running on Kubernetes.

Palladino downplayed this effort as marginalizing service mesh capabilities.

“We do not believe in SMI at all,” he said. “It’s another attempt to standardize the interface to be average and not excellent. It takes the common denominator across the meshes and makes them less valuable to the end user. It’s wide but it does not go deep.”

Palladino said that Kuma instead “interoperates across all platforms.”

Kong was founded under the name Mashape in 2009. It pushed its Kong platform into the open source community in 2015, and last year it officially took on the platform name for the overall business. The company has raised $69.1 million in funding through five rounds, with its most recent a $43 million Series C round in March.