One of the trickiest problems in the storage industry is managing demand. Internal customers seem to think that storage isn't physical and we just have tons of the virtual stuff we can pick out of the air as required. I don't think they expect to talk to the server teams and find they have dozens of servers sitting spinning just waiting for the next big project, but for some reason with storage they do.
So this lack of foresight causes demand problems as arrays have to be managed. Whilst we could simply add a new RAID group or bunch of disks when customer demand requires it, allocating all the new storage on the same RAID group, chances are performance would "suck". Really we want to add storage in bulk and spread the workload.
Similar problems occur when arrays cannot be expanded and a new footprint has to be installed (which can have significant lead time and ongoing costs, for instance fabric ports for connectivity). I can hear the bleating of many a datacentre manager now, asking why yet more storage is needed and where it will go in the already overcrowded datacentre.
The standard charging model is to have a fixed "price guide" which lists all the storage offerings. Internal customers are then charged on arrears for their storage usage. Some companies may have an element of forward planning but they are torturous processes and anyway, someone always comes along with an allegedly unforseen requirement.
Ideally, the answer is for all storage users to manage their own demand, estimating BAU (Business As Usual) growth and requirements for new products. Unfortunately, the penalties for lack of planning don't usually exist and poor practices perpetuate.
So now about offering futures (or options) on storage? Internal customers can purchase a right to buy (option) or an obligation to buy (future) storage for some time in the future, say 1, 3, 6 or 12 months ahead. In return they receive a discounted price. Storage hardware costs from vendors are always dropping so the idea of charging less in the future in order to gain more of an insight into demand is probably not an unreasonable concept.
Futures/Options could also work well with thin provisioning. Storage is pre-allocated on a virtual basis up front, then provided on the basis of futures contracts by adding more real storage to the array.
Now the question is, to use futures or options? Well, perhaps futures best represent BAU demand as this is more likely to be constant and easily measurable. Options fits project work where projects may or may not be instigated. Naturally futures would attract a higher discount than options would.
I think I need to make up a little spreadsheet to test this theory out...
Tuesday, 25 September 2007
Storage Futures or is it Options?
Subscribe to:
Post Comments (Atom)
Posts
6 comments:
Similar but different concept: www.storagemarkets.com
John, yes I use this. I think it is mildly interesting but needs more "clients" to ensure the swings prices is more realistic.
Seems to me that thin provisioning is the solution that you're looking for, not futures or options. It's not an ideal solution, yet, but a step in the right direction.
Storage users (lets call them "business people") don't really care about storage. They care about their ability to make things happen in whatever business they're in. The problem is they want access to technology to be completely dynamic and free of constraints. Got a new idea that's going to make money, get marketshare, mess with the compeition? Then tell IT to "make it so."
Trouble is, IT guys and gals, and especially the storage variety, are stuck dragging physical lumps of reality around the data center floor, which tends to slow things down a bit. TP abstracts that reality so that when a user says "make it so" you can snap your fingers and the storage is there. Then behind the scenes, at midnight on a weekkend, you can go drag around more chunks of physicality to keep up the illusion that everything's hunkydory.
Isn't that the goal?
And, just as an aside, does charging internal business users for storage really work? I've been out of IT for a while, but I spent many years in a lot of shops in Europe and the US and never saw chaargeback working successfully.
Nigel, I see what you mean however thin provisioning is more likely to cause issues than resolve them. I used thin provisioning on Iceberg 12 years ago and the issues were as clear then as they are now. TP lets the problem get pushed aside; it let's management not purchase more storage. I am talking about solutions which penalise internal businesses for poor planning. The trouble is, internal customers think storage can be magic'd out of nowhere. They need a penalty for poor planning. Unfortunately as you say, most of the time chargeback is poorly implemented as provisioning is usually overridden by management doing the "make it so" you mention. Although a process is needed, what's also required is management committment to sticking to an agreed plan and punishing the offenders, despite the implications to business.
Chris, I definitely understand the sentiment, but I'm not sure that it's a sound approach. This is going to show my age, but I remember when us IT folks were viewed as being a stick-in-the-mud for not responding fast enough to user requests for new applications and databases ("data analysis? what the heck do you need that for?") So the users did an end run around IT and built their own stuff with phenomenally complicated Excel spreadsheets, VBA scripts, and gut-wrenchingly abhorrent Access databases. But there was nothing we could do. They got their work done. And when their applications got too big for their "super-user" to manage, we got to pick up the pieces.
Things have come a long way since the heady 1990's but it seems the dynamic is still the same. If the pace of change slows - and penalties are just another way of slowing the pace - users will find a way to do it themselves, and IT will be left holding the basket at some point. Isn't it better to find ways to give users what they want so that IT can maintain some semblance of control?
Virtualization seems to be part of the key to solving this problem - which is why I mentioned TP before. Virtualization abstracts the physical, and I think it's the physical that tends to slow IT down.
Server virtualization is getting IT out of the hole they got into by giving a server to anyone who asked for one. Maybe TP can do the same for storage.
Nigel, possibly. I guess only time will tell!
Post a Comment