Kong: The API Gateway disruptor

15% off this book with code KONG15

This post was excerpted from this book’s chapter titled, “Kong: API Gateway disruptor,” by one of the authors, Robert Buchanan.

Robert Buchanan is a passionate software craftsman who picks the right tool for the right job. He is a polyglot engineer who has been in all aspects of the cycle as a UI developer, service developer, cloud engineer, and performance analyst.

Kong Inc.: Open-Source API Management

Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware). To be more precise, Kong is a Lua application running in Nginx by leveraging the lua-nginx-module. To get the most out of the lua-nginx-module Kong decided to integrate with OpenResty instead of directly compiling Kong against the Nginx module. OpenResty is not a fork of Nginx, but rather a set of libraries and modules to extend the capabilities of Nginx.

This foundation allows Kong to remain extensible via a pluggable architecture with Lua scripts (referred to as “plugins”) that can be loaded at runtime. Because of this, Kong is seen as a paragon of microservice architecture; at its core it implements database abstraction, routing, and plugin management, which leads to a separation of concerns — the backbone of microservice architecture. Plugins can live in separate code bases and be injected anywhere into the request lifecycle, all in a few lines of code. This capability allows Kong to facilitate the world’s problems, allowing developers to resolve their companies’ problems while not having a steep learning curve.

Kong was originally built at Mashape to secure, manage, and extend over 15,000 APIs and Microservices for its API Marketplace, which generates billions of requests per month for over 200,000 developers. Today Kong is used in mission critical deployments at small and large organizations. Here are some characteristics:

  • Scalable: Kong easily scales horizontally by simply adding more machines, meaning your platform can handle virtually any load while keeping latency low.
  • Modular: Kong can be extended by adding new plugins, which are easily configured through a RESTful Admin API.
  • Runs on any infrastructure: Kong runs anywhere. You can deploy Kong in the cloud or on-premise environments, including single or multi-datacenter setups and for public, private, or invite-only APIs.

API Centric

Most API Gateways are not built with an API first design.

There is the perspective that users only want to interact with beautiful user interfaces and the workings under the hood should be abstracted away from them. This may be true for the general public, who just want to consume the service, but it is a bit of a stretch for the technologically fluent users. Many gateways only ship with a dashboard (tyk.io), an application to craft the configuration (KrakenD) instead of exposing an API to let the user decide how to configure/consume its offerings, or they have both characteristics, but lack simplicity (IBM API Connect,APIGEE).

Kong was built with the API first design pattern allowing users to leverage what they have available in new and exciting ways for the problem that they have to solve for their business. It’s also decoupled some of the concerns gateways try to solve out of the box when the box is loosely defined. An example would be service discovery, where there are several methods and products to do service discovery (etcd, itsio, linkerd, consult, etc.) and a lot of the gateways try to facilitate this functionality, but generally choose one over the other as an opinion causing the users to also choose that dependency when they may have already setup another system. Kong alleviates this by having everything they do internally exposed as an API, which allows the users to build their own hooks or rely on the community to build hooks for these differently defined boxes.

With this design pattern, many great things come for free for Kong Inc. (previously Mashape LLC.) from the community such as a User Interface to administer Kong named Konga, SDKs (.Net, Java) and plugins.

Open Sourced

Open source software (OSS) is crowd-sourced. As a result it has benefits: cost, flexibility, freedom, security, and accountability, which are unsurpassed by propriety software solutions. Moreover, OSS has long-term viability and is always on the cutting-edge of technology. It is created and supported by a worldwide community of organizations and individual developers, many of whom also live by open source values like collaboration and volunteerism.

The cost benefit alone makes OSS highly appealing. The vast majority of OSS is freely distributed. But OSS is said to be “free as in kittens” and not “free as in beer” — it requires maintenance, configuration, and on-going support.

The trade-off is flexibility and freedom. Unlike closed proprietary software, OSS can be altered and extended by any developer familiar with the source code. This grants organizations freedom from “vendor lock-in” and assures long-term viability. A widely adopted OSS project is often supported by hundreds of capable development shops that can always be called upon long into the future.

Kong Inc. has made their API Gateway core open source as they want the benefit of having a following of developers to improve the platform and add capabilities that they couldn’t achieve with just their developers. This far outweighs the profit of running a purely proprietary API Gateway as users can try it out for free then promote it to their businesses driving more adoption in the market. Although their core foundation is free, software is not cheap so Kong Inc. has found a happy medium by offering extras in their enterprise edition (EE), such as plugins like OAuth2 Introspection, Canary Releases, and benefits like an integrated admin UI with Analytics. However their extras are just code into the core, which means they can be recreated by the users (OAuth2 OSS Introspection).

Configurable

Since Kong is using Nginx under the hood, an organization can take their existing Nginx configuration and embed it into Kong’s configuration. This allows organizations to ease into the an API gateway without losing all of their existing working configurations. With this capability Kong allows users to leverage features of Nginx that may not be baked into Kong such as HTTP/2.

A common use case for organizations is to serve up a website (https://example.com) and an API (https://example.com/api/) on the same server. Kong is able to facilitate this by using a custom Nginx configuration template that uses nginx_kong.lua and adds a new location block for serving the website alongside the Kong proxy location information. Here is an example:

http
http {
# Kong's Proxy server block
server {
server_name kong;
# any contents until the location / block
...
# here, we declare our custom location serving our website
# (or API portal) which we can optimize for serving static assets
location / {
root /var/www/example.com;
index index.htm index.html;
...
}
# Kong's Proxy location / has been changed to /api
location /api {
set $upstream_host nil;
set $upstream_scheme nil;
set $upstream_uri nil;
# Any remaining configuration for the Proxy location
...
}
}
}

Along with being able to use a custom Nginx configuration, Kong also enables a configuration file (default location: /etc/kong/kong.conf.default). This configuration file can be overridden by using the -c / --conf flag on startup.

Here is a preview of some defaults:

prefix = /usr/local/kong/
log_level = notice
proxy_access_log = logs/access.log
proxy_error_log = logs/error.log
admin_access_log = logs/admin_access.log
admin_error_log = logs/error.log
custom_plugins = NONE
anonymous_reports = on
proxy_listen = 0.0.0.0:8000
proxy_listen_ssl = 0.0.0.0:8443
admin_listen = 127.0.0.1:8001
admin_listen_ssl = 127.0.0.1:8444
nginx_user = nobody nobody
nginx_worker_processes = auto
nginx_optimizations = on
nginx_daemon = on
mem_cache_size = 128m
http2 = off

These configuration values can also be overridden via environment variables. The format for using environment variables is by using the KONG_ prefix to the setting to override with it being in all capitalized letters. For example the setting log_level can be overridden with KONG_LOG_LEVEL. These environment variables come in handy when you need to update a storage configuration for a particular environment, but want the rest of the preset configurations.

With organizations being diverse in their storage options (relational databases and noSQL databases) using these environment overrides allows quick settings for your storage options per environment to ensure the easiest transition from lower environments (development, test, etc) to production environments with no changes outside environment overrides.

Extensibility (High level)

Configuration is a valuable asset to any software because it allows the users to bend it to their needs. Kong takes it one step further and allows you to write plugins to fulfill the void that is not readily offered. Many API Gateways come with some staples such as rate limiting, logging, and request transformation, and Kong is no different, but it also offers many more plugins out of the gate such as:

  • Basic Authentication
  • Key Authentication
  • OAuth 2.0 Authentication
  • HMAC Authentication
  • JWT
  • LDAP Authentication
  • ACL
  • CORS
  • Dynamic SSL
  • IP Restriction
  • Bot Detection
  • Request Size Limiting
  • Rate Limiting
  • Response Rate Limiting
  • Request Termination
  • AWS Lambda
  • OpenWhisk
  • Galileo
  • Datadog
  • Runscope
  • Request Transformer
  • Response Transformer
  • Correlation ID
  • TCP
  • UDP
  • HTTP
  • File
  • StatsD
  • Syslog
  • Loggly

Along with the provided plugins there are many open source plugins that are available to fulfill what is missing in Kong’s offering for particular problems. These plugins can generally be found from searching the Luarocks repository. A good example of the community solving a problem with a plugin that is not offered in the community edition is an OAuth2 Introspection plugin.

Plugins being developed, and the ability to interact with the core of the gateway is an example of how the ability to develop plugins can solve business problems. A plugin can alleviate some network congestion by doing pre-fetching of data, such as a users profile, and loading it into the gateway cache while adding it to the upstream headers. In this scenario a plugin can reduce the network congestion because it checks the cache and only fetches the profile data based on a TTL (Time To Live). This pre-fetching capability reduces network congestion by 10x or greater because several API’s may require this information. Previously they would each have to make this call instead of just reading the data from the headers.

To aide in the development of plugins the Kong developers have documented a guide on building plugins as well as producing a project seed (we discuss this in our book).

Enterprise Edition: API platform

Software is not cheap by any means because you have to pay developers, pay marketing to get it out in the wild, and pay for support personnel if you want to be a differentiator in a market. KongHQ has not only enhanced their community edition of their API Gateway software, but with their Enterprise Edition they provide an API Platform.

What is an API Platform

An API Platform is more than just an API Gateway, since it contains all of the pieces to the puzzle that enable an organization to hit the ground running while exposing APIs to their consumers. The classic API Platform features are an API gateway, a developer portal, and a management portal. Without offering an API platform most organizations will not want to build all of these missing pieces because they see them as expensive and not a differentiator for their core business.

API Gateway

Instead of walling off the capabilities of their software, KongHQ (formerly Mashape Inc) decided to build their Enterprise Edition (EE) off the core of the Community Edition (CE). By doing this there are a few features that are not available in Kong CE that have been released only under the Kong EE. Some of these plugins are just enhanced counterparts to their CE versions, while others are new plugins. The list will continue to grow as KongHQ finds more business needs to solve for organizations that will pay the premium.

Here is a preview of EE only plugins:

  • OpenID Connect 1.0 RP — OpenID Connect (1.0) plugin allows the integration with a 3rd party identity provider (IdP) or Kong OAuth 2.0 Plugin in a standardized way.
  • OAuth 2.0 Introspection — Validate access tokens sent by developers using a third-party OAuth 2.0 Authorization Server, by leveraging its Introspection Endpoint (RFC 7662). This plugin assumes that the Consumer already has an access token that will be validated against a third-party OAuth 2.0 server.
  • Canary Release — Reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users. This plugin also enables roll back to your original upstream service, or shift all traffic to the new version.
  • Forward Proxy — The Forward Proxy plugin allows Kong to connect to intermediary transparent HTTP proxies, instead of directly to the upstream_url, when forwarding requests upstream. This is useful in environments where Kong sits in an organization’s internal network, because the upstream API is available via the public Internet, and the organization proxies all outbound traffic through a forward proxy server.
  • Proxy Caching — The Proxy Caching plugin for Kong Enterprise Edition makes it fast and easy to configure caching of responses and serving of those cached responses to matching requests.
  • Rate Limiting (Enhanced) — The Rate Limiting plugin for Kong Enterprise Edition is a re-engineered version of the incredibly popular Community Edition Rate Limiting plugin, with greatly enhanced configuration options and performance.
  • Request Transformer (Enhanced) — The Request Transformer plugin for Kong Enterprise Edition builds on the Community Edition version of this plugin with enhanced capabilities to match portions of incoming requests using regular expressions, save those matched strings into variables, and substitute those strings into transformed requests via flexible templates.

Along with the additional plugins and enhanced plugins, the EE also comes with the other parts of an API Platform that are missing with the CE. These missing parts of an API Platform are the Developer Portal and the Administration Portal.

Developer Portal

An organization has an API Gateway that exposes their APIs to the world to consume, however, where does the documentation live? Usually the documentation is handled via a Developer Portal, which will not only allow consumers to register an application (if using OAuth2) or request any API Key (using the key-auth plugin), but it also presents the documentation of the APIs in a clean and crisp format with code samples on how to invoke the APIs.

There are many open source solutions to display documentation, but the management portal and cohesion between the gateway and documentation is generally lacking. While many other solutions offer half-baked documentation solutions (most use an instance of Drupal) KongHQ has embedded their developer portal software with the EE of their API Gateway. This allows features to be developed directly against the API Gateway providing that cohesion to allow things such as automatic discovery and auditing when APIs are published without documentation.

Management Portal

We talked earlier about how Kong was “API Centric,” and while many developers prefer to work in automated ways using tools like curl/postman/httpie to make their configuration changes, not all users of Kong are developers. In fact many users of Kong are infrastructure groups that may understand/utilize the APIs directly, but they may only have the talent pool to only use this side of the configuration. Knowing the industry KongHQ’s EE offers a Management Portal that allows Role Based Access Control (RBAC) security with a user interface to allow even non-technical people access to view, enable, and understand the health of the API Platform. Although KongHQ created a management portal for the EE, some users of the CE were missing this capability as well, which lead to the creation of the Konga Dashboard. This dashboard can be leveraged to achieve the same level of management without paying for the EE.

What is it disrupting?

Disruptive innovation is a term in the field of business administration that refers to an innovation that creates a new market and value network and eventually disrupts an existing market and value network. It also displaces established market leading firms, products, and alliances. Currently, the leaders in the API Gateway space are Apigee, IBM with API Connect, Mashery, and Mulesoft. KongHQ is becoming a disruptor in this space by offering a high quality API Gateway that is customizable and flexible without the high cost of these leaders.

Kong is an API Gateway at heart, while becoming an API Platform for a premium. Although their API Platform offerings are still new, they are bringing a lot of features to this space that are lacking. This section, however, will be focusing on the capabilities of the API Gateway and not the platform as a whole. In this section we will focus on some open source competitors, as well as some licenses alternatives. We will be analyzing these at face value without customizations and without specialized training on each one (knowing the ins and outs of configurations, setup, etc). Through this analysis we will demonstrate why Kong is being a disruptor in the space of API Gateways. We will specifically talk about the Gateway, not the dev portal/analytics that each of these offer.

To begin let’s list the core attributes of an API Gateway that makes or breaks one from being a leader.

  • Cost — Cost is a big considerations because it drives whether an organization only uses the API Gateway for external consumers or if they use it across the organization for all communications.
  • API Configuration — How configurable is the API Gateway? How is it configured (file, environment, API, etc.)? How are configurations enabled (via a reload, restart, or live)?
  • Installation — What are the requirements, dependencies, and difficulty setting up the gateway? On-premise or cloud?
  • Customizability — API Gateways solve the worlds problems but not every organization’s problems. How easy can an organization customize the gateway to solve their problems?
  • Community — Without a community organization, you must rely soley on paid support to aide with questions using a solution. Is the community active? What forms of communication are available (chat, email, forum, etc.)?

Next Steps

This post has analyzed what makes Kong CE a great solution. If you’re interested in learning more, and looking at the Kong architecture to demonstrate how the software works to provide a deeper understanding of why this is becoming a disruptor, you can learn more through the book: “Kong: Becoming a King of API Gateways.”