We’ve had a few announcements from vendors and various roadmaps have been put past me recently; if I had one comment, it would be if I was designing an array or a storage product; I probably wouldn’t start from where most of them are….both vendors, old and new.
There appears to be a real fixation on the past; lots of architectures which are simply re-inventing what has gone before. And I although I understand why; I don’t understand why.
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 break processes and understanding. So, we 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 who want to see to continue to build yesterday’s architecture today; so we’ll build something based on a dual-head filer 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 now.
I’m going to take the second first; if I wanted to buy a dual-head filer, I’d probably buy it from the leading pack. Certainly if I’m a big storage customer; it is 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 but you almost certainly will 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 utilisng 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? Although it is probably the really big customers who do so but they might well be the ones who will look at leveraging new technology without a translation layer.
So if I was a vendor; I would be looking at ways to make my storage ‘plug compatible’ with what has gone before but under the covers, 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 that I could stick personalities over.
And it’s not just about a common look and feel for the GUI; it has to be for the CLI and the APIs as well.
Make the change easy…reduce the friction…
[…] us to break with the past. In fact what I am going to suggest almost negates my previous blog entry here but not […]