A recent article by Rui Silvia describing how to install an Exchange 2013 test environment on Windows Azure started me thinking about how far we have travelled in terms of virtualized systems in a reasonably short period.
For those who cannot remember, Exchange 2007 was the first version that Microsoft would support if servers were deployed on a virtualized platform. Sure, VMware had led the charge with virtualized Exchange 2003 but the big deployment blocker was the lack of support from Microsoft. You could use virtualized servers as long as you never needed support. Other technical issues also got in the way, such as the voracious appetite for disk I/O that Exchange 2003 had, but deployment and operation was possible.
While Microsoft supported Exchange 2003 SP2 when deployed on their Virtual Server 2005 R2 product, virtualization accelerated once Microsoft really got into the hypervisor race with Hyper-V. After all, having a brand-new hypervisor that does not support major application servers was inconceivable. In those days, substantial hardware was necessary to support virtual Exchange. Often, it was something like a set of blade servers in a rack, complete with large amounts of disk, a configuration that HP used successfully to run Exchange 2007 training courses.
Exchange 2010 is a much better virtual server and Exchange 2013 better still. The continuing focus that the development group has had on driving down the I/O profile of the server and accommodation for low-end disk configurations has risen to meet improvements in hypervisors to a point where it is possible for even a relatively inexpensive laptop (albeit one equipped with fast disks and lots of memory) to support several Exchange 2013 servers, even those in a Database Availability Group (DAG). Such a configuration is commonly used to validate new builds and test software. As everything is self-contained on a laptop, it’s easy to bring a complete Exchange organization on the road and use it for demonstrations or training purposes.
Now we see the first glimmer of virtualized Exchange in the cloud. It is still early days because some parts of Exchange might not be well suited to a deployment on a platform like Azure. As Silva points out, he was not able to configure Exchange mailbox servers into a DAG because of a problem with Windows Failover Clustering.
Unsurprisingly, Microsoft does not support the use of Azure as a platform for production Exchange servers, so its use is restricted to test systems. The major advantage of Azure (or any other cloud system) is that it is available if you can get onto the Internet. Being able to access your Exchange text environment from anywhere at reasonable cost seems like a pretty good deal to me.
I think Microsoft’s stance on using Azure for production servers is eminently reasonable because no real experience yet exists of how well Exchange functions on a cloud-based virtualized platform. We are at the point where people are trying things out and getting test configurations to work, while also discovering parts that do not work so well. It reminds me a lot of the situation that existed in 2004-2005 when people were experimenting with virtualized Exchange 2003 servers on VMware. We have seen how that story developed and it would not surprise me if platforms like Azure mature quickly to support the production-quality operation of sophisticated application servers such as Exchange and SharePoint.
If and when that happens, we will have the choice of deploying Exchange on traditional on-premises (physical or virtualized) servers, in a hybrid configuration with Office 365, in a pure cloud environment using Office 365 or another hosted platform, or on virtualized servers on a cloud platform. Sorting out the choices and deciding just what solution deliver the right combination of reliability, robustness, and service quality might then be pretty complex. Something for us all to look forward to!
Follow Tony @12Knocksinna
