Home > datacenter, Hardware refresh, Strategic Direction > Does the Storage Tecchnology Really Matter?

Does the Storage Tecchnology Really Matter?

This article is really more of a rant.  Take it for what it is.  I’m just a frustrated infrastructure admin trying to choose a storage product.

I am not a storage admin (and I don’t play one on TV), but I am on our storage replacement project representing the server infrastructure area.  In preparation for this project, I started reading a number of the more popular blogs and following some of the storage Tweeters.  One thing I noticed is that all the banter seems to be about speeds and feeds as opposed to solving business problems.  In the case of Twitter, I am guessing it’s due to the 140 character limit, but I would expect to see more in the blogs.  Some of the back & forth reminds me of the old elementary school bravado along the lines of “My dad can beat up your dad”.

I must admit that I am learning a lot, but does it really matter if it supports iSCSI, FC, FCoE, NFS, or other acronyms?  As long as it fits into my existing infrastructure with minimal disruption and provides me options for growth (capacity and features), should I care?   If so, why should I care? We recently moved the bulk of our data center to Cisco UCS so you would think that FCoE would be a highly valued feature of our new solution.  But it’s not.  We don’t run Cisco networking gear and our current gear provider has no short term plans for FCoE.  Given that we just finished a network upgrade project, I don’t forsee FCoE in our environment for at least three years unless funding magically appears.  It doesn’t mean that it isn’t on our radar; it just means that it won’t be here for at least three years.  So stop trying to sell me on FCoE support.

So who has the better solution?  I am going to use EMC and NetApp in my example just because they blog/tweet a lot.

I think if one were to put a chart together, both EMC and NetApp could be at the heading of any column.  Their products look the same to me.  Both have replication software, both support snapshots, both support multiple protocols, and so on and so on and so on.  The features list is pages long and each vendor seems to match the other.

There are technical differences in how these features are implemented and in how the back-end arrays work, but should I care?  Tell me how these features will help my business grow.  Tell me how these features will protect my business.  Tell me how these features will save my business money. Tell me how they can integrate into my existing infrastructure without having to change my infrastructure.  And when I say “tell me”, don’t just say “it can do this”, or “it can do that”.  Give me case studies more than six pages long, give me processes and procedures, and give me REAL metrics that I can replicate/validate (assuming I had the equipment and time) in a real-world scenario which information telling me how they affect my apps and customers.

This is an area where companies need to do a better job of marketing.  EMC started down this path with the vBlock.  Techies aren’t really interested because the specs are blasé.  C-level folks love it because it marketed towards them and the marketing focuses on the solution from a business perspective.   NetApp is starting to do the same with their recently announced FlexPod.  The main downside to these new initiatives is that they seem to forget about the SMB.  I think it’s great from a techie POV that a FlexPod can handle 50,000 VDI sessions.  But as an IT Architect for my organization, so what?  We only have 4200 employees or so.

Right now, I’m sort of in-between in what type of information I need: technical vs business.  I am technical at heart, but have been looking at things from a business perspective the last few yrs.  I am in the process of trying to map what our mgmt team wants to accomplish over the next few years to the storage feature sets out there in the market.  This is where both types come together.  Now if I can just get past the FUD.

  1. November 16, 2010 at 8:56 am

    I wouldn’t be so quick to discount FCoE in your environment. Since you’ve moved to Cisco UCS, wait for the v1.4 code release (January?), then land the FCoE capable storage array of your choice directly on the 6100-series fabric interconnects.

  2. November 16, 2010 at 11:31 am

    A question back to you is, “What business benefit would I receive by attaching the storage directly to my UCS”? What impact would have on the rest of my non-UCS servers and such? What business problems does it solve?

    I understand I can architect things differently based on protocols and capabilities. Also, all the top vendors seem to be the same on paper, spec-wise. Rather than sell me on specs, tell me how these features are going to help my business and solve my business problems.

  3. Jeff
    November 16, 2010 at 3:12 pm

    My assumption here would be that you ultimately want to arrive at a point where 100% of your environment is virtualized or consolidated on UCS. As such, if UCS is your platform of choice, then landing FCoE directly on the 6100 would eliminate a significant amount of storage networking equipment. That’s a savings not only in hardware costs (including life-cycle of said hardware) but also a reduction in complexity (one less fabric to support).

    As a case in point, had my own UCS/EMC project happened post-v1.4 UCS and EMC’s release of a FCoE card, the entire Fibre Channel storage architecture could have been eliminated, reducing total project costs by 10% as well as incurring no ongoing support and maintenance for the FC hardware. Over a five year period, it works out to something on the order of a $30K savings. Is that the business case you’re looking for?

    Even if you’re not 100% UCS now, if you envision getting there at some point, then landing FCoE is still a wise choice since you could always support existing (legacy) iSCSI or FC for the other hosts, and then wind those investments down (migration into UCS) without having to make further changes to your core UCS/storage environment.

    • November 16, 2010 at 5:26 pm

      Thank you. That’s exactly what I am talking about. It’s not about the spec sheet per se, but what those specs can do for me (my business). Showing how I can reduce costs, simplify my environment, ease the administrative burden, and such is how I want vendors to present to me. I still want the specs, but I NEED the business justification. It’s no longer a “buy based on the spec-sheet” world.

  1. No trackbacks yet.

Leave a reply to Jeff Cancel reply