Is SMI-S "Done"?
The blog-o-sphere has been abuzz of late with postings claiming that SMI-S is dead, or dying. The claim being that the standard API/protocol has not fully replaced the need for proprietary ones. As if any management standard ever did. Perhaps if we all stopped adding features to our products, the standard could finally catch up ;-) You really can't compare management standards to to protocols such as TCP/IP and HTTP, where there is a strong bias *against* adding features (witness IPv6).
All these issues are hot topics within the standards organizations such as the SNIA and DMTF as well. Eight years later, the scope of resources that are able to be managed via a single protocol and common model has grown dramatically. The set of tools, mostly open source, to create solutions in this space is very impressive. What puzzles me is why anyone would re-invent all this infrastructure from scratch?
Mostly, the use of proprietary protocols and APIs is historic. They came first. SMI-S, like any other "check box" feature gets thought about later in the development. Because the vendors don't see it as "strategic", they only implement the minimum to pass the certification tests.
Once this gets established in a product line, it's difficult to switch things around, but there really is no excuse anymore to start a new product line with a proprietary API as the "primary" means of managing a resource. The standards can easily be extended to cover the whole functionality of any given product. By leveraging SNIA and DMTF profiles and protocols as the primary interface, the implementation becomes rich and robust because there is no other interface.
Some vendors do this today, but you'd never know it. What needs to happen is to have this become a differentiator between products, and get customers to ask for vendors to provide the full functionality through the standard-based interface. We really don't need to standardize any more features in order for this to take place. It's more of a messaging problem than a technical one.
SMI-S may never be "Done" as long as we keep innovating in the storage space, and other implementations drive a need for a common way to manage those features, but who cares? It's certainly complete enough to be the primary interface into your next storage purchase, if you call the vendor on it.
Mark - what you say makes a lot of sense. The question I have is why haven't the customers demanded full SMI-S functionality from their storage provider(s) up to now? It is certainly something that the storage providers could make available to their customers if their customers demanded it!
Posted by Phil Mills on December 07, 2008 at 06:43 PM MST #
Maybe this is something the SNIA can help message and get across to customers. But there is nothing preventing any vendor from promoting the idea as a differentiator now, if they already have taken this approach.
Posted by Mark on December 07, 2008 at 07:42 PM MST #
Great post Mark. The issues I notice is not with the SNIA’s SMI-S specifically, but more with vendor commitment, implementation, quality and ease of use. Here is what I’ve seen from my experiences…
Vendor SMI-S Commitment Bucket:
1. Vendors that truly commit to the SMI-S and always follow CTP. They make client development and implementations quick and painless. All vendor extensions documented. Thanks!
2. Implemented SMI-S but have ‘not’ stayed involved and current to SMI-S. Not necessarily any fault, they may have reached a comfort level where there initial implementation(s) work.
3. Implemented SMI-S and have a proprietary API. They were/are merely looking for the mark or seal, more of a marketing effort. These vendors do not care about extending their implementation(s) because they are probably not using it internally nor do they feel it adds value from a strategic perspective.
Vendor SMI-S Agent Installation and Configuration Bucket
1. Full robust proxy SMI-S agent installation packaging. Minimal knowledge of SMI-S configuration needed. Vendor has package available for download with documentation. If embedded, documentation on how to enable. Thanks!
2. Proxy agent installation packaging. Knowledge of SMI-S is required for configuration. Documentation lacks.
3. Agent extremely difficult for anyone to install and/or enable but at least you can find it for download or work your way through enabling.
4. The vendor(s) has an SMI-S agent but you cannot find it or the vendor(s) does not provide it unless you’re a strategic partner and/or upgrade and pay $xxxxx.xx.
What SNIA does do well is provide a comprehensive specification that allows vendors a documented means to implement a standards solution to monitor and provision a system. Looking back on my experience, I would say standards in general are slow. My hat is off to everyone that helped develop, write and contribute to this spec. During the inception of this specification, there should also have been general CLIs and SDKs that were being developed and managed by SNIA. Alongside provider CTP there should have been client testing from the start. Perhaps more of a circular development/test lifecycle: New SMI-S version-->SMI-S Provider Testing-->Client Testing.
I would also suggest making your issues known, http://groups.google.com/group/smi-s-developers-group.
Posted by Kurt Krems on December 09, 2008 at 05:31 PM MST #