A couple days ago StorageBod called out the enterprise storage industry for its lack of better (SRM) management tools. I have to give him credit, he is stirring the pot like few others these days with thought-provoking dialgoue.
Lack
of comprehensive storage management is a big problem for vendors
as well as customers. It costs customers a lot of money for skills and
services, but it also costs the industry a lot in development resources
that are spent recreating the wheel in their own proprietary products.
Of course, the situation is complicated by the fact that storage companies are in
the business to succeed. Yes, those of us who work for vendors want to
see our businesses grow so we can continue to buy Syncmobiles, steering wheel cams, insurance, bandages, food and the like. This urge to have a successful business
doesn't mean we are being particularly greedy - companies tend to price
products to optimize their business models and there are several
different business models in storage right now.
Tolerances are small where enterprise
storage is concerned and the number of ways things can go wrong is mind boggling. Not
only do we have to make products that are as error free as possible,
but we are also expected to make products that humans can't screw up
too badly - and we all have our favorite stupid human stories. Should a storage
company be responsible for creating an API that allows somebody to take
a darwinian-awarded action? Many customers would say - "hell yes, I
never asked for that loaded gun" OK, but many others may have been
begging for it. As Chris Evans
and others have suggested, the API approach is probably the best way to
get where we want to go in storage management. There are lots of
ways API implementations can go wrong too and the responsibility for testing is up for grabs. Vendors try try to provide a reasonable amount of testing, but
at the end of the day customers have to be responsible for their
storage management cocktail - which isn't necessarily news to
many.
Software
development is expensive and takes a lot of time. You try to
make the best decisions you can with respect to development resources. Storage companies
are not eager to waste development resources on initiatives that don't
work out. Many companies tried making SMI-S work and its been a disappointment to a lot of people:
vendors and customers alike, but I don't think it was for lack of
trying - it was because the project was/is too large. I honestly don't
know that it could have been done better. There were/are very good
developers working on it and it was not a token effort.
I
don't use ECC and don't pretend to know much about it and don't really
want to say much about it other than this: I bet it cost EMC a TON of
money and resources to develop it. Whatever shortcomings people may
assign to ECC, I doubt they resulted from a lack of effort. So let's
assume for a minute that EMC had decided to attempt this effort by
enjoining other storage companies and their engineers to help the effort -
do you think it would have ever been finished and do you think it would
have cost less or worked any better? I don't see anything but black
fog at the end of THAT tunnel.
Then there is the matter of
intellectual property. There is nothing quite as stupid in the
technology business as opening your design secrets to others. That may be a beautiful vision for
open source software but it is THE OFF RAMP TO NOWHERE for companies
that are in hotly competitive markets, such as storage. Does anybody else remember how well it worked out for Brocade (and Cisco) six years ago?
The problems aren't all in the vendor sector - customers bear some of the burden in all this too. If you were to take 3 customers and put them in a room telling them they can't come out until they agree on their top 3 storage management priorities, there is a good chance they would starve to death first. Of course, who has time for THAT??? That's not to say customers are somehow "at fault" for not having the same requirements, but getting some agreement on priorities and enforcing buying criteria based on them is extremely powerful. SMI-S would have been more successful if customers had forced the issue.
* * * * * * * * * * * *
So, I put myself on the hook in a comment on S-Bod's blog to say more about 3PAR's storage management stuff - and here it is: We support SMI-S and have a CLI that people
can use in scripts. We also have a comprehensive metering/reporting tool called
System Reporter that only works with 3PAR arrays that assembles historical data for all components in the system (GUI and Excel interfaces only). We do not have any multi-vendor management products and are unlikely to develop any. We are working on ways to extend the management of our systems through APIs, such as the recently announced Thin Reclamation API from Symantec.