Why might you be considering moving from Kong to Tyk? In all likelihood, it’s because you need to do something that you can’t manage with the open source version of Kong.
Do regulatory changes mean that you need to apply a new technology, such as mutual TLS? Is one of your APIs getting so much use that you need to back up rate limiting with a high-performance, high-availability database?
Whatever your reason, Tyk’s “batteries included” approach means that our free, open source API gateway can achieve what you need, straight out of the box. Let’s dive into the detail…
What do you get with the open source gateway from Kong versus Tyk?
Kong provides two versions of its gateway – a community edition and an enterprise edition. We’re looking at the free, open source community edition in this article. That includes the gateway itself, Kong Hub (a repository of plugins and integrations), OSS plugins and plugin development.
Tyk provides just one version of the gateway, which both our community users and our enterprise users can enjoy. It is fully featured straight out of the box, meaning there’s no requirement to spend time adding plugins to your setup.
Tyk’s open source gateway includes a range of features out of the box that Kong’s does not. These include:
- Authentication – Tyk can use mTLS and OpenID Connect and can hash API keys.
- Traffic control – Tyk supports high-availability, high-performance rate limiting and clustered Redis. It supports enforced timeouts, circuit breakers and mock endpoints. It has advanced URL rewriting functionality and supports JSON schema request validation. All straight out of the box without a plugin in sight.
- Analytics and Monitoring – Tyk supports NewRelic and StatsD, while Kong supports Prometheus, Datadog and Zipkin.
- Transformations – Tyk supports method transformation, whereas Kong transforms gRPC to HTTP.
- Logging – both Tyk and Kong support File, StatsD, Syslog, Moesif and Splunk. Tyk also supports ElasticSearch, Graylog, InfluxDB, Kafka, Logz.io, MongoDB, SQL and Stdout, while Kong supports Loggly, HTTP, TCP, UDP, Google Cloud and Google Analytics.
Likewise, there are things that Kong’s OSS API gateway provides that Tyk’s does not. For example, Kong has a bot-detection plugin and supports third-party serverless functions (AWS, Azure and Apache). Kong’s open source product can also run without a database (with some compromises) and has a dashboard GUI, albeit with restricted functionality.
Tyk, meanwhile, can accept batched requests, has a more modular architecture and supports tracing with Zipkin and Jaeger. Kong has a wider range of orchestration tooling. Tyk’s plugin development supports a wider range of languages.
There are plenty of differences between the two solutions, but perhaps the most fundamental difference is that Tyk’s open source gateway is designed to provide all users with maximum functionality straight out of the box – for free and forever. We haven’t designed the gateway to give non-paying users just a taste of what paying customers get. It’s the full product, with batteries included and a gift bow neatly tied on top.
How easy is it to move from Kong’s open source API gateway to Tyk’s?
In some respects, migrating from Kong to Tyk is simple. The outline process has just five steps:
- Create a Tyk deployment.
- Migrate over configuration and data.
- Apply any additional changes as needed.
- Test the Tyk deployment is functioning as expected.
- Switch your API traffic to use the Tyk Gateway.
Of course, no migration is ever that painless! Migrating the configuration between systems could involve a fair chunk of work, especially if the Kong setup contains a lot of APIs and other data. Some parts of it may be scriptable, but it’s likely that there would be a substantial amount of manual effort. Data such as API keys and user accounts may also need to be migrated and this would also require effort.
It’s the same with any migration – you can’t just click a button and make it happen, as every migration is individual, based on the user’s needs and existing setup, which software versions they’re using and myriad other factors.
What are the benefits of using Tyk OSS versus Kong OSS?
Tyk’s OSS gives you the full package. It’s easy to use, completely free and comes with a super-helpful, supportive community, as well as expert support from the Tyk team. In fact, this stellar support is something that our users regularly tell us sets Tyk apart.
“I’m really excited about Tyk’s future, and Tyk’s renewed commitment to its open-source customers. We’re moving towards an API-driven, API-first world, with technologies like GraphQL changing how developers interact with data, and with Tyk’s support of its open source gateway product and the user community, more teams are going to be able to move there faster.”
Jonathan Dursi, Staff Scientist II at UHN and lead for CanDIG (read the full case study)
For organisations where authentication is particularly important (banks or healthcare providers, for example), Tyk’s open source gateway delivers everything that’s needed, straight out of the box. This delivers both robust security and peace of mind for our users.
The ability to use mTLS and OpenID Connect is also a major benefit for many users. As the CanDIG team recently observed, “Tyk’s open source gateway was the only API gateway on our long list of candidates that supported multiple OpenID Connect identity providers out of the box.”
Ultimately, it is Tyk’s vast flexibility that is at the core of why so many users are benefiting from the product. Company.info, for example, found in Tyk the perfect solution to fit with their Kubernetes environment, connect with their Gitlab CI/CD pipelines and connect to their accounting systems. Our API-driven and event-enabled approach were key to this. By being able to pick the parts they needed from such a full offering Company.info found that it was easy to get started and that Tyk integrated very well with their existing components.
Another user – Alyce – was delighted that having a consistent entry point that follows the OAS v3 enabled access for the company’s entire global team, while also meaning they could continue to adopt different tech stacks in both Golang and Python. Backend Engineer Vasiliy Toporov observed:
“Every new service now begins with Open API Spec. So it’s all API first.”
