Feature Lust By Storage People

Another day, another interesting conversation.

Today's conversation was with a customer who was ABSOLUTELY CONVINCED that they HAD TO HAVE thin provisioning on their storage arrays, and HAVE IT TODAY.

So, rather than argue, I thought I'd ask a few questions, just to make sure I understood what they were after.

And it was interesting, to say the least.

The Background

Thin (or virtual) provisioning is starting to get more popular in the storage biz.  The idea is simple: many applications don't use the storage they ask for.  So, rather than allocate a bunch of storage that *might* be used some day, provide a large (virtual) amount, and grow into it, so to speak.

And, for many people, it appeals intuitively as an easy way to save money.

But like many other similar technologies, there are caveats and rough edges to be aware of.

Examples include tier 1 applications that don't like their storage scattered around unpredictably, or don't like running out of capacity.  Or management tools that don't really handle the virtual vs. physical concept too well.  Or array-based replication tools that don't understand these volumes.  Or management processes that don't closely monitor virtual vs. physical and can result in a very bad storage day.

EMC has had virtual (thin) provisioning on Celerra (NAS and iSCSI) for a while.  The DMX version is just reaching the marketplace as I write this.

And -- there's no argument -- it's a handy feature to have in the ever-expanding storage toolbox.

So, What Do You Really Want?

That's always a good starting point for a conversation like this, isn't it?

The answer was what I expected: we think we're wasting storage, and if we implement thin (virtual) provisioning, we'll save money on wasted storage capacity.

Sure -- I agreed -- there's the potential for that.  Have you looked at your environment and come up with some estimate as to how much you'd potentially save?

Well, no, not really, they hadn't done a basic analysis of allocated vs. used storage. 

Maybe they'd save a lot, maybe they'd save a little -- they really didn't know what the benefit would be.

That caused me serious concern on two levels: first, don't go through the hassle of implementing *any* technology unless you've got a good idea what the benefit might be, and -- second -- this was indicative of what I'd charitably call "poor storage management practices" which could become absolutely lethal in a virtual provisioning environment.

But what to say without, well, insulting them?

I thought about it, and tried my first gambit -- would you be interested in a quick analysis of your environment to see what the potential benefits might be?  You know, find out what's a candidate for virtual (thin) provisioning?  Not just on EMC's products, but in general?

There was a long pause on the phone.  They were thinking about it. 

They asked me -- what would you be looking for?

Several things, really, I answered.

First, some sort of estimate of "wasted space" in your environment that's a candidate for virtual (thin) provisioning, and bounce that against your total costs for storage under management.  Then, if you wanted, we could try and project that into the future, and factor in not only expected growth, but lower storage costs.

Second, we'd look for things that aren't really a good candidate for virtual (thin) provisioning .. things like tier 1 applications that might not be happy in such an environment, replication concerns, and so on.

Third, we'd take a look at your management environment to make sure that you have the tools and processes required for a virtual (thin) provisioning environment -- things like reporting tools that showed space at both the virtual and physical level, charge back that works.  We'd also take a look at your monitoring and response processes, because running out of physical space isn't good.

And finally, we'd do a savings vs. investment analysis to make sure that your potential savings weren't outweighed by the costs associated of a new implementation, data migration, new tools and processes, etc. 

Simply put -- we want to help you make sure there's a pony there.  If your goal was to really save money, we want to establish the case that -- yes -- that's what you'll get by doing this -- be it with EMC or anyone else.

Very long pause on the other end of the phone.

I then pushed things a bit farther --  you know, while we're at it, if you want, we can take a look at your data, and come back with recommendations for tiering, archiving, data dedupe, single instancing, etc. -- as long as we're poking around -- all of which can potentially save money on storage.

Another longer pause on the phone.

Finally, the customer came back, and offered up that -- perhaps -- they ought to go back and do a bit of analysis on their environment.  And, if they thought they needed some help, they'd come back to us.

And then the truth came out ... they were severely under the gun to cut IT expenses (who isn't?) and thought that thin (virtual) provisioning might be a great way to do it.  Looked like an easy win for them. 

That's what a vendor told them.  I can only guess which one.

I said that maybe it was, and maybe it wasn't.  But I also offered that -- if you frame the problem a bit bigger, e.g. how do we save money on storage costs? -- that opens up the discussion to a wide range of potential outcomes, some of which might be quick wins.

And -- they agreed -- I had a valid point. 

Case closed.

Feature Lust Can Be A Bad Thing

Look, I fully understand being enamored with a new feature or a new technology.  I have succumbed to that siren song more times than I can count. 

And we, as vendors, don't make the situation any better, do we?

But I've learned -- the hard way -- that "outcome lust" is a far better thing than "feature lust".

Comments

[Dan]

My personal opinion is that Virtual Provisioning is intentionally overlooked in one Tier 1 environment where it could be VERY effective. Exchange is one of the few applications that can be sized properly with MS-Calc, or Excel. Users x Profile, and Users x Mailbox size. There is a bit more to it than that, but you get the idea. If you are capacity bound, because your mgmt is allocating 2 GB Mailboxes, wouldn't it be nice to provide enough spindles to meet the IO Load, but Virtually provision for the capacity. Now this scare the be-jezus out of hard-line Exchange folks, but could provide significant cost savings to one of the most inefficient hogs in the IT world.

[Chuck Hollis]

Agreed!

But I think it's also worth expanding the discussion to include "gee, have you thought about email archiving? Maybe single instancing of attachments?"