Storagebod Rotating Header Image

Viperidae – not that venomous?

There’s a lot of discussion about what ViPR is and what it isn’t; how much of this confusion is deliberate and how much is simply the normal of fog of war which pervades the storage industry is debateable. Having had some more time to think about it; I have some more thoughts and questions.

Firstly, it is a messy announcement; there’s a hotch-potch of products here, utilising IP from acquisitions and from internal EMC initiatives. There’s also an attempt to build a new narrative which doesn’t seem to work; perhaps it worked better when put into the context of an EMC World event but not so much from the outside.

And quite simply, I don’t see anything breathtaking or awe-inspiring but perhaps I’m just hard to impress these days?

But I think there are some good ideas here.

ViPR as a tool to improve storage management and turn it into something which is automatable is a pretty good idea. But we’ve had the ability to script much of this for many years; the problem has always been that every vendor has some different way of doing this, syntax and tools are different and often not internally consistent between themselves.

Building pools of capability and service; calling it a virtual array…that’s a good idea but nothing special. If ViPR can have virtual arrays which federate and span multiple arrays; moving workloads around within the virtual array, maintaining consistency groups and the like across arrays from different vendors; now that’d be something special. But that would almost certainly put you into the data-path and you end up building a more traditional storage virtualisation device.

Taking an approach where the management of array is abstracted and presented in a consistent manner; this is not storage virtualisation, perhaps it is storage management virtualisation?

EMC have made a big deal about the API being open and that anyone will be able to implement plug-ins for it; any vendor should be able to produce a plug-in which will allow ViPR to ‘manage’ their array.

I really like the idea that this also presents a consistent API to the ‘user’; allowing the user to not care about what the storage vendor is at the other end; they just ask for disk from a particular pool and off it goes. This should be able to be done from an application, a web-front-end or anything else which interacts with an API.

So ViPR becomes basically a translation layer.

Now, I wonder how EMC will react to someone producing their own clean-room implementation of the ViPR API? If someone does a Eucalyptus to them? Will they welcome it? Will they start messing around with the API? I am not talking about plug-ins here, I am talking about a ViPR-compatible service-broker.

On more practical things, I am also interested on how ViPR will be licensed? A capacity based model? A service based model? Number of devices?

What I am not currently seeing is something which looks especially evil! People talk about lock-in? Okay, if you write a lot of ViPR based automation and provisioning, you are going to be kind of locked-in but I don’t see anything that stops your arrays working if you take ViPR out. As far as I can see, you could still administer your arrays in the normal fashion?

But that in itself could be a problem; how does ViPR keep itself up to date with the current state of a storage estate? What if your storage guys try to manage both via ViPR and the more traditional array management tools?

Do we again end up with the horrible situation where the actual state of an environment is not reflected in the centralised tool.

I know EMC will not thank me for trying to categorise ViPR as just another storage management tool ‘headache’ and I am sure there is more to it. I’m sure that there will be someone along to brief me soon.

And I am pretty positive about what they are trying to do. I think the vitriol and FUD being thrown at it is out of all proportion but then again, so was the announcement.

Yes, I know have ignored the Object on File or File on Object part of the announcement. I’ll get onto that in a later post.

 

 


3 Comments

  1. John Martin says:

    I’ve not had a chance to look at the API, but I have immense respect for EMC’s engineering organisation so I would expect them to have put some serious thought into it. And even though I work for NetApp I hope it is sufficiently open elegant and extensible to form the basis of a solid open standard, because that would be good for customers and the industry as a whole.

    Having said that, if the long term plan is for this to be something that becomes a defacto industry standard, then I wish they’d done this as an extension to CDMI or Cinder or had simultaneously released the API to a standards body like SNIA. They still would have had commercial benefit from first mover advantage, a reference platform and the ability to influence future direction, but as it stands, from a cynical competetive vendor point of view, this is looking a heck of a lot like Invista 2.0

  2. It’s funny….I don’t see it like Invista at all. I loathed Invista, I thought it was a terrible product.

    But I know what you mean about a simultaneous release to SNIA but actually we live in a world where de-facto standards often work as well as those regulated by the standards bodies.

    At times, it is better for someone to just do something as opposed to getting a committee to talk about doing something. If EMC play nice and I will admit that is a big IF; this could be win for customers and potentially the industry as a whole.

    So when will SanScreen talk to ViPR? I see a lot of synergies there…if NetApp had announced ViPR with SanScreen; you’d have been jumping up and down. But you could build your own ViPR-like broker and put a SanScreen type product in front..it’s a thought.

  3. […] Viperidae – not that venomous? (via StorageBod) […]

Leave a Reply to Martin Glassborow Cancel reply

Your email address will not be published. Required fields are marked *