Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Kong 1.0 GA Released with Service Mesh Support and Plugin Development Kit

Kong 1.0 GA Released with Service Mesh Support and Plugin Development Kit

Kong Inc., has released Kong 1.0, the latest generally available (GA) version of their flagship API gateway. This version is a "scalable, fast, open source microservice API gateway built to manage, secure and connect hybrid and cloud-native architectures". Although typically deployed at the edge of a network for the handling of external "north-south" API traffic, Kong also be can deployed as a "service mesh" in front of any backend service, and it can be extended via plugins to offer functionality like authentication, traffic control, observability and more.

Although the initial announcement of Kong 1.0 was made back in September, the latest GA release blog post states that "by releasing 1.0 we are making a promise of backward compatibility moving forward." Kong builds upon the open source NGINX proxy, load balancer and web server, and has traditionally focused on providing additional functionality aimed at API management. Kong is available as an open source community edition and enterprise edition. Kong 1.0 GA also brings a focus to implementing a "service mesh", mutual TLS, gRPC traffic support, a new migrations frameworks to ease datastore schema migration, and a plugin development kit (PDK).

Kong 1.0. deployment models
Kong deployment models (image taken from the Kong website)

According to the product website, with Kong 1.0 users can now deploy this in a service mesh configuration by running Kong as a sidecar proxy alongside other service/application processes. However, the documentation for this new functionality, found under the title "Streams and Service Mesh", is currently somewhat limited. The Kong definition of a "service mesh" implies that a mesh is formed simply by Kong nodes establishing a connection:

In Kong the service mesh is built dynamically, and it only exists when there are active connections between the Kong nodes. In short, it means that Kong node dose [sic] not have to know about other Kong nodes, and services do not have to know about Kong.

Other service mesh implementation documentation tends to focus more on the management and orchestration of the entire mesh, and managing the split between the control plane (UI, routing and policy specification, telemetry collection and associated tooling) and data plane (the proxy implementation undertaken instructions from the control plane), e.g. documentation from Linkerd, Istio, Consul Connect. Tutorials also typically requires less manual manipulation of iptables and do not rely on the CLI manipulation of routes that is currently specified within the Kong service mesh documentation. However, this is relatively new functionality within Kong, and the marketable concept of a "service mesh" is still emerging within the wider industry. Community documentation contributions are also accepted via GitHub.

The separation of the data plane and control plane is acknowledged in the release blog post. Before Kong 1.0. engineers "needed to configure each cluster's data and control planes separately", but now "can make a change in a centralised location that will be reflected across multiple Kong clusters". Presumedly this will require the deployment of a Kong cluster, which also requires the installation of a Cassandra of PostgreSQL datastore.

The release documentation also states that one of the reasons for labeling Kong 1.0 now is the successful implementation of the Plugin Development Kit (PDK). The PDK is a set of Lua functions and variables that can be used by custom-plugins, which are created when engineers want to implement their own logic within Kong. The PDK provides a number of advantages over writing plugins from scratch, which include: standardisation -- All Kong plugins require a standard set of functionality, which the PDK provides out of the box; usability -- PDK's interfaces are "easier to use" than the bare-bones ngx_lua API (see the OpenResty lua_nginx_module for additional reference); and compatibility -- the PDK is semantically versioned to maintain backward compatibility, and in the future, plugins will be able to lock the PDK version they depend upon.

Other "cloud native" API gateway products that are competing within a similar space as Kong include KrakenD, Ambassador, Gloo, Contour, Gravatee and several others. Within the proxy space the competition includes Envoy, NGINX open source and NGINX Plus, HAProxy and many others. As discussed in the recent InfoQ emag, there are also many service mesh offerings, including Istio, Linkerd, Consul Connect.

The full list of changes in all Kong releases can be found in the Changelog. There are a number of breaking changes in this release, and accordingly it is recommended that engineers read the suggested upgrade path for 1.0.

Rate this Article