Software-defined storage is currently one of the hottest terms in the enterprise storage industry. Everyone from VMware to IBM has announced some type of software-defined storage product. It's difficult to cut through the FUD and understand what constitutes software-defined storage vs. virtualized storage or just plain old storage management software.
It's helpful to understand the basic concept of software-defined storage (SDS). In any software-defined infrastructure component, be it storage, compute or networking, the point is to establish a way to abstract the component and programmatically control it. Software-defined anything is about the ability to abstract the control plane from the underlying hardware and serve it up as a consumable service via a northbound networking interface. The consumer of the service could be an actual end user via a portal or, more likely, an application such as a cloud orchestration tool or a cloud-based application.
This API-level control allows the provisioning and teardown of the service and may include some other orchestration activity along with the potential of quality of service, or QoS, policies. You may ask "Isn't all storage controlled by software and therefore software defined?" After all, isn't the selling point of most enterprise storage the management interface? The key term in my definition is abstraction.
It's about the control plane
Abstraction is needed to decouple the service from the hardware, which allows the management of heterogeneous storage environments. This decoupling also allows applications and infrastructures to move to cloud-based storage products where the native interface to the underlying storage will not be presented. Eliminating that interface eliminates some hassle, since in many cases those can change without notice to the cloud consumer.
In the enterprise, there may be a server SAN (a collection of servers whose direct-attached storage is virtualized to form a single storage pool) for test and development and EMC's VMAX storage platform, for example, for production applications. From an orchestration perspective, the underlying storage should be abstracted to provide a consistent interface to the application. A developer who is writing a cloud application should be able to specify the class of storage along with the size of storage. Which array serves that storage request should be invisible to the application developer.
The result is one of the software-defined storage benefits: SDS gets out of the way of the data. SDS is capable of administering storage management tasks, actually providing the communication path for the data. As noted, some products play both sides of management and presentation.
SDS isn't virtualized storage
Just as software-defined networking (SDN) is different from virtualized networking, SDS is different from virtualized storage. Virtualized storage looks to actually abstract the data plane. An example of virtualized storage would be OpenFiler. Products like OpenFiler are presented with physical storage from one or more sources and present it via some storage communication protocol, such as Network File System (NFS), Common Internet File System (CIFS) or iSCSI. The virtualized storage platform injects itself into the storage path, while SDS products orchestrate the communication.
VMware's VSAN is an interesting product because it both virtualizes storage to present a target and path to share storage and has the data plane controls attributed to SDS. VSAN provides the ability to create policy-driven storage from commodity server hardware. Similarly, HP offers a "build your own array" option through its StoreVirtual platform.
Exploring the enterprise options
SDS is still a maturing market. You'd be hard-pressed to find a vendor that offers an SDS-specific program that provides control plane management across multiple vendors. EMC offers ViPR, which leverages open standards for the provisioning of storage on enterprise arrays. However, there are limitations on which actions the product can take -- even on EMC Storage. There's also limited support for non-EMC storage systems, such as products from Hitachi and NetApp.
The options expand if the use case is around a single platform such as EMC VNX, EMC VMAX, SolidFire or even VMware VSAN. Each vendor offers some type of software-defined interface for the orchestration of storage. For example, EMC offers Storage Integrator, which allows applications to provision storage via application programming interfaces (APIs) to the Storage Integrator management node. While this meets the requirement of potentially controlling the storage from orchestration software, it makes abstracting all enterprise storage a long shot. IT shops are limited by which features are exposed across multiple storage products.
On the other side of the spectrum, upstarts such as SolidFire and X-IO offer complete REpresentational State Transfer (REST) APIs for end-to-end management of their arrays. REST allows an application or orchestration product to have the same management capability as a vendor's native management console. It's this REST API approach that enables a cross-vendor program as described earlier.
Orchestration tools that can take advantage of REST APIs can be leveraged to provide a full SDS program with all of the software-defined storage benefits. An example would be VMware vCloud Automation Center (vCAC), which could use these open storage control APIs to provide storage services to cloud consumers, such as application developers.
The overall market is still pretty young, but the argument for the functionality of SDS is strong. I expect such market newcomers as SolidFire and X-IO to pressure incumbent storage providers to provide a strong set of REST APIs to either their storage management products or to the storage directly.
As storage vendors embrace REST APIs, I expect the SDS capability of both orchestration providers and cloud management programs, such as OpenStack and vCAC, to improve a lot.