Recently we looked at API Gateway products for a microservices project. The constraints were that on-premise was preferred, low-cost was preferred, and open source would be fine. While we could have built something simple, the thought was that a product would have more in the way of management and monitoring features.
We ended up looking at Tyk (https://tyk.io/). It’s based on an open-source project (with the API Gateway itself written in Go), with commercial add-ons and additional hybrid or cloud options that we didn’t review. I’d characterize the on-premise installation as a capable product that’s not yet mature. The documentation is not yet as in-depth as you might like, and features are still coming in. Yet it hit many of the punch-list items for this case:
- Can configure the gateway, dashboard, and services via setup scripts (using a REST API) or via a Web GUI
- Supports a REST facade, in which you define a pretty API in Tyk that maps to a messier back-end service API
- Supports versioning of services
- Supports JWT for authentication, including extracting JWT claims into HTTP headers for back-end calls. (It also supports OAuth 2 and a list of other authentication mechanisms, which we didn’t explore for this project.)
- Configurable CORS support, for calls built in to JavaScript apps served from elsewhere
- Supports Swagger documentation for services (which it displays in a “developer portal”)
- Supports rate limits and similar restrictions on API usage
- Provides metrics/analytics such as the number of successful and failed API calls per user, per API, and etc.
- Multiple installation methods, including direct, Vagrant, and Docker
The gateway itself is free, though the Web configuration/management app is not. Well, they say they will issue you a 1-year license for the “Dashboard” for free and re-issue it as needed. We had no trouble getting the free license, though we haven’t yet used it for a year to see if it’s as easy to renew.
The Tyk Stack
The Tyk stack has five moving parts:
- The API Gateway, the main workhorse
- A Redis database, used by the Gateway
- The Dashboard, a Web app that can configure the Gateway using its REST API and display monitoring information
- A MongoDB database, used by the Dashboard (e.g. with aggregated request data)
- The Pump, which reads out of the Redis database and populates the MongoDB database, needed to provide aggregate data in the Dashboard.
None of those last three pieces are needed for core functionality; they just support the Dashboard. But the Dashboard is pretty convenient, so it’s hard to recommend going without it.
The Developer Portal, though conceptually a separate piece, is handled as a service running in the gateway.
Limitations
Some of the reasons I say it’s not fully mature:
- Some of the features we used were so new they were documented only in release notes, not in the main product documentation
- In at least one case the documentation neglected to mention that you must check a certain checkbox on a different page (which defaulted to off), without which all of the things described in the document would silently fail. More on this in a future post.
- The different installation methods use different setup scripts. Scripts meant to run in Ubuntu work in some versions but not others due to differences in the Python stack.
- The setup walks you through configuring several URLs, without really explaining what the different ones are going to be used for. In general it doesn’t give a good overview of the Gateway vs. Dashboard vs. Developer Portal
- There’s plenty of guidance for test installations, but less for production installations. What they have punts on the database configuration, telling you to configure and secure the two databases as recommended by those vendors. That’s fine if you already have MongoDB and Redis in production, but not so helpful if you don’t.
- Error logging was limited. Things were split between undocumented database records, standard output, and log files. The GUI option to display error logs doesn’t show necessary detail for debugging. Overall, it was missing a single point of “this is what’s wrong” that would help identify and correct configuration problems.
- The analytics were limited. You could track API calls by service and by user (and successful vs. failed), but for instance there wasn’t a great way to group users by company and aggregate by company. The main use case seemed to be public-facing services where every user was an individual, not business partners were the users would be grouped. Further, there wasn’t a way to drill into an aggregate result in more detail. The high-level information looked nice, but to get into detail you’d need to explore the Redis data on your own.
- Just in the last month, among other things, Tyk has added a Kubernetes installation procedure and initial support for automating Let’s Encrypt certificates. Previously, support for reading data out of JWT tokens was hot off the presses, and has only just now arrived in the product documentation. While it’s great to see product development, the rapid feature additions give the impression that Tyk is still a work-in-progress.
That said, the price is right and you might be able to live with or ultimately work around these limitations. We went forward with Tyk for the time being. Over the next few articles, I’ll look at some of the specific issues we ran into and procedures or workarounds we came up with.