The initial Aperi storage system management code is ready to be used but is anybody actually going to do anything with it?
The Eclipse web site states; "The Aperi initial code contribution has been approved by the Eclipse Foundation legal team and is now publicly available under the EPL license for download." Storage vendors can get the code and then develop their storage management facilities in its framework. NetApp's Jay Kidd, in charge of emerging technologies activities, wonders who is actually going to use it?
He reckons most storage system management products make it easy for other products to view what is going on in the storage devices/software under control; the view APIs, but make it harder to control what's going on, the control APIs.
My take on this is say, suppose an Aperi member, like Brocade, wants to make its Aperi product look after HDS TagmaStore devices. HDS isn't in Aperi. Then it would be relatively easy for the Brocade Aperi product to find out the status of those devices but hard for it to get those devices to actually do something.
HDS, EMC, NetApp, Symantec, Sun, Qlogic, HP ... the number of storage suppliers not in Aperi has to exceed in market and customer coverage the ones inside Aperi: Brocade/McData, CA, Cisco, Emulex, Fujitsu, IBM, LSI Logic, NetApp and Novell.
Kidd said: "Aperi will be a very good idea. Its adoption has been a little slow. EMC has said it's not going to invest in Aperi. We'll work with Aperi but others need to work on it to make it worthwhile."
That's the kicker. The anti-Aperi group members won't invest. Will Aperi group members?
NetApp and every other storage supplier knows that a heterogeneous storage monitor at this stage of events is a wished-for feature and not a product. So do we all.
In effect, vendor's storage management products have open view APIs and closed or private control APIs. Even if Aperi members do produce fully-featured Aperi-compliant storage management products, meaning open view and control APIs, the non-Aperi members will not, and heterogeneous storage management will recede into the future like a mirage in front of a desert traveler.
It might be that the Aperi exercise is a time-wasting diversion. Alternatively it would be better for customers if Aperi group members did produce a heterogeneous storage management product that worked with Aperi group member's products even if the great unwashed remained outside. Half a loaf is better than none.
What is the point of the SNIA if, in the storage management sphere, it cannot get vendors to co-operate and produce storage management products that storage customers want? At the moment HP's Storage Essentials looks like the leading storage system management product because HP is putting resources behind it and the AppIQ team produced a great initial product. Whether Storage Essentials can overcome the control API inertia facing it though, that is the question.
For now we may as well come out with it and say that, like Monty Python's Norwegian parrot, Aperi is stalled if not dead.
Despite group members' assertions that this still-looking, non-moving, non-breathing, silent creature is actually alive and well, the opposite view says that the Eclipse Foundation project is actually only a nail holding the dead beast upright on its perch.