Fairly often in my work, I come across and environment that can only be called “crusty”. Whether it’s a load balancer, server, or operating system, it’s not an environment that has been kept up to date. The product or software or OS may be years behind the current version, even EOL’d, and pretty much abandoned by the manufacturer.
This is very bad.
Computer gear doesn’t age well, and the pace of aging seems only to accelerate. As hardware ages, the vendor stops stocking replacements. As software ages, the user group declines as more people move to more recent versions. Bugs and security holes get less attention, or even no attention.  For operating systems, vendors will stop developing for that version (official support and binary compatibility too). Because of this, it’s important to constantly review any infrastructure and make proactive updates.
The engineering maxim that “if it ain’t broke, don’t fix it” isn’t really applicable to modern data centers. Leaving well enough alone for too long can have very detrimental effects on any operating environment.
The older something gets, the more “fragile” it becomes. The more people are afraid to make any changes, to update or even touch. This obviously hinders any organizations flexibility in dealing with potential issues. It severely restricts options. You may not be able to load an old operating system on new hardware, or install new fangeled databases. Older hardware may not be able to interface with new types of connections, or upgrade hardware components that are no longer made.
This affects commercial and open source software and proprietary software alike. Companies go out of business, and open source projects die off.
So what’s needed to avoid these issues? A different way of looking at deployment.
First, adopt the mindset of constant renewal. Apple used this to great effect when it established the top-secret project of maintaining parallel builds of Mac OS X on both PowerPC and x86 platforms. Every time they added a featureto the PowerPC build, they did a build on the x86 platform. This wasn’t too difficult to initiate, as NeXTSTEP, the operating system that Mac OS X was based on, already ran on a number of platforms, including x86 (in fact, it had to be ported to PowerPC). With this little bit of effort, they saved months, even years off of moving from PowerPC to x86, making them much more nimble. Imagine the pain in the ass it would have been to do an x86 build from scratch.
Have an exit strategy for every shiny new piece of hardware or software you put in.  Know that it’s not going to last forever, and get an idea of when you’re going to need to update/upgrade/replace. For instance, you install Solaris 10 on a server. Realize, you can’t run a server on Solaris 10 for 10 years. It will be problematic to run it on Solaris 10 for 5 years even. Plan to update Solaris 10 to the next version in two years. It doesn’t have to be right after the new Solaris version is released, but it should be sometime relatively soon.
Planning ahead for these types of changes makes them far easier than scrambling to update a fragile environment. A stitch in time can save many times nine, in this case.
