The time for Storage Blades.
I’m writing this blog from the El Dorado Resort in the Riviera Maya Mexico while sipping some sort of Frozen Blue Hawaiian cocktail, so my life at the moment doesn’t suck. When most people are catching up on the latest Twilight novel, or Andre Agassi’s biography, I’m flipping through whitepapers and tech docs I’ve been printing out for the last few weeks. For those of you that do a great job of “unhooking” from work during vacations, I applaud you.
I was reading through a few things, and it’s becoming clear to me that the industry is at a crossroads. I liken this to the same situation the server vendors went through just 6 or 7 years ago with the deployment of server blade technology. I recall talking with a large independent school district in West Texas back then about connecting the new IBM BladeCenter with our Magnitude 3D solution. The BladeCenter was a new thing, and this customer was searching for an ability to reduce rack space as well as cost predictability when deploying future applications. Since then, blade servers have proliferated to the point that they’re typically the server of choice for deploying server hardware. Virtual servers have taken this to another level. It’s not uncommon for companies to fully understand the number of virtual machines a certain model Blade can support and buy different types of blades based on those requirements.
I think the storage industry is at this pivot point as well. We can accurately tell you within a few GB’s the capacity predictability of a solution we quote, so why is it that we have a difficult time being that predictable with performance? We still get speechless when customers ask what sort of performance predictability can I expect today, in 1 year, in 3 years and in 5 years. This is going to become MORE important as virtual desktops and other IOP-hogging applications become more mainstream. I’ve stopped being surprised when talking with channel partners as they recite problems when they deployed a certain storage vendor’s solution and they find out 3 months later it was undersized. Een though according to the vendor’s tools, it was sized according to the vendor’s best practice, and the customer still runs into performance issues as they ramp up the use of the solution. What’s even more surprising is the storage vendor’s near-giddy response when telling them how they can solve this issue. SSD anyone? Can you spare a few tens of thousands of dollars after you’ve already blown your budget on the acquisition to purchase 2 SSD drives? Just to solve a performance issue?
Maybe it’s time for the storage industry to look at Storage Blades as a means to meet this performance/capacity predictability paradigm. Imagine looking at storage as a building block for an overall storage strategy that allows you to be predictable in both capacity and performance so your sizing of application deployment becomes easier and more cost effective. Imagine knowing the dollars per IOP per Rack Unit on the life of the storage blade? In other words, you can expect X IOPS per RACK Unit for the 5 year life expectancy of the storage solution. Imagine being able to do this knowing that the predictability is based on running the storage solutions at 97% utilized This begins to put you on par with the capacity planning you’ve grown accustomed to knowing.
I believe that Storage Blade architecture has the ability to bring the storage industry to a crossroads. Do we continue piling on features and functions, already found in typical applications and OS’s, and live with horrible utilization rates and the inability to predict basic performance results? Or should we stop this controller feature crawl and hit the big issues at hand: cost, capacity and performance predictability? Storage Blades, like their server brethren, can possibly be the means to this end. If nothing more, for certain applications, Storage Blades just make perfect sense.
Oh well – I just saw someone order a Frozen Mojito that looks really good. Back to the grind that is my vacation 🙂