Why Microsoft’s Head is up its DAS

I’ve been doing a bunch of research on cloud-based email lately. It started when I was speaking with a number of Wikibon members about what they’re doing with Exchange and whether Exchange 2010 is changing the way they think about deploying storage. The Exchange team in Redmond has been pushing DAS harder than I’ve ever seen. Microsoft is telling customers that it has dramatically reduced the IO load from Exchange 2003, which is true.

Exchange 2003 was IO bound and very ‘bursty’ meaning performance was unpredictable. I believe the technical term for this is Exchange 2003 is a pig. So SAN has been the obvious choice for many Exchange deployments. Exchange 2007 addressed much of this IO problem but many clients skipped right over 2007, waiting for Exchange 2010. Wish I’d taken that path with Vista.

Microsoft is now pulling out all the stops. It’s telling clients that I spoke with to think about maintenance expiring on Exchange 2003 (I think you can still buy an extended service plan through 2014 if you give up your third child) and that SAN is not a recommended configuration for 2010. Microsoft is telling customers to worry about complexity and SAN can be a single point of failure. The logic put forth is that if I lose a DAS device I only lose part of my storage whereas if my SAN goes out…all my data is inaccessible. Interesting logic I thought.

I started to think about Microsoft and how they’ve behaved over the years and I thought that Microsoft must be trying to take back some of the value they’re losing to storage vendors and that’s why they’re recommending DAS so aggressively. It’s clear, right? They’re trying to put more storage function like replication into their own software stack and make their software more valuable to users…we’ve seen it a zillion times.

Except…I spoke with Microsoft about this and they said that really wasn’t the motivation. In fact they said many inside Microsoft love SAN. Rather Microsoft indicated to me that the vast majority of problems with Exchange can be traced to storage so Microsoft figures they’ll do the industry a favor and improve certain Exchange functions and simplify the whole environment; which will make Exchange better and more reliable. Thanks Mr. Softy :-), that’s so nice of you.

Being the skeptic, I starting to think about this more deeply to try to find the real motivation behind these trends. Then it hit me in a moment of mastering the obvious; something I’ve grown quite good at.

Google. Duh! Everything these days goes back to Google. Of course. Here’s an oldie but goodie updated to show the next wave we’re about to see in the technology industry.

There are three key points I always make about this chart:

The waves keep getting bigger.

With each new wave, some big companies die and some small companies get big.

Each wave has a big daddy and this coming decade it’s Google.

No company has more to lose in this transition than Microsoft.

The Google Apps Tsunami

Now I’m not predicting the death of Microsoft mind you. I don’t see that happening. Too much cash, too smart, too many good people. But I am here to tell you that Google Apps is getting into Microsoft’s shorts big time, using plays that Microsoft has never seen before. This isn’t Novell or Lotus or Netscape or Sun or even Oracle. This is Google– the advertising monster. And it started with a blank piece of paper and it’s driving Microsoft nuts. Microsoft simply doesn’t have a good answer.

Check out this data that I and some of my colleagues put together comparing on-premise Exchange costs with Microsoft Exchange Online and Google Apps for a 10,000 seat installation.

Microsoft Exchange on-premise is about 4X more expensive on a TCO basis than Google Apps; and Microsoft’s SaaS offering, Exchange Online, is about 1.6X the cost of Google Apps, even though its monthly subscription is less (check out your pricing with this calculator from Microsoft; here’s Google’s pricing— no need for a fancy calculator). And the big pieces of the cost bar that Microsoft wants to lower are storage and archiving (which is really storage). Oh, did I mention that Microsoft doesn’t get any of this revenue today so it has nothing to lose by telling all of its customers to bail on SAN.

So the bottom line is Microsoft wants to bomb storage costs so it can make on-premise Exchange more competitive with Google and preserve its obscene margins from Exchange and client-side software. It might actually work for a while.

But is DAS really cheaper than SAN for Exchange? Well, it depends. In my next post we’ll look at a model we built to answer the question: Should you use DAS or SAN for Exchange?

David: Just wanted to note my response to your gracious comments and let you know I appreciate your spending the time to reply. I should have a more detailed response in a few days. Thanks for all you're doing with Wikibon.

http://www.facebook.com/people/David-Vellante/725454387 David Vellante

Ditto Mark…You're very welcome. Say I went to your blog today and it showed 3 comments to your 'Pound SANd' post but the comments weren't visible. ???

It’s good to see not everyone has drank the Microsoft Exchange Kool Aide.

I have been Supporting, Designing and Implementing Exchange for a very long time and some flavor of email even longer. It's funny that you showed “network centric” where Microsoft Exchange had considerable problems, and still does, with Network configuration problems yet they didn't go all out to fix these problems by simplifying (fixing) the networking within Windows or Exchange. If anything it’s even crankier and prone to more network problems than before. A network burp now could result in DAG replication issues resulting in complete recreation or reseeding of databases. The jump from DAS to SAN is a smoking mirrors routine. Basically Microsoft stating “It's not our fault Exchange is expensive, it’s the SAN vendors fault” So get rid of the millions your company spent on SANs and buy into NOT CHEAP DAS/JBOD which does the same thing without management or proven uptime. RAID is old fashioned? Or so Microsoft will tell you. What do you call Replication of data onto multiple storage das/jbod via software? SOFTWARE RAID? Take all the years of technology that made RAID controllers, HBA Cards, Storage Arrays reliable and toss that out for coders that rarely know more than the functions they are writing, but why worry Windows Update will save you, unless that BUG causes Logical corruption. But don’t worry just restore from backups, but those are old fashioned according to Microsoft too. Since when was Software RAID more reliable than hardware RAID? NEVER. Then lets toss up that replication over the most unreliable part of most customers environment, the NETWORK.

Exchange vs Google, unfortunately Microsoft is spending way too much time trying to catch up to Google and forgetting all the companies that use Exchange and why. Do companies really want all their corporate data up on a database where the admins are low paid offshore and out of country, or worse out of jurisdiction for prosecution when data is STOLEN? Not all the countries your data could be in has as strict prosecution as the company wanting to use Google would like. Proof, just look at how many hackers have been prosecuted for causing the major Viruses over the last couple of year costing millions/billions in lost man hours and data recovery.

What about corporate security from hackers? If every person on the planet can get to email, then so can the hackers. Google is a nice trend for HOME and maybe school users, but corporate/military/government users? Absolutely NOT.

Outsourcing is bad enough, but completely moving your email offsite to save a few bucks because Google’s “Cool”. All companies have done is to split the email environment out of their datacenters where ADMINS and security watch over all the data, not just email. What will the cost to the companies be in a year or two when they realize they have to go back?And just like outsourcing, the day will come when the companies realize they didn’t save a few bucks and just made everything more complicated.