One Size Does Not Fit All

Certain vendor-driven concepts in this industry can sometimes drive me nuts.

Not because a certain concept might be less-than-relevant, but because some vendor (and analyst) concepts can actually lead you down an uncertain path where you'd be unhappy with the outcome.

Today, I want to decipher the concept of "application optimized storage" -- the idea that if you've got Application X, it's best if you use Storage Y.

This, I believe, is oversimplification to the point of potential harm, at least to many people.  And I'd like to find a way to get our authoritative voices in the industry to take a slightly more sophisticated view of the situation.

The Proposal

We've seen it from all manner of storage vendors. 

"The Best Storage Array For Exchange"

"Doing VMware?  You Need Storage Array XYZ".

Ditto for Oracle.  And SQLserver. And SAP.  And archiving.  And even video surveillance.

Deceptively simple, isn't it?  Makes storage selection nothing more than making a list of all your important applications (or operating system environments), and simply find the 'best' for each one.

Nothing could be farther from the truth, in my humble opinion.

Here's why.

Application Usage Profiles Change Over Time

I believe there's no such thing as a static profile for most applications -- they're incredibly dynamic.  They start in a test/dev/eval phase, they move to limited production, more users climb on, it becomes part of the business fabric, becomes more mission-critical, etc.

Sure, there are a few exceptions.  But for most real-world applications, it's really hard to predict just what kind of service levels will be required in three months, let alone three years.

But a few things do stand out: successful applications usually result in the requirement for more demanding service levels over time -- performance, availability, recoverability, no down time, etc.  What looks good at the outset might not look so good over time.

Not only that, but most applications get peaks and valleys -- beginning of the business day, end of the quarter, holiday season, tax season, etc. -- and these are hard to predict as well.  A storage system that can't keep up with the workload can make things run just as slowly as an inadequate server, or network.

The presumption that a given storage device can meet all of your service level needs, cost-effectively, over a long timeframe is possible, but shouldn't be a standard assumption.

Service Level Requirements Are Different Even Within The Same Application

When applications get to a certain size, you'll notice that -- even within a single, supposedly homogeneous applications -- there's a wide range of requirements for different service levels.  Some pieces need more,  some need less.

Oracle databases: redo logs, indexes, datastores, archived data -- all present unique requirements that may or may not be relevant in your environment.

Ditto for Exchange.  And SAP.  And most anything else of a certain size. 

Now, going through the effort at looking at different pieces of a given application, creating profiles of service levels required, etc. -- well, you may not want to do that with everything in your environment.  But if your environment is of any size, it's worth at least taking a look at it.

My favorite non-example of this is VMware consolidation. 

Most people are looking at consolidating a variety of workloads (server and desktop) into virtualized servers.  That means they're also consolidating a wide range of storage workloads and service level requirements as well.

Saying "this is the only storage device you'll ever need with VMware", well, that just doesn't work for me in most cases. 

I think at one time NetApp tried to take this to an extreme, proposing that their "unified storage" could do *everything* in most environments.  I think it's safe to say they've backed away from that particular egregious positioning.

Information Through A Different Lens Creates New Requirements

When we first got involved in email archiving, people wanted to archive to the cheapest stuff possible.  Availability didn't matter, performance didn't matter, manageability didn't matter, etc. 

Just give me the big, cheap parking lot, please.

Well, the first thing that happened is that the archive storage was busier than anyone thought.  Since it looked like part of your email box, people tended to use it more often.

And it also had to be managed as part of the environment, so that became important as well.

And when we moved to compliance and eDiscovery, being able to lock down important emails (think Centera) and provide chain-of-custody became more important as well. 

The point here is that information storage requirements have this way of changing in surprising and unpredictable ways.

As another example, Arun Taneja wrote a nice post on storage for video surveillance.  It's a bit of awareness-raising on this relatively newer application, and he's arguing that cheap is good.  OK, for someone who's got a bit of this to do, perhaps that's the right advice.

Not to disagree, but we're already working with a large number of customers who consider this video content relatively important, more than you might think.

Companies who will be using video footage to protect themselves in court, for example.  Or an organization that's responding to an imminent security threat, and wants to scan through a lot of video files right now.  Or even a few clever retailers that are using the video to figure out how people wander through stores.

And we can introduce you to folks who already have surprisingly large farms of video storage for this purpose, and are now looking at manageability aspects.

I'm not trying to say that everyone will end up in this position, but I don't think many people have the luxury of making a point decision and assuming that the requirements will stay locked down for any length of time.

Things change -- plan on it.

Managing Everything Becomes An Issue

The dark side of "best of breed" is dealing with complexity.  Imagine that you've got a dozen important applications, and -- as a result -- you've decided you want to implement a solution from roughly a dozen different vendors.

Any "optimization" you thought you'd get would be absolutely clobbered by the time you'll spend listening to all the vendors, working out integration and support problems, trying to stay ahead of all their new features, etc.

The trend I've seen is pretty clear -- a strong interest in working with a smaller number of vendors who have broader offerings.  Not especially good for the little guys, but you can understand it from the customers' perspective.

So, What Does EMC Recommend?

Nothing really new here -- just what we've been saying for a while.

In short:

• Plan for growth.  The ballpark number is about 60% logical capacity growth a year.  And it's been that way for a very long time.  You can slow it, but you can't stop it.  Or, at least, no one that I've ever heard about.
   
• Think about the problem in terms of a catalog of service levels.  Your storage infrastructure should provide a reasonable range of service levels (and cost points) to applications.  Even better, tell people what your true costs are.  As individual requirements move up (or down), they get placed on the appropriate tier of storage.
  
  Seeing growth in low-value information?  Get more storage that does that.  Seeing growth in transactional information with high performance characteristics?  Get more of that.  Think of yourself as the service provider who offers different classes of services at different price points.
   
• Pay very close attention to "soft costs".  Management, for example.  Interoperabilty.  Migration.  Support.  I continue to be amazed by the attention paid to hard costs (e.g. equipment) and the less intense focus paid to the soft costs, which tend to overwhelm any hard cost differentials.
  
  I personally am a fan of what DMX does -- a very wide range of service levels in a single frame, with more coming.  People tell me that high-end storage is expensive.  I argue back that trying to own and run dozens of different, smaller storage arrays can be really, really expensive.  And when we run the numbers for larger environments, the results can be very surprising.
   
• Work with someone you trust.  Your information is pretty important stuff, both now, and in the future.  Even better, work with someone who's got answers to problems you might not even know you'll have in the future ...

Sometimes people get frustrated when they ask us "what is the best storage for application X" and we tend to answer "it depends".  I think they're looking for a quick answer. 

Wish I had one for them.