Real support periods versus nominal official ones

January 15, 2014

Suppose that you have a vendor with a support period of five years for their OS. This is great, since you can install a machine with that OS and get five years of support for it, right? Well, no, of course not. You only get five years of support if you install your machine right away when the OS comes out. If you install a machine two years after that, you only get three years of support for it; if you install a machine four years after the initial release, you get one year of support.

(We're assuming that the vendor doesn't extend the support period at some point due to popular demand.)

In a heterogenous environment where you're deciding on a project by project basis what software to use, you just have to consider support requirements when you're planning each project; each one can wind up using something different that fits its needs. Generally this is going to make any particular OS or software version less and less attractive for new projects as it gets closer and closer to its EOL, because more and more projects will have support requirements that run beyond the EOL.

(On the other hand you may see surprising usage even quite late, as new projects with short support requirements pick the old version for various other reasons, eg the people involved have a lot of familiarity with its quirks.)

If you want to run a mostly homogenous environment making a big use of this software, another important factor comes in: you now care a lot about how often the vendor releases new versions with new support periods. We can see this by taking the extreme case. Suppose that this OS vendor does releases only once every six years, leaving a one year period where you can't install or run a machine with support. You're unlikely to use this OS because you'd have to abandon it during that one year gap.

In a homogenous environment where you're strongly tied to a given bit of software on basically all of your machines, the worst case minimum support period you may actually get works out to be around the official support period minus how often the vendor does releases. If the vendor releases new versions every four years, the vague worst case is that you have to set up a new machine just before their new version comes out and so it gets about a year's support. The practical result is often that if the vendor only has what you consider a short overlap, you'll start dragging your heels on new machines as the time for a new version gets closer and closer; you really want to delay long enough to use the new version for its much longer support period.

(In practice you're unlikely to immediately start using the vendor's new version the day it gets released, so if you're unlucky you may have to install with the old version even for a while after the new one is released.)

This leaves sysadmins and other people really wanting a good healthy overlap of support periods after new versions are released. For a not entirely hypothetical example, five years of support coupled with a new version every two years gives us about three years of overlap for the worst case. That's a pretty respectable number that leaves me with little qualms about installing the 'old' version pretty much any time up to the point where we have the new version ready for production.

(There is also the related issue that real world support periods are shorter than they look.)

Written on 15 January 2014.
« The problem with OmniOS's 'build your own' view for Perl and Python
SELinux fails again (Fedora 20 edition) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 15 01:18:28 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.