TAGS: |

Kong Aims To Be King Of The Service Mesh And API Gateway

Drew Conry-Murray

Kong provides connectivity software for microservices and scale-out applications. The company recently released version 2.1 of Kong Enterprise. This latest version offers an API gateway, a service mesh, and a Kubernetes Ingress Controller. Customers deploy multiple data plane instances of the gateway, service mesh, and ingress controller while managing all of them from a central control plane.

Traditionally, API gateways were deployed and managed separately from service meshes (though currently the lines between these two categories are blurring). By bringing API gateways and service meshes under a single management platform, one of Kong’s goals is to make it easier for companies to address a variety of traffic management use cases.

Another of Kong’s goals is world domination. “From an execution standpoint, we are building the Cisco of L4 to L7 connectivity,” said CTO and co-founder Marco Palladino in an interview.

That’s a boastful statement at this point, as enterprises have a variety of open source and commercially supported options for gateways and meshes.

The service mesh space in particular offers a variety of options. The best-known open source option is Istio. There are  commercial offerings that build off Istio, including those from Red Hat (OpenShift Service Mesh), VMware (NSX Service Mesh), and Cisco itself (Container Platform Service Mesh).

Other popular service mesh options include LinkerD and Kuma. (By the way, if you want more information on service meshes, check out the Service Mesh Buyer’s Guide whitepaper, written by Dave Tucker. It’s available as part of a Packet Pushers Ignition membership.)

Moving Parts

Kong Enterprise has a bunch of moving parts, and here’s where things get a little complicated.

First, Kong’s service mesh, called Kong Mesh, is built from Kuma. Kuma was originally developed by Kong, which then contributed it to the Linux Foundation’s Cloud Native Computing Foundation. Kuma is currently a sandbox project within the CNFC.

Kong Mesh also relies on other open source software, including Envoy for the proxy.

For the API gateway, Kong relies on NGINX for its network primitives. NGINX, now owned by F5, also offers a competing API gateway. Open source software makes for strange bedfellows.

Remote Controls

The data plane elements of Kong Enterprise’s gateway and service mesh can be deployed on premises or in the public cloud, depending on the workload.

For instance, the API gateway might be deployed in front of a set of corporate Web applications, while your of service mesh instances reside in a Kubernetes cluster on premises and in AWS or Google Cloud.

The control plane relies on a hierarchical deployment model, with localized instances of a control plane deployed as close to data plane elements as possible. Kong calls these instances “remote control planes.” Remote control planes then feed into a global control plane. The global control plane is where administrators can set policies, monitor gateways and services, create reports, and so on.

Kong says it has decoupled the remote and global control planes to ensure high availability and scalability. At present, the software for the global control plane runs on customer-controlled infrastructure, and is not available as a service from Kong. The company says a cloud-based version of the global controller is on its roadmap.

Should Network Engineers Care?

What does all this mean for network engineers? In the long run, it means new opportunities. While microservices, Kubernetes, cloud-native, etc. etc.,  are all currently weighed toward developers, all the services and functions being developed need to talk to one another.

That’s a lot of API calls to be plumbed up, load balanced, encrypted, authenticated, monitored, logged, traced, measured for performance, and diagnosed when something goes wrong. In other words, it’s networking. If and when microservices becomes the dominant application architecture, organizations are going to need networking smarts to set up the correct connections, with appropriate guardrails, so that developers can do their thing without having to worry about the roads.

About Drew Conry-Murray: Drew Conry-Murray has been writing about information technology for more than 15 years, with an emphasis on networking, security, and cloud. He's co-host of The Network Break podcast and a Tech Field Day delegate. He loves real tea and virtual donuts, and is delighted that his job lets him talk with so many smart, passionate people. He writes novels in his spare time.