API gateway comparison: Kong vs. Tyk

Kong vs. Tyk: Meet the contestants

Kong was released in 2011 as a private API gateway and now is an open source project, governed by the Apache 2.0 license. It's built on top of Nginx's HTTP proxy server and written in the Lua scripting language, and users can deploy it both on premises and in the cloud. A Community Edition of the open source tool contains a range of features, including load balancing, service discovery and health checks, but lacks a management dashboard, although users can apply an open source Konga GUI. The Enterprise Edition includes a comprehensive management panel, additional features such as role-based access control, real-time monitoring, OAuth 2.0 Introspection, and flexible customization, and 24/7 maintenance support from the provider. 

Founded in 2014, Tyk is also an open source API gateway, but it is under the Mozilla Public License (MPL), which is a little more restrictive than the Apache 2.0 license. Tyk is built on top of the Golang HTTP server and written in Golang, which some developers associate with higher throughput and more efficient request management. Tyk also accepts plugins written in languages other than Golang. Users can deploy Tyk in the cloud, on premises or in hybrid environments. Tyk users can create unlimited gateways and manage them in a headless manner. The paid version of Tyk includes a management dashboard.

Architectural differences

Kong uses servers and a datastore. The Kong server, which acts as a proxy between the clients and the APIs they request, has two layers. The public layer exposes APIs to end users and funnels user requests to the back end, while the private layer configures and manages the APIs and the installed plugins at the back end.

Kong's datastore holds the data related to the plugin and API configurations. Kong supports PostgreSQL and Cassandra, and runs on its own cache, although some plugins rely on external components, such as Redis for rate limiting.

Tyk, on the other hand, has three components. The gateway manages and routes API calls to their respective APIs. The dashboard provides controls to manage APIs and visualizes important data pertaining to the APIs. The storage component, Pump, holds and exports API data to external databases. Tyk supports Redis and MongoDB.

Overall, Kong is more community-driven, pluggable and extensible, whereas Tyk is predominantly developed by its parent company with a focus on day-to-day operational simplicity. 

Performance and scalability

Kong surpasses Tyk in benchmark tests on outright performance, and more efficiently handles concurrency and instance scaling in the back end, which is important because API calls can spike to thousands of requests per second. However, those tests showed Tyk easily handles up to four thousand requests per second, which is sufficient for most organizations. Tyk also claims its recent versions achieve better performance with some functions disabled such as authentication and monitoring.

Scalability is highly important for an API gateway because of the distributed nature of microservices-based applications, and Kong and Tyk both are easily scalable. To scale Kong horizontally, users simply create more nodes and connect them to the same database. The only point of failure is the database; for high availability, you must create multiple instances of the same database.

To scale Tyk, users create a Tyk API gateway instance and link it to the same database. They also must implement a host of tweaks and optimizations to ensure it runs at peak levels, such as space management to accommodate Redis and MongoDB clusters. Tyk relies on CPU power more than RAM; once CPU utilization reaches 60% to 70%, Tyk advises users to add another node and processing cores.

Plugins and custom features

Kong is extremely community-driven and offers more plugins (77 as of this writing) for functions such as basic authentication, security, serverless, deployment, logging and more. However, some plugins, such as LDAP authentication, are only available in the Enterprise Edition. You can also create a custom plugin to fit your specific needs using Lua, as Kong contains the OpenResty package and is based on Nginx.

Tyk also provides various plugins for authentication, logging, security and more, but the list is limited (fewer than 10 plugins) and all are built by the parent organization. Tyk provides plugins to help set traffic quotas and import from Swagger or API Blueprint. Tyk also enables creation of custom plugins for specific needs, and has an edge over Kong because it supports their creation in multiple languages including Javascript, Python, .Net, Golang and gRPC.

CI/CD and Kubernetes integration

Organizations across the globe embrace CI/CD for faster development and deployment. Both Kong and Tyk are compatible with Kubernetes and can easily plug into CI/CD pipelines, which lends well to declarative infrastructure and processes. Kong has an edge because it's more widely integrated with more cloud platforms, including the powerful Prometheus monitoring tool.

Kong plugins better integrate with Kubernetes-driven CI/CD pipelines, with various ways to install Kong on Kubernetes via a Helm chart, Google Cloud or the Kubernetes Ingress Controller. Other plugins include a Kubernetes Sidecar Injector to form a service mesh on top of Kubernetes, and the aforementioned Prometheus plugin to better monitor Kubernetes clusters.

Tyk can be installed via Helm charts, and it also has a Kubernetes Ingress Controller to interface between Tyk and the Kubernetes API, as well as a service mesh controller -- although those are available in the paid edition.

Community support

Both Kong and Tyk are open source and rely on active community bases for contributions, vulnerability identification and extensions to various platforms. In this sense, Kong enjoys better community support -- on GitHub, Kong has nearly 24,800 stars, 160 contributors and 5,400 commits, compared with 4,900 starts, 54 contributors and 3,100 commits for Tyk. Similarly, on Stack Overflow, around 300 user questions tag "Kong" versus 36 questions tagged for "Tyk." This suggests Kong customers can expect faster results from these active developer communities, whereas Tyk users may prefer to rely on a Tyk support team.

Kong is based on Nginx and OpenResty, both of which are third-party components. If there is a problem with any of those third-party providers' components, developers must wait for the provider to make an upstream fix. However, Kong requires that developers create custom plugins and features with Lua scripts, which limits their options.

Tyk, on the other hand, allows support for various languages, which means developers can write custom plugins using their preferred programming language other than Golang. Tyk is based on Golang, so there is quicker support for any bugs in Golang.

Kong vs. Tyk: Which API gateway fits your needs?

The best API gateway for your applications depends on your organization's requirements. Kong is a better option for outright performance, whereas Tyk offers good performance with an eye on operational simplicity.

If your organization wants an API gateway that is packed with plugins, and doesn't mind writing custom plugins, Kong is a great choice. However, if you want more flexibility in the programming languages to write custom plugins -- and you're sure you can manage them somewhat on your own -- you should go for Tyk. For those who prefer a vendor to guide them rather than rely on an open source community, Tyk is the way to go.

Cost comes into play as well. Tyk is transparent about its pricing -- a free one-month proof-of-concept license or a $9,000 per environment production license -- but you'll need to contact Kong's sales team to get a quote. Organizations can scale up Kong for free by simply creating new nodes. Tyk's community edition restricts some functionality to do this. However, Kong lacks features in its community edition that Tyk provides, such as metrics and logging, and users may need to rely on third-party tools for a free control panel -- and consider whether they can depend on them for uptime.