Recently, it has felt like my entire professional existence has been co-opted by buzzwords and marketing. This is due to a push by seemingly every vendor to establish themselves as leaders implementing emerging technologies. As an industry, we run around spinning … rephrasing … claiming … in an attempt to be named a leader in a given quadrant, and other such nonsense. While at first these activities are fair and needed to highlight innovation, over time they move from the productive discussion of emerging trends to pure unadulterated marketing.
In my opinion this is where we find ourselves today with SDS.
For the uninitiated, “Software-Defined Storage” emerged shortly after Software-Defined Networking, establishing itself as a real thing. Given the success and momentum of SDN, a new movement emerged. Whether you call it the Software-Defined Datacenter (SDDC), Software-Defined Infrastructure (SDI), or the Datacenter Abstraction Layer (DAL), ultimately we’re talking about the same thing. Handily, you can currently identify which ecosystem someone is most familiar with or supports by which phrase is used. At its heart, all this Software-Defined stuff really comes down to is … management.
In order to lower the TCO of running a modern infrastructure, the infrastructure must be inherently more manageable. This means rich API support and preferably standards-based interfaces and platforms to improve the admin-to-infrastructure ratio.
The idea is simple …
If a given product can only be administered through a GUI or CLI, then it is difficult to integrate that component with the rest of the datacenter without either producing one-off integration in-house, or purchasing specialized tooling. In a Software-Defined world, it is easy to integrate disparate systems into a common management platform.
With me so far? Let’s stay on this track …
Manageability is the engine powering the entire Software-Defined movement. However, like any other emerging technology, the vendor “land grab” has left the majority of our user base confused and fractured. We are attempting to have a meaningful discussion around the value of these new methodologies whilst not properly defining what the terms being used actually mean. This is to be expected. Just glance at any Flash conversation and you’ll inevitably see someone bring up Phase-Change Memory… even though it’s not flash. (Hint: It’s non-volative RAM.)
The point here is to reiterate that words matter. Until that is true, it is impossible to fully advance our industry and really move the needle for our collective customers.
This, my friend, is why standards bodies exist!
This is the problem they solve! They provide the necessary abstraction between vendors to allow new terms to be defined, and thus wholly understood and accepted. They also act as a sort of beacon as to when a concept or idea moves from quaint to primetime, and are called in when innovation and progress begin to loose out to buzzwords and FUD.
Recently the Storage Networking Industry Association (SNIA) assembled a working group of industry veterans from EMC, Evaluator Group, HP, Huawei, IBM, NetApp, and Toshiba to finally sit down and define what SDS is and is not. The result of this effort was a Draft definition that went out for review in December, and was recently ratified!
Why does this matter?
Well now when someone starts to declare that Solution XYZ from Vendor A isn’t really SDS, we have a common definition to work from. Meaning … we can establish common language and make actual progress, instead of bickering amongst ourselves.
Per the SNIA definition, SDS is:
“Virtualized storage with a service management interface. SDS includes pools of storage with data service characteristics that may be applied to meet the requirements specified through the service management interface.”
SNIA goes on to list the attributes of SDS:
- Automation – Simplified management that reduces the cost of maintaining the storage infrastructure.
- Standard Interfaces – APIs for the management, provisioning and maintenance of storage devices and services.
- Virtualized Data Path – Block, File and Object interfaces that support applications written to these interfaces.
- Scalability – Seamless ability to scale the storage infrastructure without disruption to the specified availability or performance (e.g. QoS and SLA settings).
- Transparency (self-service) – The ability for storage consumers to monitor and manage their own storage consumption against available resources and costs.
- Scale-Out – Ability to seamlessly distribute the storage services horizontally. May allow for the building of the storage and data services “solution” incrementally.
- Resource-Pooling – Should include the pooling of storage and other resources.
- Commodity Hardware – Allow customers to “build it themselves,” providing their own commodity hardware to create a solution with the provided software.
- Specialized Hardware – May work with either arbitrary hardware or may also enhance the existing functions of specialized hardware.
- Resource Metering – May allow storage and data service owners to do cost recuperation via a chargeback model based on the authenticated storage consumer.
I’m almost certain that as you read that list you’re thinking to yourself …
“Wait! That’s not right! It’s missing <insert-feature-vendor-has-told-you-is-mandatory>!!!”
Given the current landscape of our industry, I would be surprised if that did not occur. However in this case I think they darn near nailed it. It’s not perfect, but it get’s all the important stuff right.
For instance, they call out that …
A SDS solution must have the ability to fully automate the complete storage stack.
They would prefer the automation be completed using a standard management interface (SMI-S/Cinder). However, they will recognize legacy methods so long as the solution implements APIs for all aspects of storage management.
This is the heart of SDS.
They also acknowledge the need to operate in a self-service, cloud-first world, mandating non-disruptive scalability, in addition to a fully virtualized or abstracted data path.
What they do NOT mandate, but agree are common elements of a SDS solution, are all the things we’re fighting over these days.
Commodity hardware vs specialized hardware.
Chargeback resource metering.
I think this was wise. These are still hotly contested and thus not proven elements. For instance, there are valid SDS configurations using both commodity hardware and specialized hardware, in some cases it’s even the same storage solution. Given the fact that we have valid examples of both, these elements cannot be made mandatory features. That is not to say they are not important. It’s just to say they are not required to operate the storage system in a SDS model.
Personally, I don’t think the definition is perfect. It is a good compromise though, and I believe they got all the big stuff right. I’m not going to drill too much further into the definition, as it’s publicly available here. But, before I let you go, I wanted to address one more potential issue…
There are already definitions of SDS, right?! I mean … who died and made SNIA God?! No one. There are multiple definitions, and I’m sure most vendors will still continue to define SDS however they feel like, or more likely how it would most benefit their specific product/solution/implementation. However, I would point out that SNIA is as legit as they come, and this is totally within both their charter and area of expertise. If you’re reading this and thinking …
“Pft! Yea but those storage guys don’t know anything about the new SDS solutions like VSAN!”
On the contrary, these guys eat, sleep, and breathe storage! They understand what elements actually matter and which do not. The purpose of SDS is to make the storage infrastructure more agile, thereby allowing it to keep up with its SDN and SDDC siblings.
While there is a long list of features that most vendors will try and glop onto the list defined by SNIA, I believe SNIA did the right thing. And guess what… Almost EVERYTHING is SDS these days! It’s not unique. The manageability of traditional Frame Arrays, Unified Storage, Commodity Storage, and Converged Storage is the same from the perspective of the Software-Defined Datacenter. There are major differences in Power, Space, Cooling, Opex, Capex, etc, etc, Ad nauseam. However, I’m hard pressed to think of something that isn’t capable of supporting SDS.
Therefore, I would like for all of us to just stop talking about it. Seriously, everyone has it. Rebranding your product line to “Software-Defined” is just silly, and trying to declare that your platform is the only way to support this operations model is a red herring. Whether you use an existing interface, a standards-based approach, or custom/proprietary integration, as long as the storage can be managed as an element of the larger infrastructure, it is then indeed …