This article is more than 1 year old
How to design a storage array: NOT LIKE THAT, buddy
Architecture might all look samey, but it's like that for a reason
Storagebod We’ve had a few announcements from vendors recently and I've seen all manner of storage roadmaps. If I had one comment to make on all of these, it would be to say that if I were to design an array or a storage product, I probably wouldn’t start from where most of these guys are starting.
There appears to be a real fixation on the past, with lots of architectures which are simply re-inventing what has gone before. And although I understand why, I don’t understand why. Stick with me here.
Let’s take the legacy vendors. You can’t change things because you will break everything: you will break the existing customer scripts and legacy automation, you will break processes and understanding. So essentially, the vendor can’t build a new architecture because it breaks everything.
I get the argument, but I don’t necessarily agree with the result.
And then we have the new kids on the block, which want to continue building yesterday’s architecture today. “We’ll build something based on a dual-head filer,” they say, “because everyone knows how to do that and they understand the architecture.”
Yet again: I get the argument but I really don’t agree with the result.
I’m going to take the new vendors' situation first. If I wished to buy a dual-head filer, I’d probably buy it from one of the leaders of the pack. Certainly if I were a big storage customer, it would be very hard for one of the new vendors get it down to a price that is attractive.
Now, you may argue that your new kit is so much better than the legacy vendors that it is worth the extra hassle, but you will almost certainly break my automation and existing processes. Is it really worth that level of disruption?
The first situation with the legacy vendors is more interesting. Can I take the new product and make it feel like the old stuff from a management point of view? If storage is truly software (and the management layer is certainly software), I don’t see that it should be beyond the wit of developers to make your new architecture feel like the old stuff.
Okay, you might strip out some of the old legacy constructs. You might even fake them ... so if a script creates a LUN utilising a legacy construct, you just fake the responses.
There are some more interesting issues around performance and monitoring, but as a whole, the industry is so very poor at it. Breaking this is not such a major issue.
Capacity planning and management: well, how many people really do this? The really big customers likely do it, but they might well be the ones who will look at leveraging new technology without a translation layer.
So if I were a vendor, I would be looking at ways to make my storage “plug-compatible” with what has gone before – but under the covers, so to speak. I’d be looking for ways to do it a whole lot better and I wouldn’t be afraid to upset some of my legacy engineering teams. I’d build a platform on top of which I could stick "personalities".
And it’s not just about a common look and feel for the GUI, I'd engineer the same for the CLI and the APIs.
My advice to the new kids: make the change easy by reducing the friction. ®