Strange Fascination With Aperi

Open source, and a little chutzpah, are just what storage management needs

November 3, 2005

8 Min Read
Network Computing logo

Ch-ch-ch-changes, as David Bowie once crooned, are a part of life. This column has run for the past two years on Storage Pipeline, now merged with Byte and Switch. Editor in Chief Terry Sweeney asked me to come along for the ride, and Terry's a pretty persuasive guy and a skilled editor, so I agreed. I would like to encourage my regular readers to make the transition with me and to be just as aggressive in your responses to my opinions here as you were at Storage Pipeline.Figure 1:

Bowie's song maps extraordinarily well to the situation that exists in the world of distributed storage management today, especially given the news from IBM that it is founding an open source initiative called Aperi to fix the world of storage management. Such an idea holds enormous promise, and we are cautiously hopeful that IBM with its cadre of fellow travelers that includes most notably, Computer Associates, will make it happen.

To contextualize the importance of Aperi, first you need a bit of background on how we have arrived at the problems we confront today in storage management. In the song, Changes, Bowie bemoans that "running wild" took him down "a million dead-end streets," but ultimately failed to deliver a "sweet taste" of success. And so it is with contemporary storage management in distributed systems. Customers have long awaited an integrated solution for administering heterogenous storage gear and to make fewer workers more productive. We are still waiting.

There have been a lot of dead-end streets in storage management. First, customers were provided with "point" software tools for managing discrete products from specific vendors. This was a very inefficient management strategy (a non-strategy, in fact) that required each administrator to master a growing set of frequently changing software utilities. It was not always easy to know the right tool for the job, and transferring knowledge to new hires required the skills and patience of a Jedi master.Next came an onslaught of "hardware-agnostic" storage resource management software products from something like 270 vendors. To a one, they were only as effective as their creators were at gaining access to the proprietary APIs and MIBs of the hardware guys. With more than 11,000 new hardware products introduced each year, there were inevitable gaps in the coverage provided by these packages. Moreover, the desire of many vendors, most notably Veritas, to deliver "suites" of software tools that would deliver their functionality across the vendor's own framework led to acquisitions of point products too often with little attention paid to integration under the covers. Many so-called integrated enterprise storage management software suites were integrated at the brochure level, but not much more.

The late 1990s saw the emergence of hardware-turned-software-vendors, which, despite their evangelism and promises of "openness," delivered management products that worked well with their own equipment but created black holes in the management of competitor gear. Truth be told, for all the hype around WideSky, Storage Tank, and other hardware vendor offerings, these products not only failed to deliver the goods for managing heterogenous storage, they set the stage for a return to a homogenous storage buy. Bottom line: If you really want to make fewer administrators capable of managing more storage, then buy it all from a single vendor.

Along the way, we saw the rise of CIM/WBEM and Storage Management Initiative-Specification (SMI-S) from the Storage Networking Industry Association (SNIA). The idea of well-intentioned backers was to create an abstraction layer that would map storage resources and processes back to the business applications that required their services. However, "co-opetition" (cooperation among competitors) proved to be an ineffective driver for delivering the Holy Grail of heterogenous storage management. In the words of a senior technologist at SNIA, "I've definitely lost any enthusiasm I ever had for SMI-S (it has wandered into the land of mindless complexity and abysmal performance). I hate to say it, but you were right. That's too bad, because an abstraction layer is desperately needed."

In light of this on-going challenge, it should come as no surprise that stovepipe solutions have begun to emerge. Hewlett-Packard has acquired AppIQ, and in so doing, bought itself a place at Hitachi Data Systems' table going forward, since HDS uses a modified version of AppIQ management tools on the bulk of its arrays. EMC has pursued its own Enterprise Control Center (ECC) product, which features uneven integration of the many software vendors that the company has been acquiring over the past three or four years. Oracle and Microsoft seem hell-bent on coopting storage management functionality directly into their wares.

Has any of this moved us any closer to real, application-facing, heterogenous storage management? The answer is simply no.In all honesty, the industry doesn't want heterogeneous storage management. The ability to manage all storage wares dumbs down marketing messages about a vendor's product differentiators. Worse yet, real heterogeneous management opens the door for a competitor's product to be placed in the same infrastructure with yours, all manageable via a single, universal pane of management glass. That is anathema to most hardware vendors we know.

Nowhere is this more clear than in the marketing campaigns around the "V" word: virtualization. When companies like Compaq, DataCore, FalconStor, and StoreAge came out with their virtualization plays in the late 90s, the hardware vendors trounced them with FUD (fear, uncertainty, and doubt) campaigns that leveraged, more than anything else, their own tenure in the market to put down the newbies with their hair-on-fire ideas and their hardware-agnostic solutions.

Then, when IBM announced its SAN Volume Controller last year, an unnamed source at EMC immediately stated that EMC LUNs could not be virtualized with an IBM product. The truth was that LUNs are a function of SCSI, not EMC, and a LUN is a LUN. Shortly afterwards, EMC unveiled its own virtualization product, Invista, which, it claimed, could virtualize all of its competitors' LUNs. As the genius glam-rocker said, the ripples change their size but never leave the stream.

Which brings us to the present, and to IBM's announcement at Storage Networking World last week, that it was forming an open-source initiative to create the Holy Grail of heterogenous storage management called Aperi. As I reviewed the announcement, it seemed to me that Big Blue was getting dangerously close to stating the obvious: The industry is not going to deliver the goods on its own. The final option is to give the open-source crowd a shot at the title.

Of course, the stovepipe vendors have been quick to criticize the idea of the maniacal hordes in the open source world mucking about with storage. Listen closely and you can hear their marketing folks and paid henchmen in the "objective" analyst world sharpening their knives. Poor EMC feels snubbed by the IBM initiative, which it was invited to join only 30 minutes before Big Blue made the announcement. Meanwhile, Symantec/Veritas has already given the idea the middle finger, wrapping itself in the flag of propriety: "IBM didn't start with a specification." HP/AppIQ has also demurred, as it has its own stovepipe approach and stack to develop.As I read it, everybody is scared. And that's because, depending on how the details are worked out, this Aperi idea might actually have legs.

Think about it. One of the key impediments to cross-platform storage management is deliberately obfuscatory stuff that array vendors have built into their products. EMC, for example, offers little visibility into the configuration and layout of its enterprise arrays except through tools that are, as a rule, available only to its own systems engineers. Users complain that they must maintain complicated spreadsheets just to keep track of storage allocation on Hopkinton arrays so that they know how much capacity they have available for use at any given time. EMC is not alone, of course; other vendors purposely erect similar barriers to universal management.

These barriers are, in large part, what makes storage resource management such a daunting task. Given a miniscule amount of funding and a little encouragement, the maniacal open-sourcers could use the wiles they have built over the years to find ways to circumvent the obstacles. Think about it: Joe writes some code that gets around a lock-out and gives you visibility into the internal workings of one vendor's arrays, which he then shares with the open source community. No longer will the storage management ISVs have to go hat in hand to every hardware vendor on the planet and beg for access to their APIs.

If this sort of "hack the planet" approach to developing a real storage management capability strikes you as unfair to hardware vendors, keep in mind that it has been a long time coming. It is in the nature of the open source community that it will beg, borrow, or invent hacks around any problems that stand in the path to success. That is exactly the chutzpah that will be required to fix storage management.

I, for one, think it is about time. Every other storage management initiative out there is either so proprietary that it will cost more than it saves by the time it is delivered to market, or it is doomed to fail by the proprietary nature of storage today.We will be watching Aperi going forward to see whether Big Blue and company remain true to the ideals expressed in its brief press announcement. It will be fascinating to see this thing unfold.

Look out, you rock-n-rollers.

— Jon William Toigo, Contributing Editor, Byte and Switch

What storage management song can't you get out of your head? Drop Toigo a line

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights