Well over a year ago, I wrote about the first reports of running Exchange 2013 on Azure and noted that this might represent a future deployment option. In a world where Exchange fully supported Azure and Azure fully supported Exchange (for the two must go hand in hand), you would have the choice of a classic on-premises deployment, hybrid connectivity with Office 365, a pure cloud deployment with Office 365 or another hosting provider, or moving servers onto a cloud application platform such as Azure.
Conceivably, you’d have a choice of cloud providers too as Microsoft might support Amazon (or even Google), in much the same way as support for the VMware hypervisor became so much easier after Microsoft released Hyper-V. Amazon supports Exchange 2013 on EC2 today as long as you’re willing to have Amazon provide support because Microsoft absolutely won’t.
Supportability is therefore key in any platform discussion. Just because some gifted technologists make Exchange sing and dance using certain hardware is no guarantee that such a configuration can be supported, especially when it’s used by people who might not have quite the same level of expertise as the folks who “proved” that a solution works. NFS support for Exchange is one obvious example. NFS vendors proclaim that they can make their technology work just fine with Exchange but Microsoft is unwilling to endorse NFS storage because they know what can happen if things go wrong in the hands of the unwary. A corrupted database is not a thing of beauty.
People who know the ins and outs of any platform can accomplish things that others cannot. Azure experts have shown that they can make Exchange 2013 work well on Azure but, apart from some tentative indications that it might be possible to host the witness server for a Database Availability Group on Azure, the Exchange development group hasn’t moved much in this area recently.
Part of this might be due to an understandable focus on Exchange Online and Office 365. As we learned at the recent Microsoft Exchange Conference, there’s a ton of new features and functionality coming to Exchange Online soon. Some of those features, like the Office Graph, are likely to require a fair amount of heavy-duty integration behind the scenes. Of course, the beauty of the cloud is that you let the cloud provider do this kind of work and then benefit from it.
Being asked to divert resources to make Exchange supportable on Azure doesn’t seem like it would be commercially attractive for Microsoft either. After all, three deployment options are already available to customers, and, as pointed out above, supporting Exchange on Azure might create a crack in the wall that could be exploited by Amazon.
It’s also true that the economics of running an application like Exchange on a cloud platform that charges through resource consumption is unproven for customers. Office 365 has been successful because it is able to charge a simple monthly fee per mailbox that varies according to available features. But Azure charges for resources like CPU, network, and disk consumption plus the virtual machines that you want to use. It’s interesting to have a look at the Azure online pricing calculator to try and figure out how much some production Exchange servers might cost, remembering that Exchange 2013 is a resource hog and you’re not going to want to run it on some small servers. I imagine that the CPU, RAM, disk, and bandwidth bills for an Azure deployment of Exchange 2013 might be “interesting.”
And then there’s the utterly salient point that deploying on Azure still means that you have to do a lot of work to deploy Exchange 2013. Again, one of the attractive things about Exchange Online is that Microsoft gets to do all the server management and enjoyable tasks such as applying regular cumulative updates, patches, and so on. You have to do the same work on Azure because Microsoft won’t do it for you.
The more I think about it, the less attractive Azure seems to be for Exchange. It might be a good place to run a few test servers and Microsoft might adjust the economic argument in the future by creating an Exchange package for Azure, but that’s not the case right now. Even though TechEd North America 2014 was full of Azure announcements and good news, I think we can leave Exchange aside for the moment.
Follow Tony @12Knocksinna
