My June 7 post exploring the thought that Exchange 2010 SP2 RU3 was a roll-up update (RU) with some of the characteristics of a full-blown service pack (because it includes some interesting functionality enhancements in addition to the normal collection of bug fixes) provoked some further thinking about the influence that cloud-based systems have on their on-premises counterparts.
One response I received from a member of the Exchange development team pointed me to the post by Rajesh Jha (corporate Vice President for Exchange) on the EHLO blog that describes Microsoft’s development cadence for Exchange Online, the version that runs as part of . I already reviewed that post last October and concluded that companies that switch to a cloud platform have to revise their expectation about the rate of change of software and factor this into their deployment plans.
Then I read an article that examined how Microsoft can keep Windows 8 “fresh” after it is released by Hal Berenson, who was a Distinguished Engineer and General Manager at Microsoft before he retired. Not only was the article interesting because of the insight it provided into the evolution of the desktop version of Windows over the years, it provoked further thought about the increasing pace of software development and concluded that, with , Microsoft has to balance the need to refresh its O/S to keep it competitive while also providing a stable platform that can be easily deployed and supported within large corporations. Berenson said that he thinks that Microsoft should release service pack updates for Windows every six months as “frequent small updates are too disruptive”.
Moving back to Exchange, here are some data points to summarize the current situation:
- Exchange 2010 and Exchange 2007 have operated on the basis of an annual (or thereabouts) service pack with cumulative roll-up updates being released every six weeks or so. Service packs have been the vehicle to introduce new functionality like the revamped Outlook Web App released in Exchange 2010 SP1.
- Exchange Online updates functionality every 90 days with major refreshes every 12-24 months. Bug fixes are deployed every two weeks. The next major refresh for Exchange Online will be when Microsoft deploys into the datacenter. Tenant administrators will have some control over when Exchange 2013 is available to their users but this control only applies for a limited period and eventually they will have to transition.
- Microsoft expects an increasing number of its current installed base to move to Exchange Online over the next few years. The exact proportion of the base that will end up using a cloud or hybrid-based system is debatable but could be as high as 50% of the total mailbox count. Your guess is as good as mine. What’s not debatable is that cloud services are a huge influence on Microsoft development – Kevin Allison, GM of Exchange, reported that a majority of Exchange development engineers are working on Exchange Online features rather than those specifically for the on-premises version. Of course, work done for Exchange Online can and often does benefit the on-premises version.
- Microsoft faces continued and sustained competition from Google and Amazon for its Office 365 and Azure platforms. Although Microsoft appears to have the upper hand in terms of functionality, Google continues to roll out new features in Gmail and Google Docs, creating an imperative to enhance Office 365 on a continual basis.
With the greatest of respect to SharePoint Online and Lync Online, there’s little doubt that email is the easiest application to move to a cloud platform and is the fastest to achieve a return on investment after the move. As such, there’s lots of pressure to keep Exchange Online moving forward. And although there’s lots of work for the developers to do to improve aspects such as automation and manageability for Office 365, they also work on new features and the result of the work trickles through to the on-premises server, which might be contributing to the sort of creeping change seen in Exchange 2010 SP2 RU3.
The prospects of having to understand, test, and deploy an evolving server every six weeks or so are unattractive to many administrators. Taking the arguments advanced by Berenson, software stability is important to administrators as it facilitates better planning and (usually) a better operational experience. With this in mind, deploying every RU soon after Microsoft releases the update might not be the best approach. I think it’s important to review the list of fixes contained in each RU to check whether any of the fixes is important to your deployment and install the RU if such a fix is found. But apart from that, a pragmatist might decide to install every third RU on the basis that eighteen to twenty weeks is a reasonable period to run a particular software version that also gives sufficient time for the planning and deployment process to be managed efficiently with the framework of normal software release cycles. RUs are cumulative so installing the latest update means that a server is brought completely up to date.
Microsoft used to be criticized because they didn’t fix software quickly enough. The interesting thing about the current situation is that Microsoft could be construed to be pushing out updates so fast that it’s difficult for some customers to deal with them. I guess it’s the pace of the new, improved, cloud-centric world that we have to figure out how best to harness. It’s a strange old world at times.
Follow Tony @12Knocksinna