The API Gateway without limits
In the past, I have rarely worked with such a convincing and outstanding product like the Kong API Gateway. Before I start writing further blogs about Kong, let me first describe the Kong Gateway briefly. At the time of writing this blog, Kong 3.2 was the actual and latest version.
Overview
Kong is built on top of NGINX using the OpenResty framework to enable API Gateway features. This design approach enables an exceptionally fast Gateway with low-latency and low-memory footprint.
Kong can be operated as free version of the Community Edition (CE) or the extended and licensed Enterprise Edition (EE). Customers who opted for the enterprise version have access to support services, additional graphical user interfaces and enterprise plugins with enriched feature sets. It should be noted that the Kong support is excellent, usually fast and provides real problem-solving answers.
The EE Kong Manager UI makes the configuration easier for beginners and the so-called Vitals feature integrates analytics and health monitoring. The customizable EE Developer Portal is intended to discover, learn and use APIs.
Persistence
Up to Kong version 2.4, the Enterprise Edition required the use of a database (PostgreSQL or Cassandra). Since version 2.4 there is a further DB-less configuration variant available (configuration without a database), which has not yet enabled the use of the Developer Portal and RBAC-security.
I assume that most Kong customers with persistence requirements select the PostgreSQL database because of the lower resource requirements and the ease of installation, as well as the “maintenance-free” operation mode. Probably Kong tends towards the same direction because they deprecated Cassandra usage and announced a sunset at product version 4.0. Kong customers with pure traffic routing requirements simply go for a DB-less configuration. There is an additional deployment option called hybrid mode. Here you have so-called data planes (DP) running distributed without a database which retrieve the configuration from so-called control planes (CP) which need database persistence. Kong speaks of increased flexibility and reliability1, but on the other side you add distributed communication and increase the setup complexity.
Product flexibility
The product line is completed by a special Kong version called Kong Ingress Controller (KIC), which operates as ingress controller of a Kubernetes (K8s) cluster. KIC is designed to scale with your traffic and infrastructure but the configuration differs, as you have to use K8s manifests as configuration artifacts. Late 2020 also a PaaS product option was introduced as Kong Konnect.
Core components
In essence, the Kong configuration consists of the description of processing pipelines, which always include a route and service entity. A route determines the entry point and to which target service a request is routed (the service provider or backend). The authentication (AuthN) of so-called consumers with possible authorization rules (AuthZ) can be part of the processing. These security AuthN/AuthZ tasks are realized by corresponding plugins that can pull security-related configuration from vault entities. Plugins are functional building blocks and belong to the Kong core entities in addition to the mentioned service, route and consumer entities.
In general, plugins determine the sequenced processing steps and functionalities during a request-response lifecycle. They are assigned to NGINX operation phases with a given priority determining the order of processing. Recently Kong offers a dynamic plugin ordering feature limited to the NGINX access phase, which allows to change the priority to implement dynamic dependencies between plugins (previously this could only be achieved through plugin cloning or patching).
Plugins
The Kong plugin system is open, meaning that out-of-the-box plugins, additional enterprise plugins, community supported plugins or self-written custom plugins can be used. So-called serverless functions are special cases in which individual source code modules can be integrated without the need of writing plugins. Plugins implement all kind of policies and can be declarated as “global”, meaning always running, or mapped to a route, service, or consumer entity for targeted execution.
An upstream entity includes optional load balancer functionality. When running on a K8s cluster an upstream entity can be omitted since the pod routing is delegated by the service entity directly to the K8s service object. The balancer functionality is therefore transferred to the K8s cluster.
Configuration
Kong configuration may be realized by using the interactive Kong Manager UI or via REST calls against the Admin API. The decK tool and the Kong CLI (Command Line Interface) offer further ways of configuration. Both can receive and execute a declarative configuration description which can also be given at the start time.
The abbreviation decK stands for “declarative Kong” and provides additional configuration and so-called drift detection features. In my opinion the best CI/CD-friendly configuration for a DB-less pure traffic-routing approach is the Kong CLI import of a declarative YAML configuration file. The decK tool is often advertised by Kong but still not part of the product itself and the advanced features are simply unnecessary when taking an immutable deployment approach.
Observability
Off the shelf, Kong offers Prometheus monitoring and Zipkin tracing features. Since version 3.0 Kong also offers an OpenTelemetry plugin. These plugins are supplemented by two statsD plugins, an open-sourced and EE advanced plugin that is deprecated since 3.0. Several logging plugins complete the important observability functionality of Kong.
Conclusion
After more than three years of dealing with the Kong Gateway in a challenging environment with multiple complex policy demands, I can safely say that Kong is the right API Gateway. Especially in a pure traffic routing approach where additional API management features are not playing an important part (like a socialized or monetized API). Missing functionality can be easily added by a serverless function or writing a custom plugin utilizing one of the the plugin development kits (PDK). Lua, the original plugin programming language, is quickly learned, but recently also support for Go, JavaScript and Python has been introduced. Coming back to my opening statement, with the Kong Gateway you will not run into any limitations.
Credits
Title image by jamesteohart on Shutterstock
