Hi Team, Current issue -
We are currently using TYK 2.5.1 version which does not have support for response object needed to log response related info. Also , we are facing TYK compatibility issues with grpc plugin with 2.5.1. version .
So we are planning to upgrade tyk to a newer version.
We have currently identified two TYK versions to upgrade i.e. 3.2.1 and 4.3.x ( TYK 5.x is not prefered as of now as TYK R5 is recommended to Use after June 2023. Refer - Long Term Support Releases)
Our Requirement -
To get the response object for logging purpose (which I believe is supported in both the identified versions i.e. 3.2.1 & 4.3.x)
To get the compatible grpc plugin with new TYK version ( Which is again available in both 3.2.1 & 4.3.x)
Our current setup in production -
We already have 3.2.1 TYK docker deployed in cloud world. So we are prefering to to upgrade the same version also in VM world ( Currently using tyk 2.5.1).
Functionality we are currently using in TYK 2.5.1 -
We are using JSON based proxies ( both Soap & Rest APIs) deployed in TYK ( We are not using any open API spec)
We have custom middleware policy for rate limiting.
We are not using TYK dashboard , TYK analytics, GraphQL & Open API specs. ( This is the major change i noticed b/w 3.2.1 & 4.3.x)
Questions -
As we have noticed that both TYK 3.2.1 and 4.3.x suffice our requirement .
So I am wondering if there is any performance improvement in TYK 4.3.x over 3.2.1.
Is there any reported Security vulnerability in 3.2.1 which is fixed in 4.3.x version If that is not the case , Can we move ahead to upgrade TYK from 2.5.1 to 3.2.1 ?
I hope i am able to explain our requirement . Kindly suggest the best suitable TYK version for upgrading.
So I am wondering if there is any performance improvement in TYK 4.3.x over 3.2.1.
We do our best to improve the performance of the gateway at each release but it is impossible to give a general answer to this question. They only way to know is to perform benchmarks with the typical load your systems APIs.
Is there any reported Security vulnerability in 3.2.1 which is fixed in 4.3.x version
I’m not aware of any.
If that is not the case , Can we move ahead to upgrade TYK from 2.5.1 to 3.2.1 ?
This isn’t for us to decide, best practice is to do acceptance testing, load testing as well as implementation and backout testing before deciding.
Can you please guide us with what all benefits we will get if we move to 4.3 or later?
Please note, as mentioned above, we are not using Dashboard and not having plan of using GraphQL & Open API specs.
Is there any change in hardware requirements from version 3.x to 4.x or 5.x?
Also, Can you also guide us if R5 is in Beta at this moment?
Can you please guide us with what all benefits we will get if we move to 4.3 or later?
We don’t advise the use of 4.3 at all. As per the long term support policy 4.3.x will not receive bug fixes now that 5.0 has been released.
The primary benefit you will get from running a more recent version is that it will receive patch releases to fix bugs and we who support Tyk will be more familiar with it. The version you are running now, 2.5.1 is so old that I personally have never used it, but if you were running the latest patch of the 4.0.x branch you would be on the same version as hundreds of customers.
Please also refer to the release notes for more details of what is included in each release.
There are more details of specific defects fixed with each release and patch on the github release page
Is there any change in hardware requirements from version 3.x to 4.x or 5.x?
No, but it is essential to test thoroughly in your environment under production like loads.
Also, Can you also guide us if R5 is in Beta at this moment?
No, 5.1 is currently in beta, 5.0.1 was released three days ago, and 5.0.0 about a month ago.
What is recommendation from TYK team regarding how much time we should give any version to get matured before having it in production. I mean, as you mentioned, 5.0.1 was released 3 days ago, so is it available for dev and staging environments or customers are (or already have) migrating to the new version?
It simply means R5 will be our main focus in releases and patches. Of course no software if free of bugs, so if there is a critical or security fix needed in a previous version like R4, then we might do it. If not, then we may just suggest you upgrade to R5 which would have the latest patch or fix.
I’d answer this question based on the Hypercare period. However, you could give some room for gotchas, so something like 6 months is also okay. Ultimately your upgrade period would depend on a number of factors like your deployment architecture and business needs. For example, a security patch could force you to upgrade quicker than expected in order to mitigate any security vulnerabilities.
The one thing you always want to do is to ensure you have run your tests on the version you wish to migrate to on some sandbox environment like dev or staging before completely migrating a prod environment.