zagandesign - Fotolia
VMware offers numerous products that make the update process smooth, but the improvements vSphere 6.7 Update 1 offers over the initial release show that IT administrators should delay vSphere updates to see what the next version offers.
Some software updates include significant new features, whereas others fix bugs, offer performance enhancements or add security improvements. Software updates are a normal part of IT administrators' workflows, but the less common major releases require a different perspective.
When a software package goes from 6.0 to 6.1, it's usually a minor change and doesn't necessitate a lot of effort from admins. Going from 6.0 to 6.5 is a different story, and that shift often includes more risk -- and reward. There's often so much change between versions that some admins wait for the first maintenance release of the newer version before they update.
VMware announced that vSphere 6.7 Update 1 would debut with an upgrade path from vSphere 6.5 Update 2. This left many admins wondering what happened to the upgrade from 6.5 to 6.7. It's present, but many admins passed on it in favor of waiting for other vSphere updates, such as the first maintenance release or Update 1 of 6.7.
VMware has done vSphere updates like this in the past, and it's not alone in this practice. For instance, admins who manage Microsoft servers often wait until the first service pack before they do the initial install for a major point release.
Many admins don't care about being on the bleeding edge of a software release; others wait and see because of previous troubles they incurred by updating too soon.
VMware vSphere updates require patience
When a vendor announces a major software release, it usually coordinates with the marketing department and organizations months before the actual publish date. This establishes a deadline for the software release, which can limit what goes into it.
After publically announcing a release date, it can be a public relations disaster to delay it. This can force the vendor to save some features for a future release or to include imperfect versions of those features. This doesn't mean that an update 1 is always a better release, but admins should think of it as a more refined version of the previous release. This pattern persisted with VMware's vSphere 6.7 Update 1.
For most software vendors, a standard major point release and an update release aren't usually critically different. However, with VMware and other virtualization products, these releases are more consequential. Unlike most software in a data center, virtualization products have become the core foundation of the entire data center. The effect of a bad patch or update reaches further than an OS update can.
Increased risk comes with increased attention and caution. VMware software is unique because admins can often use vMotion and other technologies to do updates without any outages. Though these products are helpful, they can also create a false sense of security when it comes to updating the hypervisor and its related components.
Despite the complexity of VMware software, its core infrastructure often remains under the radar when it comes to updates. Most managers and staff don't understand all of the pieces of a virtual infrastructure, so admins have some free reign for vSphere updates. A single bad update or issue, however, can invite scrutiny of the virtual infrastructure, the risks updates pose and the update policies currently in place.
One of the biggest factors for admins is that a fully functional client didn't show up until vSphere 6.7 Update 1. Beyond features, the cost of vSphere updates also applies.
Even though the VMware software update process is typically nondisruptive, it still takes time and effort to complete the update and ensure there are no disruptions. Most admins tend to have a full plate, and continually updating the infrastructure on top of everything else can be a drain on precious resources.
At some point in the future, vSphere version 7 will emerge and the same argument will repeat. Some will make the initial jump and others will step back and observe the issues with the new release first. This isn't because they don't want to use the newest features or that company policy is stopping them -- it's mostly due to the time it takes to apply vSphere updates. Why shouldn't admins wait for the polished version?