Revolutionizing the product update with WSO2 Update 2.0

Every software application undergoes various changes over time and as a result, we get patches/ hotfixes, updates, and new version releases. Those changes can be either architectural/ technical changes to suit the current technology landscape or functional changes to meet end-users’ demanding needs. An update or a new release of a software application can consist of either of those changes or maybe both.

Software applications that do not meet time to market when releasing updates and new versions and take a long time to release updates or new versions become obsolete. They vanish into thin air without a trace. That’s why giants like Microsoft have reduced their major release cycle from 4 years to 3 years and also provide major Updates to the current release bi-annually so that the end-users are up-to-date and on track. Not only new releases and updates, but they also have to provide patches/ hotfixes for identified bugs/ vulnerabilities in order to stay competitive in the game.

The Problem

Though we understand the importance of providing new releases, updates, and patches/ hotfixes more frequently is very important, it has its own set of challenges. Software vendors have to invest a lot in the people and resources to create/ develop these updates. Not only software vendors, but even customers also have to spend a considerable amount of time and money including internal resources to roll-out an update.

I’m not going to talk about the challenges faced by software vendors for creating updates because it is part of their value proposition. The ability to provide frequent updates and patches/ hotfixes is one of the reasons why customers choose them.

I’m going to talk a bit about the challenges customers are facing when rolling out updates and patches and some of them are:

• Frequency of patches/ hotfixes and updates — depending on the type of software, the frequency of release of patches/ hotfixes and updates will vary. While consumer-facing applications such as Office can stay without updating, applications such as identity management solutions, integration solutions that are mission-critical cannot skip or postpone updates and patches. No matter what the frequency is, we have to keep them up-to-date to avoid any security risks and other vulnerabilities.
• The dependency of patches/ hotfixes and updates — some patches and updates are not cumulative — depend on others and it does not allow to skip over. When a critical patch or update is released and if we have not applied any of the previous patches, we have to apply all of them before coming to the critical patch/ update.
• Resolving conflicts when applying patches/ hotfixes and updates — unlike consumer-facing/ productivity applications like Office, mission-critical applications such as middleware solutions can be deployed in various topologies depending on the customer requirements. Some deployments can be very simple and straightforward while others are very complex and distributed in nature. Rolling out a patch or update to those complex deployments often requires resolving a lot of conflicts in the configurations.
• Managing existing customization — most of the enterprise-grade customers do not deploy software as it is since they don’t meet all their requirements out-of-the-box. As a result, they tend to do a lot of customizations to suit their unique use cases. When applying a patch or update on a highly customized deployment, we have to make sure that we don’t overwrite/ replace or break any existing customizations. Having an inventory of all the customizations will make this exercise a bit easy. However, it takes a considerable amount of time and effort when applying an update or a patch over customizations.
• Time consumption — in a nutshell, it takes a lot of time and effort for applying a patch or an update considering all the other challenges. We have to plan for longer production downtimes and it impacts the day-to-day business as well.

The above list is just the tip of the iceberg and not even close to the complete list of challenges we face when updating or patching mission-critical applications. Hence, having a proper upgrade/ patching methodology as part of any software application is a huge benefit.

Kubernetes pipeline — Source: WSO2

WSO2 Update — The Background

WSO2 is committed to improving its products continuously by providing bug fixes, security fixes, and product improvements. Our aim is to release 01 major versions and at least 03 minor versions every year. Every major release of a WSO2 product is followed by a series of updates. When WSO2 is aggressively releasing fixes and product improvements, as customers, it’s challenging for us to apply them without having a propper update mechanism.

Below is a quick refresher of the WSO2 Update Story:

WSO2 Update Manager (WUM) 1.0 — introduced in the year 2016.

WSO2 Update Manager (WUM) 2.0 — introduced in the year 2018. It allows you to download fixes, updates, and move them over to your environment. It’s a bit time consuming as we have to compare differences between the original product binaries and the updated binaries and manually copy them over to your environment. This becomes further complicated and time-consuming when we have multiple pre-production environments, as we have to perform the same process for each environment.

WSO2 Update Manager (WUM) 3.0 with In-place — introduced in the year 2018. This release of WUM came with the support for the in-place upgrade which allows us to update an environment directly without downloading the update separately, comparing the difference, and moving over files manually. This tool automatically checks the current update level of the product, compares it with the latest version, and identifies the no of updates we are behind. And we can use the same in-place tool to download those patches/ updates and apply them. It also helps us in resolving any conflicts identified during the update process. However, we still have the same set of inherent problems we had with WUM such as having to deal with large downloads, etc.

Over 4 years of experience with WUM, WSO2 introduced a revolutionary way of updating their products — WSO2 Update 2.0.

WSO2 Update 2.0

WSO2 Update 2.0 was introduced a few weeks back and in the process of rolling out to their customers. It has a new client-server architecture and the WSO2 Update 2.0 client tool connects with the server and delivers hotfixes, improvements, and features seamlessly through Hotfixes and Updates. Updates are proactive fixes created by WSO2 and Hotfixes are created for customer reported incidents/ bugs.

Webinar — Introducing WSO2 Update 2.0

Below are some of the key highlights of the WSO2 Update 2.0:

• The Update tool has the ability to update itself automatically
• Introduction of Update Levels instead of timestamps (wso2am-3.2.0.1)
• Download only the changeset required for the distribution, not the complete product binaries
• Very low bandwidth utilization
• Faster updates (1–2 mins to update a product)
• Ability to revert/ rollback to the previous state very easily by backing up the product distribution
• Ability to update the customized product distributions while merging the configurations and customized artifacts. Allows resolving merge conflicts.
• Support for the distributed deployments
• Support for Cloud deployments such as AWS
• Support for container-based deployments such as Docker and Kubernetes

Updates are proactive fixes created by WSO2 and Hotfixes are created for customer reported incidents/ bugs. Each hotfix will be carried forward to other customers through an update. Hotfixes are in the form of .zip files and they are valid only for a limited time period (x months). This encourages customers to move to the next update level when ready, rather than staying with just hotfixes. And a hotfix is valid only for a specific update level. Updates cannot be applied while hotfixes are applied and need to revert the hotfixes and then apply the update.

JIRAIDSUB-wso2am-3.1.0.5.full-hf-1.zip — is a hotfix created/ released for the customer JIRAIDSUB, for WSO2 API Manager 3.1.0.5 update level and it can be applied only on top of API Manager 3.1.0.5 update level.

Below are some useful commands related to using the new WSO2 Update 2.0 tool:

wso2update current-state — check the current update level of the product

wso2update check — check to see whether there are any updates or hotfixes available depending on the current update level

wso2update — downloads and applies the available updates. This command will first create a backup of the current product before applying any updates.

wso2update — continue — continue the update process after resolving any conflicts encountered during the last update

wso2update — revert — allows us to revert/ rollback to the previous state using the back taken during the update

wso2update apply-hotfix [hotfix file] — applies the hotfix supplied as the input

wso2update apply-hotfix — continue — continue the applying hotfix process after resolving any conflicts encountered during the last hotfix applying operation

wso2update revert-hotfix — allows us to revert/ rollback to the previous state using the backup taken during the hotfix applying operation

wso2update create-docker — allows us to create a docker image using the current state of the product

Finally, you may want to know where we can find this WSO2 Update 2.0 tool. You can find it in the [PRODUCT_HOME]/bin directory. You should see 03 different executables — wso2update_linux for Linux platform, wso2update_darwin for MacOc platform, and wso2update_windows for Windows platform. Depending on the platform, you can use the appropriate executable. In case if you don’t see these executables, it means you have to take the latest WUM and it will add those executables to your product binaries.

Conclusion

WSO2 is committed to providing improvements and enhancements to their products and as a result, they also have revolutionized the way updates are applied using a new tool — WSO2 Update 2.0.

WSO2 Update 2.0 improves upon the In-place and WUM update tolls to provide an enhanced experience for:

• Faster updates with low bandwidth usage
• Use of update levels instead of timestamps
• Adheres to proper standards and update protocols

Why wait? Give it a try.

For more information, please check the webinar — https://wso2.com/library/webinars/introducing-wso2-updates2.0-na/