vSphere 8 has a new release model to quantify adoption
As you probably know by now, vSphere 8 was announced during VMware Explore US 2022 and brought a plethora of new features and improvements. You can find out more about them in our blogs part 1 and part 2
As far back as I can remember, new versions have always been looked down on and avoided. Microsoft Windows XP was no good until Service Pack 1, then 2 and 3. Administrators of virtual environments have all avoided GA versions as it would be crippled with bugs of any sorts. I even used to have a boss who would avoid any major vSphere version in x.0, so we went from vSphere 5.5 Update 3 to vSphere 6.5 Update 1 (because GA is no good).
The release cycles over at VMware have been a topic of discussion in the last few years when vSphere 7.0 was subjected to cadence of 1 major release every six months. While it brought new features quicker, many suspected that less effort was put into testing and ensuring platform stability after VMware had to deprecate buggy versions that would cause production issues. The bigger one was the release of vSphere 7.0 Update 3 that brought purple screens of deaths to many users in specific circumstances.
Release designations
If you aren’t familiar with usual release naming conventions, now is a good time to have a look at them. Note that this is a common release cycle and doesn’t represent VMware’s.
Alpha
Alpha versions are early builds in the first phase of software development. In this phase, builds are usually a bit rough and can include performance or stability issues as they are in active development and not thoroughly tested. Not all features will be in the Alpha release and some software refer to it as nightly builds to make you aware that you may encounter unexpected behavior so you run it at your own risk.
FC (Feature Complete)
It can be argued that FC isn’t really a phase of the software cycle but rather a milestone. Reaching FC means all the features that should be available in the product have been implemented. However, FC releases aren’t stable and require going through testing before making production.
Beta
The Beta testing phase follows Alpha. The purpose of this phase is to report and fix bugs in the product. No guarantee is given with regards to stability, performance or risk attached to running the build. Most software companies run open or closed beta testing phases to let power users put the product to the test and gather as much feedback as possible.
RC (Release Candidate)
Release Candidate versions of product are, as the name implies, candidates to be released in stable state. Having gone through Beta testing, RCs are usually a lot closer to what you get in production but may still include small bugs that don’t hinder useability or edge cases that haven’t been tested yet, meaning they represent an insignificant minority of cases. The RC phase focuses on product stability and no new feature/code will make its way into this release. It is usually fairly safe to run RC builds, although it is not recommended for production workloads obviously.
RTM (Release to Manufacturing)
This stage means the product reached a quality level that matches expectations for distribution. This is what you’ll get when you download it on the vendor’s website but it hasn’t been distributed to the general public yet. At this point the new version is released to marketing departments who can finally work on their shiny diagrams, blogs and videos about it.
GA (General Availability)
General availability is when the product is available for download and safe to run in production (although I am yet to meet someone who will do that).
Upgrades and Patches
After the GA release of a product, vSphere included, the life cycle includes Upgrades to bring new features and improvements and patches on a more aggressive rate to distribute fixes and address security vulnerabilities.
Why is there a new vSphere release cycle
Part of the reason behind this decision is to restore users’ confidence in production releases. Last year’s failures caused by speedy vSphere 7.0 releases raised a lot of doubt among the community and caused many admins to consider whether they should upgrade or not in order to not put their SLA in jeopardy. This is a problem because product readiness shouldn’t even be a factor when deciding when to upgrade as there are already many things to consider.
This new release cycle also aims at matching vSphere 8 with Cloud Services releases that are part of vSphere+.
New release cycle in vSphere 8 (IA/GA model)
As you know, installing a new version is scary and you don’t want to be the one encountering day-0 bugs in your production environment. Customers don’t want to be guinea pigs and want to wait until it has enough traction to reach a point where you can say the product is stable because enough users are running it without significant issues. It can be a chicken-and-egg problem as, if no one wants to install a release to wait for product stability, the only feedback VMware is going to get is from users like us running small labs that are not representative of production scenarios.
In order to distribute more stable versions of vSphere and appease these concerns, VMware will now first release vSphere under an IA designation (Initial Availability) that meets all quality gates of GA. It is available for a period of up to 2 months during which customers can deploy it in production or production-like environments.
When VMware establishes that the release has gained wide adoption, it will graduate to GA.
Wrap up
With this new vSphere 8 release cycle, VMware is adding a layer of product qualification by quantifying customer adoption of a release to bring peace of mind to early adopters. The hope behind this move is to encourage customers to install GA versions and stop the common habit of skipping it and waiting for update releases. Let’s see if this works out and what the numbers will be for vSphere 8 GA.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
