With the success of the App Store as a market to distribute applications, people have gotten used to their apps getting updated regularly. In fact, many people simply accept their updates automatically, and trust the provider to not mess up. And then they forget about it altogether. After all, you want to use an app, not manage it, right? Given the scale of apps and the number of smartphones, it’s remarkable that this model works pretty much flawlessly. And the same model works for your phone operating system, especially when you’re on iOS (update practices of Android phone manufacturers differ). Apple proudly reported that iOS 12 adoption rate hit 50% of eligible devices within a mere three weeks of launch. Hundreds of millions of devices got updated within mere weeks. Without any serious issue. Google Chrome is another great example. Most people have no clue what version they are using currently. Google has even decided to not separate minor and major updates. There’s just one version. Every update is treated in the way a minor update was previously. It gets published, and rolled out without much fanfare. Again, no serious issue.
There’s a lot of benefits to be had in regular updates. It keeps you up to date with the latest features, it improves security, and there are new things to discover. It keeps you in shape and healthy. And from a provider perspective, as customers move from older product releases, overall entropy goes down – or at least doesn’t go up all the time. It is also a chance to engage with your customers. So everybody wins.
Consumer to business
With enterprise software, however, regular updates are not that common. It’s the kind of maintenance that is regarded important, but seldom urgent enough to actually spend time and resources on. That’s a pity, because what could be more valuable than keeping your enterprise in shape and healthy? I know, there are those past experiences with updates gone horribly wrong. Those never ending, costly migration projects to get every employee to Windows 7 – with all their custom hardware and software. And yes, it is important to take lessons from the past. But no, maintaining a steady state is not the answer. The world around us is in constant flux, technology is evolving, and so are the threats. Consequently, you have to keep up to date, or else, risk being obliterated. As the principle has it, keep responding to change, or risk oblivion.
A sensible update strategy
Your update strategy starts with ownership. If your ownership is not clearly defined, nobody will plan or budget for regular updates. If you own a building, or a car, you plan for regular maintenance. So why would you treat your valuable software worse? In the Netherlands, caring for our dykes is so engrained in our culture, that planning for maintenance has become a no-brainer. I think you should do likewise.
If you have an update policy, you probably discriminate urgent fixes from regular updates. You have a process for unplanned patches and a process for upgrades. Urgent fixes are deployed when something is broken, or a major security vulnerability has come to light. WSO2 uses its update manager, WUM, to distribute fixes and patches. They recommend to run it weekly, and deploy it in your dev environment. Whenever you’re ready to up a stage, it will be automatically included. This makes sense as long as the integration platform itself is still being developed. However, once you’re in production, should there be an urgent security patch to apply, you probably wouldn’t want to wait for some future point in time when the new version is released. So you need an emergency process to test and deploy urgent patches.
It makes sense to think about testing, Test automation is good, but it only brings you so far. With cloud-native technologies, more advanced scenario’s, such as blue-green deployments, can be used to manage the risk of updates. And the better you can manage your risks, the easier an upgrade becomes.
WSO2 has a quarterly release scheme for their main products. With the launch of new versions, new functionality is made available. We recommend to adopt a quarterly update process too. This does not necessarily mean that every update should be implemented – the outcome of your evaluation might very well be to skip an upgrade for good reasons. It does mean, however, that every upgrade should be considered.
It also does not mean to say that you should adopt the latest and greatest release as quickly as possible. If you’re a smart follower, lagging six months behind to wait for the majority of bugs to be ironed out, might very well be a strategy that works for you just remember to keep pace from there.
When evaluating a new release, there are two dimensions to weigh – costs and benefits. If you consider the costs of upgrading and the benefits of upgrading against the cost and benefits of not upgrading, you can make a balanced decision. However, do not underestimate the hidden risks (and related costs) of your technological debt. After all, the more versions you skip, the richer in scope your future update will become. Which may very well present its own set of challenges. Also consider that deployment automation is a great way to minimize the cost and risk of deployment. Hence, with automation, benefits will outweigh the risks more frequently, so you can reap the benefits earlier.
With practice comes perfection. This is also true for your update process. With today’s technology and experience it is feasible to tackle major risks to an extent that serious issues are very, very scarce. We’ve entered the era of utility computing, and that is the level of quality your users are expecting. No problem, as long as you have a sensible update strategy in place.
As always, you can approach us if you want to discuss your particular deployment process. We can probably help you from our experience as WSO2 Value-Added Reseller and WSO2 Premier Certified Partner. In case you want to share your experience with the community, please do so in the box below.