Friday, April 9, 2010

Dear Jon - Use Cases for Block-Level Tiering

Yesterday afternoon I happened to pop into Tweetdeck and saw a tweet from Jon Toigo -

I'm interested in exploring the case for on-array tiering. Makes no sense to me. Sounds like tech for lazy people!...

I engaged Jon in a quick tweet discussion (I'm the "inbound tweet") until we both had to attend to personal matters but I wanted to come back to this statement because he's brought this up before and I find it a little bothersome. Not because Jon's asking a question or challenging the use case - I'm perfectly fine with that.

My rub is that his premise seems to be that block-level tiering is being positioned as a replacement for data management policy and best practices. That's not the story - at least not the Compellent story. For example, Jon's last tweet on the matter was this:

Seems like understanding your data and applying appropriate services to it based on its business context is becoming a must have, not a theoretical nice to have.

If anyone's selling array based block-level tiering as a replacement for data management policy, archiving best practices, private information security and the like, I'm not aware. This is a pure storage optimization play. There's nothing about automated block-level tiering that would prevent the development, implementation or enforcement of a good data management policy.

What makes my ears prick up is when a statement like Jon's attempts to paint automated block-level tiering as an evil when it's nothing of the sort. You want to implement an HSM scheme or data management policy on top of ATS? Go right ahead - you'll still have data that is less actively accessed (or practically inactive for that matter) until the data management police take appropriate action is my guess.

On Jon's blog, he quotes an anonymous former EMC employee:

The real dillusion [sic] in the tiered storage approach is that the data owners – the end users – have no incentive to participate in data classification, so the decisions get left to data administrators or worse (software). Just because data is accessed frequently doesn’t mean the access is high priority.

This really sums up the ATS nay saying. First, it's not a delusion to say that data owners aren't incented to participate in data classification. It's an ironclad fact. If you're lucky enough to have published a data retention policy, the exemptions and exclusions start flying almost before the ink is set on paper. Still, I don't believe that ATS is a solution to that problem, but rather a reaction to it.

Secondly, the whole concept that ATS is somehow trying to equate data access to criticality is, in my opinion, fallacious. At some level, yes, access frequency tells us a lot about the data - chiefly that there's a lot of interest in it. It doesn't tell us that it's necessarily important to the business. It may be - it likely is. It may not be. Conversely, infrequently accessed blocks may contain business critical data. Maybe it doesn't and likely it's less critical (now) because it's not being accessed frequently (now).

So ATS gives you a way to store data cost effectively, without impeding the data steward from taking action to classify the data and handle it appropriately. It's not an enemy of data management - nor an ally for that matter. So why is it drawing so much ire from Jon?

Jon, feel free to continue to champion for better data management practices - I'm with you. But please don't waste energy fighting something that adds value today while we're waiting for that battle to be won.

As for the use cases - ask your friendly neighborhood Storage Center user!

Friday, April 2, 2010

Hotel Compellent


Tommy posted a great analogy piece on his blog which explains storage in terms of hotel ownership and occupancy rates versus room cost.  Not to take anything away from Tommy, because it was a good example for non-technical audiences, but I want to point out that analogies like statistics in USA Today, can be used to position your point favorably while making a seemingly fair comparison.
Let me illustrate.  Let’s use the storage-as-hotel example but make some modifications.  Hotel X has an outstanding occupancy rate – or shall we say occupancy capacity but our enterprising new owner quickly finds that he has a problem.  Following the advice of his architects he’s built a high end hotel with luxury rooms outfitted with imported artworks, complimentary services like turn down and pillow chocolates and other fancy features.  Because of this, he finds that his operational expenses (opex) begin to erode the apparent capital expense (capex) efficiencies he thought he’d realized because of the higher capacity.
On top of that, Hotel X has a highly trained and experienced staff waiting to serve the every whim of the guests from bell service, to concierge, to shoe shine, to someone who will hold the door open for you. 
Who wouldn’t love to stay at Hotel X?  I would – sounds like a great place!
But, I can’t afford it.  Nor can many travelers who simply need a place to sleep, shower and maybe make a few phone calls at the end of the business day.  Hotel E might be the perfect place for them.  Clean, comfortable and cheap.  Not too many services available but you can get a free cinnamon bun in the morning and a complimentary cup of coffee.
But consider the proprietors of Hotel C – let’s call them Phil, Larry and John.   They’ve been in the business for many years and they know hotels and more importantly they understand guests.  They know that most guests (say 80%) really just need a place to sleep for a night or two and don’t want to pay a lot for stuff they don’t need.  The other 20% are high end travelers, VIPs or executives who expect the best and demand all sorts of expensive services – and they have the money to pay for it.  So, Phil, Larry and John build a hotel to meet the needs of everyone.
Not only can a guest choose to stay in a room that meets their demands, if those demands should change they can upgrade or downgrade to a more appropriate level of service.
OK, you get the point and I could go on and on with this.  I even thought about talking about Hotel E as an example of vendor lock in (“you can check out any time you like, but you can never leave”).  But the bottom line is this:  Take the time to understand what you’re getting or you’ll go broke staying in places like Hotel X and won’t have money to get back home!