Should a computer be immortal? Like human immortality, it sounds all right until you look at the details. Physical computers certainly aren't immortal; anything with moving parts will wear and decay until it ceases to function. But virtual machines (VMs) are just files, so as long as the files are around, so is the VM. Without proper VM lifecycle management, organizations can end up with out-of-date, seemingly immortal VMs.
In the past, operating system (OS) upgrades were tied to hardware replacement. When the risk of hardware failure got too high, IT bought a new computer and installed a new OS. The new OS was necessary, because hardware vendors only release drivers for recent OSes when they release new hardware. New OSes often also meant new application versions, so applications were frequently updated or replaced.
VMs have disrupted this natural cycle. Now, the hypervisor is what's updated, but the VM continues to operate with no awareness that it is on new physical hardware. We are no longer upgrading our OSes and applications every few years as the physical hardware ages. As a result, the VM OS and applications are immortal. I recently came across a critical application running on Windows NT 4.0 -- a 17-year-old OS.
How did this machine remain in use? Surely somewhere along the way it crossed a threshold where it should have been replaced. But because there was no hardware replacement crisis, it just kept running. The VM continued to do its job as it always had, so there was no pressing reason to upgrade or replace it.
Why immortal VMs should be put to rest
However, consider how this affects support costs. In years past, most computers in an organization ran either the most recent version of an OS or the previous version. Now we have VMs running four or five different major releases. It is unlikely that you will find corporate antivirus, security, asset management or monitoring tools that span all these versions -- not to the mention staff with the skills to support multiple OSes. Many IT professionals were still in school 15 years ago when Windows NT 4.0 was the standard. How will they cope when called on to support these IT dinosaurs?
Clearly this isn't desirable or cost-effective, and immortal VMs may become the support nightmare that COBOL was when Y2K rolled around. Corporate IT departments may find that they need the services of the gray-bearded old-timer who remembers when these old systems were new.
So how will corporate IT avoid the nightmare of immortal VMs? I see two possible strategies for VM lifecycle management:
- Strong governance to prevent immortality. If the IT department can enforce a VM lifecycle management policy of only allowing a set number of OS versions in the data center, then as new OS versions are released, the older VMs will need to be upgraded. The hard part is that the business unit using the application must usually pay for the upgrade and possibly will have to find a new application the new OS supports. This business unit must pay the cost, but often gains nothing from the upgrade. This will cause resentment of IT. Support cost for central IT will be minimized, but the cost to the business may be high.
- Embrace immortality. Step off the upgrade hamster wheel and embrace older OSes and applications. Build a culture of education where younger IT staff members are trained on older systems by those who put them in. Older tools still do what they always did. If that is still what the business needs, then why upgrade? Focus the resources and spending on upgrades in the areas where the business requirements are not being met. Spend less time and money on upgrading and patching and more on adding business value.
Virtualization has disrupted many areas of IT. The OS upgrade cycle is one of many where IT must now make conscious decisions that never existed before virtualization. A clear VM lifecycle management strategy with real IT commitment will prevent a support problem with immortal VMs.
Dig deeper on Virtual machine provisioning and configuration
Alastair Cooke asks:
How do you approach VM lifecycle management?
0 ResponsesJoin the Discussion