Sweet Shyamalamadingdong! Tyk v2.3 is out!
If API Gateways were professional wrestlers, Tyk would probably be a Luchador… she would use different stage names: Pirata Rosa, Presidente Misterioso, or La Fenix Mayor, and each persona would instill quivering anticipation with onlookers: “No! Not Pirata Rosa!” they would whisper in their lunch break, “I heard she made El Ruso Picante eat his own mask, after she kicked his ass with a rubber chicken….”
“This one time, La Fenix Mayor strolled into the ring,” they said in hushed tones, “she took one of the fans of El Coyote Magico, and then beat him to death with his own feet!”, tickets to her shows would sell in the millions, her fans would be adoring, her fame would spread across the world and she would be so renowned that the Mayor of Funkytown would need to erect a statue to her honor… Tyk the API Gateway, the Luchador-of-Luchadores, the Beater-of-things, oh it would be magical…
Ok, so maybe I’m going totally off-topic here… we’re here to talk about the newest, shiniest, most kick-ass-iest API Gateway update in the history of API Gateway updates.
So what’s new pussycat? Let. Me. Tell. You:
Performance, performance, performance, performance… wait, did I mention performance? Performance.
That’s right: Tyk v2.3 can handle more than twice the traffic that v2.2 could, on top of that, it’s more efficient in how it handles Redis, and it’s more clever in how it manages its traffic.
The latest incarnation of Tyk comes with a distributed rate limiter. This new module means that Tyk no longer needs to synchronise rate limits across a cluster via Redis, and instead does so by ongoing inter-cluster chatter and a distributed in-memory token-based limiter that is eventually consistent, instead of hard-synchronised.
The new rate limiter is also more forgiving, if you set a limit of 1 request per second, then one request per second will always get through, whereas previously the client would need to implement some kind of back-off strategy.
This also means an overall reduction in the amount of Redis traffic coming from the Gateway that ensures that the Gateways scale effectively as CPU cores increase.
And all of that culminates in a really cool, auto-scaling system that can handle a bunch of traffic, efficiently and effectively.
You want to extend Tyk? Have I got some news for you…
So if Tyk were a wrestler, then if she were to use a weapon outside of the ring (as you do), unlike most other wrestlers that are limited to using only one tool, usually a poor spectator’s chair. Tyk – or La Fenix Mayor!, to use her nom-de-souffrance – will use the spectator’s chair, the spectator’s backpack, the spectator’s handkerchief, or even the poor spectator themselves to beat her opponent to a whimpering mess.
(That’s quite a strained metaphor, I’ll admit.)
What we’re saying is that in Tyk v2.3 you can add pre-processing, post-processing, and custom authentication middleware in more than just one host language. With Tyk, you can add plugins using… clears throat, drumroll:
- JavaScript (ECMAScript 5)
- Python 3
- LuaJIT (beta)
- Any language that speaks gRPC: Ruby, NodeJS, .NET, Java, Python and Golang to name a few
That’s right, if you want to add a custom authentication server to Tyk and you want it to be fast, you can use any of the above to extend how Tyk works.
The new plugins feature means that on top of all the native goodies that come with Tyk out of the box, extending it now fits the needs of your team and not what we (or anyone else) impose on you. It’s all about flexibility and performance, and here, we perform very well.
Performance
While Tyk v2.3 can easily handle 2,000 requests on commodity hardware, when you start introducing plugins and host languages you can see a bit of a performance hit, but that performance hit, in Tyk, is designed to still be plenty fast. In our benchmarking, Python 3 plugins performed at about 1,300 requests per second with sub-100ms latency, while gRPC with a local gRPC host gave us 1,400 requests per second with sub-100ms latency.
This is important, so I’m going to say it again: You can extend Tyk with almost any language you chose, and get blazing-fast performance to boot.
Pre-built plugins
Now we’re not saying “we have all this cool new stuff for you but you need to do it yourself”. Hell no! We always like to add value – just look at all the cool features that come built into Tyk natively. No, we like to go further, to go deeper. With this release, we’ve also been hard at work fashioning some initial plugins that are 1, pretty damned useful, and 2, a great starting point for setting up your own.
Some of the more awesome plugins that we’ve put together are:
- Loggly integration
- Datadog integration
- Bot detection
- Message Queue integration (AMQP amongst other message queue hand-offs)
- Webhook sidecar
- Correlation IDs for request logging
We’ve also generated demo’s to get you started in your favourite languages for:
And we’ll keep going…
Is this the future of Tyk?
In a word: No. Unlike other vendors, we like to pack value into our offering, and we don’t want to take the chicken-sh*t way out and force our customers to maintain their own plugins, or forks of ours in order to add functionality to Tyk. We don’t want you to increase your technical debt by having to maintain customisations to Tyk over huge swathes of time.
So our plan is to continue adding great functionality to the Tyk OSS core, and even migrating popular plugins into the core so that they are available to all “at the speed of Go”, while giving our users the flexibility and capability to make it easy to integrate Tyk with your systems.
In future, we may opt for creating plugins for Tyk in Go itself, at which point things may change, but for now: Tyk is there to make sure that you can get your sh*t done and get it done well.
Other cool stuff
So the above two features are pretty much the biggest, baddest announcements that come with Tyk wading into the ring with v2.3, but we have also been busy fixing up bugs and adding smaller, nice-to-have features to the overall system, I’ve listed a few below because they are pretty cool, and it’s nicer to read them here rather than parsing our changelog:
Environment variable configuration
This is a dull, but very useful change – you can now configure all of the Tyk Gateway, Analytics and Pump settings via environment variables – more precisely – you can override them. This is extremely useful for those of you deploying into Docker orchestration environments such as Kubernetes where files aren’t fun to deploy.
Live Gateway logs in the Dashboard
A lot of the debug information in Tyk comes from the Gateway log (stderr) output, so we’ve made it so that key log operations are also copied through to a live Dashboard view – this way you can quickly check why an API hasn’t loaded or if a system event or error has occurred without reaching for the raw logs from the Gateway hosts.
Custom error templates per response code in XML or JSON
This is a popular request, you can override all of our error templates, per-status-code, in either XML or JSON, this means you can have much more control over how your API Gateway responds to end users when errors occur.
Chained authentication methods
A popular request from the community – having the capability to have HMAC-based message signing in conjunction with a bearer token. With this mechanism, you can actually use many different authentication methods chained together in order to provide maximum security for your applications.
Hot reconfigure and reload of the Tyk Gateway process from the Dashboard
Tyk has always been able to hot-reload from the command line, but we’ve made the process smoother and more efficient, not only can you send a signal to the process to fork and start a new process without dropping any connectionss, but you can also hot reload from the Dashboard and also re-configure the Gateway in the process without having to set foot on the host.
(Naturally, this feature can be disabled!)
A new CLI tool to help you build and deploy plugins
Having so many plugin options means we needed a better way to publish your code to the Gateway layer, and to make that work, we’ve started work on a CLI tool, this tool currently can only do one thing: sign and package up your plugins so that they are cryptographically secure and guaranteed before being deployed (and verified) by the Gateway.
But this project will keep growing, and more and more functionality will be added to the CLI to make it easy to script common Gateway operations.
More logger integrations
Tyk v2.3 now has logger integrations for:
So that you can aggregate your Gateway logs into the system of your choice.
Separate Redis cache
For those using our caching mechanism, in very high availability environments you do not want to have your Redis cache be the same database that is used by Tyk for configuration information. With this update it is possible to completely separate out the cache to a different Redis database or cluster.
More portability: Import/Export API
It is now possible to backup and re-create your Organisations, Policies and APIs using a dedicated import/export API. This will allow you to completely re-generate an installation from backed up assets without worrying about mis-attributed IDs.
LetsEncrypt support
A fun, and currently experimental feature, the Tyk Gateway can now auto-provision SSL certificates for your domain-bound APIs so you do not need to configure them yourself. All certificate information is encrypted and shared across a cluster so that subsequent visits to your Gateways are fast and scaleable.
That’s all folks
Until we meet again – we’re already planning v2.4 and have some very cool stuff in the pipeline for you. As always, get in touch with us on the community forum, or directly via Twitter, to give us feedback or ask any questions.
For those of you on v2.2, we have created some upgrade notes.
Now… back to the ring.
Martin and the team at Tyk Towers in Shoreditch, London.
