NetApp vs EMC usability report: malice, stupidity or both?

Most are familiar with Hanlon’s Razor:

Never attribute to malice that which is adequately explained by stupidity.

A variation of that is:

Never attribute to malice that which is adequately explained by stupidity, but don’t rule out malice.

You see, EMC sponsored a study comparing their systems to ones from the company they look up to andΒ try to emulate. The report deals with ease-of-use (and I’ll be the first to admit the current iteration of EMC boxes is far easier to use than in the past and the GUI has some cool stuff in it). I was intrigued, but after reading the official-looking report posted by Chuck Hollis, I wondered who in their right mind will lend it credence, and ignored it since I have a real day job solving actual customer problems and can’t possibly respond to every piece of FUD I see (and I see a lot).

Today I’m sitting in a rather boring meeting so I thought I’d spend a few minutes to show how misguided the document is.

In essence, the document tackles the age-old dilemma of which race car to get by comparing how easy it is to change the oil, and completely ignores the “winning the race with said car” part.Β My question would be: “which car allows you to win the race more easily and with the least headaches, least cost and least effort?”

And if you think winning a “race” is just about performance, think again.

It is also interesting how the important aspects of efficiency, reliability and performance are not tackled, but I guess this is a “usability” report…

Strange that a company named “Strategic Focus” reduces itself to comparing arrays by measuring the number of mouse clicks. Not sure how this is strategic for customers. They were commissioned by EMC, so maybe EMC considers this strategic.

I’ll show how wrong the document is by pointing at just some of the more glaring issues, but I’ll start by saying a large multinational company has many PB of NetApp boxes around the globe and 3 relaxed guys to manage it all. How’s that for a real example? πŸ™‚

  1. Page 2, section 4, “Methodology”: EMC’s own engineers set up the VNX properly. No mention of who did the NetApp testing, what their qualifications are, and so on. So, first question: “Do these people even know what they’re doing? Have they really used a NetApp system before?”
  2. Page 10, Table A, showing the configurations. A NetApp FAS3070 was used, running the latest code at this moment (8.01). Thanks EMC for the unintended compliment – you see, that system is 2 generations old (the current one is 3270 and the previous one is 3170) yet it can still run the very latest 64-bit ONTAP code just fine. What about the EMC CX3? Can it run FLARE31? Or is that a forklift upgrade? Something to be said for investment protection πŸ™‚
  3. Page 3 table 5-1, #1. Storage pools on all modern arrays would typically be created upfront, so the wording is very misleading. In order to create a new LUN one does NOT NEED to create a pool. Same goes for all vendors.
  4. Same table and section (also mentioned in section 7): Figuring out the space available is as simple as going to the aggregate page, where the space is clearly shown for the aggregates. So, unsure what is meant here.
  5. Regarding LUN creation… Let me ask you a question: After you create a LUN on any array, what do you need to do next? You see, the goal is to attach the LUN to a host, do alignment, partition creation, multipathing and create a filesystem and write stuff to it. You know, use it. NetApp largely automates end-to-end creation of host filesystems and, indeed, does not need an administrator to create a LUN on the array at all. Clearly the person doing the testing is either not aware of this or decided to omit this fact.
  6. Page 4, item 4 (thin provisioning). Asinine statement – plus, any NetApp LUN can be made thick or thin with a single click, whereas a VNX needs to do a migration. Indeed, NetApp does not complicate things whether thin or thick is required, does not differentiate between thin and thick when writing, and therefore does not incur a performance penalty, whereas EMC does (according to EMC documentation).
  7. Page 4, item 5 (Creation of virtual CIFS servers). The Multistore feature is free of charge on all new systems and allows one to create fully segregated, secure multitenancy virtual CIFS, NFS and iSCSI NetApp “partitions” – far beyond the capabilities of EMC. Again, misleading.
  8. Page 4, item 6 (growing storage elements). No measurable difference? Kindly show all the steps to grow a LUN until the new space is visible from the host side. End-to-end is important to real users since they want to use the storage. Or maybe not, for the authors of this document.
  9. Page 5, Item 1. We are really talking here about EMC snapshots? Seriously? Versus NetApp? To earn the right to do so assumes your snapshots are a usable and decent feature and that you can take a good number of them without the box crumbling to pieces. Ask any vendor about a production array with the most snaps and ask to talk to the customer using it. Then compare the number of snaps to a typical NetApp customer’s. Don’t be surprised if one number is a few hundred times less than the other.
  10. Page 5, item 3 (storage tiering): part of a longer conversation but this assumes all arrays need to do tiering. If my solution is optimized to the level that it doesn’t need to do this but yours is not optimized so it needs tiering, why on earth am I being penalized for doing storage more efficiently than you? (AKA the “not invented here” syndrome).
  11. Page 6 item 1 (VMware awareness): NetApp puts all the awareness inside vCenter and, indeed, datastore creation (including volume/LUN/NAS creation and resizing), VM cloning etc. all from within vCenter itself. Ask for a demo and prepare to be amazed.
  12. Page 6, item 2 – (dedupe/compress individual VMs): This one had my blood boiling. You see,Β EMC cannot even dedupe individual VMs, (impossible, given the fact that current DART code only does dedupe at the file and not block level and no two active VMs will ever be exactly the same), can’t dedupe at all for block storage (maybe in the future but not today), and in general doesn’t recommend compression for VMs! Ask to see the best practices guide that states all this is supported and recommended for active production VMs, and to talk to a customer doing it at scale (not 10 VMs). A feature you can theoretically turn on but that will never work is not quite useful, you see…
  13. Page 8, entire table: Too much to comment on, suffice it to say that NetApp systems come with tools not mentioned in this report that go so far beyond what Unisphere does that it’s not even funny (at no additional cost). Used by customers that have thousands of NetApp systems. That’s how much those tools scale. EMC would need vast portions of the Ionix suite to do anything remotely similar (at $$$). Of course, mentioning that would kinda derail this document… and the piece about support and upgrades is utterly wrong, but I like to keep the surprise for when I do the demos and not share cool IP ideas here πŸ™‚
  14. Page 11, Table B1: In the end, the funniest one of all! If you add up the total number of mouse clicks, NetApp needed 92 vs EMC’s 111. Since the whole point of this usability report is to show overall ease of use by measuring the total number of clicks to do stuff, it’s interesting that they didn’t do a simple total to show who won in the end… πŸ™‚

I could keep going but I need to pay attention to my meeting now since it suddenly became interesting.

Ultimately, when it comes to ease of use, it’s simple to just do a demo and have the customer decide for themselves which approach they like best. Documents such as this one mean less than nothing for actual end users.

I should have another similar list showing clicks and TIME needed to do certain other things. For instance, using RecoverPoint (or any other method), kindly show the number of clicks and time (and disk space) for creating 30 writable clones of a 10TB SQL DB and mounting them on 30 different DB servers simultaneously. Maintaining unique instance names etc. Kinda goes a bit beyond LUN creation, doesn’t it? πŸ™‚

All this BTW doesn’t mean any vendor should rest on their laurels and stop working on improving usability. It’s a never-ending quest. Just stop it with the FUD, please…

Finishing with something funny: Check this video for a good demonstration of something needing few clicks yet not being that easy to do.

Comments welcome.

D

Technorati Tags: , , , ,

4 Replies to “NetApp vs EMC usability report: malice, stupidity or both?”

  1. I would hope one of my calls would never be so boring that a participant finds himself not paying attention and instead writing in his blog. πŸ˜‰

    First, a few words about the importance of usability.

    Usability is core to the success of any technology, however there’s much more to it than counting mouse clicks. When I assess usability of software applications I look at everything (e.g., the positioning and presentation of written and graphical information on the screen, labeling and semantics, color palettes, user expectations, procedures, UI performance, user error rates, etc) including the usability of any end user documentation.

    Usability can make or break a user’s perception of the best engineered hardware. Think near-meticulously engineered BMWs and the company’s 1st gen Windows CE based iDrive UI back in 2001. That was a horror show. CCC and the later CIC aren’t significantly better. Both fail to address key issues and tradeoffs of the iDrive concept.

    And now a few words about posts such as yours above.

    I recall having a similar conversation very recently with some people you may know. The problem I see with posts like the one above, and the one’s that appear often on other employee blogs from companies such as EMC, HP and HDS, is that they tend to get bogged down in tit-for-tat discussions of engineering and design minutiae.

    I’m not suggesting that such discussions are unimportant. In fact, they can be more revealing than intended. Distrustful technologists find such posts very entertaining and valuable as evidence of their strong belief that all vendors (including NetApp and EMC) engage in sleights of hand and mind. At the end of the day they’re simply going to select whatever fulfills their needs best regardless what you write.

    Instead, I am suggesting that a company’s marketing should take the lead, not one of its employee’s blogs. Not only is your reach practically insignificant by comparison (no offense to you or your fellow tech bloggers) but it’s also not offered in a form that’s as easily digested by prospects. In a nutshell, your efforts may be counterproductive for your employers. If your points have merit and offer meaningful differentiation they should be captured in your employer’s marketing message.

    Everything else is just noise and unfortunately will be viewed by outsiders as the rants of whiney competitors in an engineering pissing contest. I’m pretty sure that isn’t your intent.

    1. The other issue is that each vendor’s employees often have blinders on. I can easily show where each vendor falls short, each excels. I can do it with more than these two.

      However, I do find it useful and entertaining to read you blog.

  2. Joseph and Urban,

    The point of this post was to refute slanderous and erroneous material spread by a competitor.

    Not to prove there are no downsides to any specific technology.

    The perfect widget has not been invented yet – and I think it never will. Which is a good thing.

    Regarding the blinders – that’s a basic human condition, even people that think they don’t have blinders, do, and are quite unaware of it. A bit beyond the scope of this article πŸ™‚

    It is quite comical to see competitive materials that depict certain products as essentially useless. The people writing such materials aim them at their own employees in order to enlarge the blinders, not remove them.

    I’ve now been at multiple sides: Customer, reseller of various tech, Vendor. I sometimes talk to competitor engineers that seem to firmly believe NetApp is a small tier5 NAS storage player.

    Well, NetApp is now officially the #2 storage vendor by volume after EMC, and the #1 vendor by platform. The largest DBs in the world are on NetApp gear. Believing we are small is called “the ostrich manoever”. Whoever is executing this manoever – feel free to keep doing it, but it’s not helping you so far.

    I urge fellow engineers to look beyond the materials created by their own company.

    Otherwise it’s like you’re only reading the government-controlled newspaper in certain oppressive regimes. Chances are, you’re not learning the whole truth… πŸ™‚

    D

  3. So excuse me for being 7 months late to this party, but I take exception Joseph’s comments.

    As a guy involved in the NetApp vs EMC vs Compellent decision cycle right now, I found this post amazingly helpful.

    NOT because I will take what was posted verbatim, but rather as I believe it is intended, and that is to ask probing questions of *all* vendors about the issues raised here.

    Perhaps I am atypical, but as a Director guy who is one step removed from day to day management of these systems, it is this and similar posts that really help me understand what is relevant to my business model. It is this information that helps me work with the team to ask the questions that will get the techs out of the data center in and into the business, where we can make a REAL difference.

Leave a comment for posterity...