Every major software release has a lifecycle – the end point of which being when the developer no longer can support bugs or changes to the code because of age. Twenty years ago, a new operating system was often deployed a year or two after the consumer version was released, in many cases after the first service pack had been released. This meant that “end of life” was often timed to many years post-release, in some cases a decade. (Windows XP, for instance, was supported for 12 years post release!) After end of life was reached, the developer would no longer issue security updates or patches, which meant that these dates were critical for folks to know. These lengthy support times caused three downstream effects among businesses:
- Many businesses faced with a hardware or software requirement to upgrade simply postponed, forcing staff and partners to use older software and creating large security vulnerabilities over time; new functionality was positioned as “risky”, even if the functionality was security related.
- Because deployment of a new operating system (or even a new application) required major changes to user experience, staggering releases over 3-5 years was positioned as both fiscally prudent and easier to plan change management around.
- Every customer has a different mix of applications – when combined with a “choose which patches to apply” model on the security and features front, and even a single organization might have thousands of different types of code deployed on machines. This meant that when problems occurred, it was nearly impossible to replicate the exact mix of OS and application information to get to the root cause, even with accurate telemetry. The longer software was deployed, the worse this problem became.
With the advent of the cloud, the ability to update software and collect telemetry, including the operating system itself, became quite trivial. This caused major software developers, including Microsoft, to start to shift the landscape of support – instead of attempting to support an OS for 3-5 years, developers moved the support window to 1-2 years. This wasn’t a change made in a vacuum: the ability to generate smaller releases containing code that had already been proven to work, tied to real-time telemetry, is part of the broader landscape shift from waterfall-based development to more agile “dev/ops” aligned approaches. For a software developer, all of these changes are broadly positive: less financial risk, greater customer engagement and the ability to make changes quickly before products are marketed. For consumers and businesses, there are key benefits as well: security is now baked into software rather than being bolted on, features that enter the consumer space can be brought into the business more quickly, and because changes are smaller, change management can be more easily adopted.
Despite all these benefits, these are still changes, and with any chance, businesses will take different amount of times to adopt. What has become clear over the past three years is that many organizations haven’t fully grasped the support implications that accompany a faster pace of versions and improved security.
