A major WSO2 version upgrade will be needed at regular intervals, to avoid buildup of technical debt. However, many companies are pushing an upgrade forward, making the gap to be bridged bigger and bigger.
This blog draws from a recent upgrade project for a Yenlo Connext customer. More information on Yenlo Connext, our 24/7 hosted and managed WSO2 cloud solution, can be found at solutions.
Why upgrade anyway?
An upgrade keeps your WSO2 implementation in good shape. Please note however, the most direct need can be found in urgent (security) patches as they occur. The longer your last major upgrade is behind you, the more problems an urgent patch will present to you. To the point that you may have only bad options. Even if you would manage to roll out that patch in isolation, maybe with some tweaks, then your product configuration is no longer formally supported. Remember the log4j issue, which emerged in late 2021? That caused a lot of trouble for companies that were lagging behind in software configuration. You simply don’t want to upgrade in a very short time frame, with a lot of stress, while your security is on the line.
The actual Yenlo Connext platform version was already safeguarded from the log4j vulnerability. Notwithstandingly, Yenlo issued an interim release with additional security settings, as a temporary precaution. Log4j was attracting a lot of attention around the world, you could not know what’s next. In any case, each Connext customer that was using the latest and greatest platform version was already safe.
Our message: avoid a rusty configuration!
Upgrade approach
At Yenlo, we aim to separate the integration platform from the artefacts running on it. Making the upgrade and copy/restore of an environment so much easier. A proper automated deployment pipeline serves to rapidly and consistently redeploy platform versions and artefacts. Also, we aim to store stateful transaction data separately. Yenlo Connext has been realized accordingly.
In the project at hand, the upgrade was realized according to customer’s planning. First of all, a new and temporary upgrade environment was provided, which was preferable over an in-place upgrade, so as not to interfere with ongoing development work.
Subsequently, the artefacts were deployed and (regression) tested. In preparation for the PROD roll out, a runbook was made and followed.
Steps
In more detail, the upgrade comprised the following steps.
- Make a separate upgrade environment available. For Yenlo Connext, this step is easy, using the Connext automated platform pipeline, avoiding manual activity.
- Many customers deploy custom components on an environment, when needed for specific integrations. For example, a specific library for encryption, hashing, etc. Hence, it is important to document what custom components apply. The Yenlo Connext platform pipeline can be adapted to incorporate such custom components, in order to keep the environments consistent (TEST, UAT, PROD) – and avoiding manual activity.
- Next, it’s time to establish connectivity with the endpoints involved. Connectivity often comes in various forms, e.g. public internet access, private network access (using VPN), IP whitelisting. Again, it is important to document these properly, to avoid reverse engineering during the upgrade project.
- Certificates also require attention. They may be used for various purposes, such as caller authentication and response signing. Once more, keep track by proper documentation. If you want to verify the proper functioning of the certificates on the upgrade environment, then it does make sense to request and install the applicable certificates. In practice, this is often a time consuming process, on the critical path of planning.
- After that, the services can be deployed on the EI of the upgrade environment. Often, this takes place long after the original developers have moved to other projects or employers. Hence, you need documented deployment guidelines for your Support Team, so that they can deploy with minimal knowledge and effort.
- Likewise, the API’s need to be deployed on the upgrade environment. Provide client id and secret where necessary, enabling API callers to generate access tokens. For Yenlo Connext, this is one of the standard actions by Yenlo’s Support Team.
- In the project at hand, WSO2 Identity Server was not used. If it does apply in your case, then identify the preparatory actions, enabling you to test IS in connection to the platform upgrade.
- At this point, your upgrade environment is ready to be tested. Standard regression tests will help (happy flows and edge cases), together with Postman sanity checks. The average major upgrade will have little impact on non-functionals. In practice, the receiving systems tend to be the limiting factor when it comes to handling volumes. This is unlikely to change by a platform upgrade. In the project at hand, the tests revealed no issues, giving confidence for the rollout to PROD.
- Before going live, there is still the question whether to go for an in-place upgrade or to fully replace PROD. Each choice has some pro’s and con’s. For Yenlo Connext, we chose the in-place upgrade, because facilitated by the available automated pipelines.
- As the last preparatory step, a runbook for UAT and PROD deploy needs to be made. Even if you are confident that the planned upgrade is under control, you still need to think about practical matters, such as:
- block the input to the integration platform, and wait for completion of any ongoing transactions (e.g. watch the queues becoming empty), leaving no unfinished work in the middle.
- inform upstream and downstream application managers about downtime
- organize standby of specialists when restarting
- verify proper processing of first records after restart
- pay attention to a rollback scenario
That’s it! These steps should point you the way. In the project at hand, the upgrade was realized smoothly.
Conclusion
When upgrading your WSO2 or Yenlo Connext environment, you will benefit from previous discipline in maintaining:
- stateless environments
- automated platform deploy pipeline, making it more easy to keep your configuration up-to-date, and to keep it in sync between different environments
- automated artefact deploy pipeline, making it more easy to (re-)deploy artefacts as needed
- documentation on artefacts, custom components, connectivity, certificates, deployment guidelines, sequence diagrams, and more
- regression test sets
- built-in sanity checks (e.g. Postman), good use of logging, monitoring and dashboards
If you deviate from this path, the cost of your upgrade effort will increase, and delay it significantly. Besides, the risks at the time of a major version upgrade will increase as well.
Yenlo Connext provides the required tooling as described. Together with the Yenlo Way of Working, you are guided to success in a major version upgrade. Besides, Yenlo can support with ample expertise. This puts you in a position to upgrade more frequently and not perceive it as a big barrier. Thereby avoiding the problems of deferred maintenance.
