Experienced administrators at companies that decide to move some workload from on-premises to the cloud are confronted by many challenges. I’ve covered some of those in recent posts, such as the lack of advanced training and figuring out how to cope with service outages.
Understanding how Microsoft releases software into Office 365 also causes brows to crease. It’s not just a question of losing control about when updates are applied, a factor that tends to be commented upon from time to time. By now, everyone accepts that when you sign up for a cloud service, the software running in the service will be updated and you have to accept that this is the modus operandi. Rather, the issue seems to be understanding the words Microsoft uses to describe software availability. Let’s try and put this into words that the on-premises community understand.
Ever since Microsoft started along the journey to produce enterprise software with Windows NT, they have operated beta programs to have some customers test new software before final release. Some product groups are better at running these programs than others. The Exchange team, for instance, has long had a well-organized Technology Adoption Program (TAP) designed to have hundreds of thousands of on-premises mailboxes run new versions of Exchange in production before the software is released.
Over those years we have become accustomed to see major new versions of products released every three years or so. The exact date when a product like Exchange, SharePoint, or SQL is “released to manufacturing” (RTM) is not strictly determined by the maturity or stability of the software. Certain quality goals have to be reached, but often the release date is set for marketing purposes, such as the collective announcement of a “wave” of Office servers.
Of course, RTM is an archaic concept today. Where “gold” copies of software were once taken to manufacturing facilities to be turned into copies on floppy disks (installing products like Word for Windows from multiple floppies was such a joy), CDs, or DVDs, current releases are more likely downloaded from a Microsoft web server. Even so, RTM remains an important event in the product lifecycle that customers build plans around.
A year or so after a product reaches RTM, Microsoft usually releases the first service pack (SP1). Collective wisdom says that SP1 is the time when the software is safe to deploy into production. Early bugs have been fixed, People have been trained. Third party vendors have updated their software. Everyone has a warm feeling of comfort. And life is good.
The classic beta-RTM-SP1 cycle doesn’t exist in the cloud. Compared to the often slow progress made in deploying new software into on-premises environment, the cloud operates at frenetic speed. User interfaces change, new applications appear, features disappear or morph, and generally you have to keep your eyes open all the time to track what’s going on. Or at least, to try to.
The Office 365 cycle begins with preview, when select tenants are exposed to new software. This is like the on-premises beta phase because it has the same intention: locate bugs and make sure that functionality is stable. Some software (like Delve) stays in preview for months while some seems to hurry through in a matter of weeks.
The next step is First Release, which means that a tenant signs up some or all of its users to be exposed to software earlier than the norm. First Release allows Microsoft to expose software to more users while allowing tenants to access new functionality some weeks before it becomes generally available. Many changes can be made to an application like the task management Office 365 Planner before it is released to all.
A further complication is the way that Microsoft publishes announcements about new functionality around the time that code enters First Release. The way the text reads, you’d assume that a new feature will appear imminently. The truth of the matter is that you might have to wait for months before the software is usable. No amount of pretty screenshots can disguise this fact. The recent announcement of the new Office 365 Admin Center is a case in point. Anyone who has attempted to use the new interface will tell you that it’s slow, breaks, and is missing functionality. But it’s been announced and that’s nice.
Eventually, the folks responsible for features consider code to be ready and the software joins the Standard Release of Office 365, at which time it is “Generally Available”. In on-premises terms, you could consider First Release to be equivalent to RTM and Standard Release to be SP1 because the tenants who enable First Release do the job of testing software to make sure it’s safe and works well before the vast majority take the plunge.
Which brings me to “flighting”, the term used to describe the deployment of software updates within Office 365. Different teams “flight” software at different times and to different tenants. It’s a side effect of operating a massive multi-tenant environment that is organized on a regional basis. The net effect is that your tenant might use different software than that used by another tenant in another Office 365 region, even if you both seemingly have the same version.
Although an analogy can be created between the on-premises beta-RTM-SP1 routine and the cloud’s cycle of Preview-First Release-General Availability, you can’t compare the way that software is rushed into Office 365 when it seems to be incomplete with the measured pace of on-premises releases. Office 365 Groups are a great example. A fantastic concept with great functionality was spoilt in the early days because it was released with lots of holes. Some, like support in Outlook 2016, have been filled since while others, like a soft-delete capability, remain missing. It seems that quality has lost out to urgency in the cloud. Today, it's all about staying one step ahead of the competition.
Understanding release cycles and the different terminology used in Office 365 is probably not one of the most pressing concerns of administrators facing the need to migrate workload from on-premises. However, like many things in life, mastering detail is a good way of ensuring that you’re less likely to be blindsided. Knowing what words mean and when software will turn up falls into that category.
Follow Tony @12Knocksinna
