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 blogs about Kong, I first would like to describe the Kong Gateway briefly. At the time of writing this blog, Kong 2.8 was the actual and latest version.
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 features. It should be noted that the Kong support is excellent, usually fast and giving 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 EE Developer Portal is in a puristic manner (do what is has to do, management of an API catalog). Up to Kong version 2.4, the Enterprise Edition required the use of a database (Cassandra or PostgreSQL). 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 3.x. 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. The product line is completed by a special Kong version called Kong Ingress Controller which operates as ingress controller of a Kubernetes (K8s) cluster. It is a DB-less configuration with K8s manifests as configuration. Recently also a PaaS product option was introduced as Kong Konnect.
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). 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. 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. The Kong plugin system is open, so 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 may be unnecessary because the pod routing is delegated via the service entity directly to the K8s service object. The balancer functionality is therefore left to the K8s cluster.
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 that can receive and execute a declarative configuration description 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 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.
Off the shelf, Kong offers Prometheus
monitoring and Zipkin tracing features (OpenTelemetry in the future). Several
logging plugins complete the observability functionality of Kong.
Conclusion:
