Summit 7 Team Blogs

You Must Be This Tall to Ride

Recently, there's been some ferment in the Exchange community around a post written by VMware's Deji Akomolafe titled "A Stronger Case For Virtualizing Exchange Server 2013 - Think 'Performance'" and the response from Tony Redmond, "VMware tells Microsoft that they don't know anything about Exchange 2013 performance." A lively debate has ensued, with the debaters mostly falling into two groups, one fervently pro-virtualization and the other pointing out (quite rightly IMHO) that virtualization often hinders more than it helps.


I don't want to address the specifics of Deji's post or Tony's response, except to say that I am more inclined to agree with Tony: the Microsoft Exchange server sizing tools are field-proven and reflect countless man-years of engineering expertise, but they're still only a starting point for sizing enterprise deployments. (I also agree with Deji that the Exchange team has a history of stiff-arming virtualization, although that stance has changed over the last few years). Instead, I present to you the following:


Why Yoda? Well, I didn't have a good picture of Ross Smith IV handy, so this will have to do.


The important part of this picture isn't Yoda, it's the "you must be this tall…" sign. Ride engineers at Disney, and every other amusement park, have to size the hardware of their rides to match their expected audience. While they could potentially design for extremes of height and weight, doing so would add cost and complexity for relatively little benefit, so, instead, they set height and weight limits (and these limits go both ways; many rides can't safely be ridden by people over 6'7" or so).


What does this have to do with Exchange? Simple. We can't use height as a determinant, but I think we need an equivalent metric for organizational maturity, a sort of "you must be this tall to deploy Exchange" measurement. Exchange is an extremely flexible product that supports a very wide range of configurations. At the simple end, we have a single server with JBOD storage. At the complex end, we have multi-site, multi-DAG hybrid deployments using SAN storage. The skills required to design, deploy, and operate these configurations necessarily vary. As the environment gets more complex, two things happen: your organization needs a wider each range of skills, and the level of each of those skills required increases. Let's take a look at each of these changes in the context of Exchange.


First, the skill range. Obviously if you take VMware's suggestion and virtualize Exchange, you'll need someone who knows how to design, implement, and operate VMware. (nb.
This is equally true if you use Hyper-V, of course.) That's a brand-new specialized skill set that you may, or may not, already have. My own bitter experience confirms that properly sizing VMware servers is a learned skill, one which many organizations don't have and which some will never develop. (If you've ever had a customer pause a deployment to put more RAM or disk space into a hypervisor host, raise your hand!) There are others, too, including designing and maintaining virtual networks, disaster recovery for hypervisor hosts, integration of hypervisor hosts with your SAN if you're using one, and (my personal favorite) the complex and punitive system of licensing requirements and restrictions that some hypervisor vendors impose.


Next, the skill level. For most of these skills, it's nowhere near enough to have one dude on your team who watched a webcast that one time. If you're going to virtualize business-critical workloads, you have to treat them as critical, which means ensuring that you have sufficiently skilled people managing them. I realize that this sounds like "IT operations 101" but it's a sad fact that familiarity with a technology and mastery of it are worlds apart. The more diverse the skill range you have to keep in house, the harder it is for any one person to have sufficient skill depth. This leads to specialization, which is why we end up with people (to cite one example) who make big bucks as DBAs or virtualization engineers despite not necessarily knowing anything about the applications they're providing a platform for.


If you're going to deploy virtualization, there is no way around the inconvenient fact that virtualizing things makes them more complex. You have 100% of the actual workload, plus a virtualization infrastructure tax. Sure, you can argue about the size of the tax, but you're very unlikely to convince me that there is no such tax. (And understand: when I say "tax" I'm talking about complexity and the number of moving parts, not the cost of licenses, which is a separate and unpleasant tax associated with some hypervisor solutions.)


Given that premise, you have to carefully consider the complexity tax that virtualization imposes on its own and as a driver of the two skill factors I just talked about. Effectively, to deploy virtualization you're paying the virtualization tax and, quite likely, paying for additional virtualization-specific skills… an additional form of tax. That's on top of the Exchange complexity tax that you pay for doing things such as using SANs instead of JBODs or splitting server roles.


In other words, the more you deviate from the preferred architecture, the more likely you are to have to pay those taxes. Plain and simple. Just like with real-world taxes, you cannot eliminate them or just decide not to pay them (unless you live in Greece, but I digress). You can seek to lower your tax exposure… which is precisely why Microsoft doesn't use virtualization in Office 365. Or you can decide that the amount of tax you pay is worth it for the benefits you receive. That's a legitimate decision, but it's not the same as just saying "oh, there is no tax."


It's interesting that the software engineering world solved this problem some time ago. The Capability Maturity Model is a standardized way to assess how mature and repeatable an organization's development process is. It's a good yardstick to assess whether a given organization is able to tackle particularly difficult projects.


My argument comes down to this: no matter what vendors say, and no matter what your friendly neighborhood Exchange MVPs say, the ultimate yardstick for whether a particular configuration is appropriate for your organization must be tied to your organizational skill and maturity levels. The more complex a configuration is, the higher the required skill level to make truly effective use of it, and thus the fewer organizations will be able to take advantage of it. Keep that in mind when you're deciding on how to design and deploy Exchange, or any other Microsoft enterprise server product for that matter. Are you tall enough to ride the ride safely?


(Title image from