Ross Smith from Microsoft recently published a blog entry outlining Microsoft’s preferred architecture for Exchange (I’ll call it the MS PA). It’s certainly worth a read, as it covers the design criteria for Exchange that they’ve been working toward since well before the Exchange 2007 release.
I wouldn’t be the first to congratulate Ross and the rest of the Exchange team on their achievements, but I’ll do it anyway – their journey has been impressive, and they’ve kept true to the vision they set out nearly a decade ago. They have been absolutely relentless in driving out infrastructure cost from Exchange, and alongside the SharePoint and Office teams, have delivered a competitive and feature rich (if relatively closed) SaaS offering. Consider my cap doffed.
As you might expect, though, I respectfully disagree with some of Ross’ conclusions in the blog post. I don’t think Ross is being disingenuous in his assertions. Rather, I believe our disagreements are the result of our different perspectives.
A messaging architect’s mission is to facilitate the architecture supporting email services with a reasonable SLA at a low cost.
An enterprise architect’s mission is to facilitate the architecture supporting all business applications in the enterprise with an SLA that meets the applications’ respective business criticality at a low cost.
For the messaging architect, the MS PA may make some sense (although a lot of folks would take issue with claims around the value of virtualization and the need for backups). But at least at a philosophical level, eliminating anything not in the core application increases simplicity, reduces cost and increases availability.
For the enterprise architect, providing a common set of technologies that can be leveraged by as many applications as possible reduces duplication of effort, streamlines operations, reduces complexity, and increases availability. These technologies and techniques include management/automation, backup and recovery, and business continuity, just to name a few.
For the enterprise architect, the following points generally hold true:
- Standardization and normalization of operations drives higher availability and agility, while driving out operational expense. An enterprise architect will adhere to her infrastructure strategy wherever possible because tactical deviation will increase unplanned work, while squandering existing and planned investments. And while Exchange is an interesting workload, it certainly plays nicely with nearly all common infrastructure strategies.
- Virtualization is the norm. According to IDC, four times as many virtual Windows Server instances than physical will be deployed in 2014. As you can imagine, this gap will continue to grow. Applications requiring physical infrastructure are an aberration. As a result, customers have modified their operations to default to management and automation of virtual infrastructure, and therefore physical infrastructure is the more complex, expensive option.
- Ross and I agree that more management control points create complexity and add to cost. But even if an enterprise architect can eliminate the infrastructure management layer for Exchange, he’s still going to require those components for other applications. In a data center where each application has its own infrastructure, M&A, business continuity, and backup strategy, overall management and problem identification/resolution are going to be outrageously complex, expensive, and time consuming.
- If an enterprise architect is deploying and removing mailbox servers on a daily basis in the support of millions of mailboxes, it makes sense to automate around the application. But an organization of 100,000 mailboxes with a site resilient setup might have just 16 mailbox servers. That’s a fair number, and it’s surely worth automating. But it would make little sense for an enterprise to build a customized management and automation strategy from the ground up just for Exchange.
- The MS PA requires impressive scale in order to be cost efficient. A “typical” (~$25k) server nowadays will have 24-32 cores and between 768GB to 1TB of RAM. Let’s say that two of those servers can support 15,000 mailboxes in a fault tolerant configuration. However, in a physical environment, you’ll have to use more, smaller servers. While this will cost only slightly more in capital expense, operational expense explodes – rack space, cabling, power/cooling, inventory management, and simple hardware maintenance to name a few. Virtualization indubitably fixes this. Of course can also expect this gap to increase in the future – in a few years, that pair of $25k servers will support 100,000 mailboxes, and it’s going to be even more difficult to make efficient use of compute infrastructure without a hypervisor.
- Bypassing the HA options inherent in virtualized storage and server infrastructure wastes the competencies and efficiencies in which most enterprises have invested. These competencies cannot be eliminated because of the advantages they provide to other applications in the data center. This shifts (and increases) operational expense from the operations team, which is optimized for infrastructure deployment and maintenance to the application maintenance team, which is not.
These are just a handful of perspectives and challenges that face today’s enterprise architect that differ from that of a messaging architect. Does it really make sense to duplicate Office 365’s architecture in an general purpose data center environment?
So, what is EMC’s preferred architecture?
It’s easier to ask questions than it is to provide answers, and in that I applaud Ross and team’s clarity in their recommendation. My preferred architecture is the one in which the customer has the broadest competency. If you virtualize your infrastructure with VMware with VNX, then Exchange on VMware with VNX makes the most sense for you. If you’re finding success with vBlock, VSPEX, Hyper-V, and/or VMAX, then those are your preferred architectures.
Put shortly, deploy Exchange in a manner that will be least disruptive to your operations and management strategy. This will put you in the best position to cost effectively support the application.