The New Hotness: Software Defined Storage

One thing I love about the industry I work in is the great passion and the awesome competition for ideas that we have.

One thing I really hate about our industry is all the people who just take their existing product and then re-label it as the new hotness.  Come on people, you're better than that.

Just as Cloud before it and SDDC more recently, the term "Software Defined Storage" (SDS) has suddenly become very hot in the storage industry.  Amazingly, it turns out that almost every storage vendor ALREADY HAS a great SDS product that they've been making for years!!  WOW!  These guys are really good.

Wait, what?

Yes, that's right.  Now that SDS is hot, everyone is simply claiming that their product is already a great SDS platform (surprise!).  Sometimes they do this by simply redefining the term (see here for example).  Others just blatantly ignore the facts.  Still others do actually have really cool SDS products.

You can see the problem here.  Those not very close to the subject quickly become confused.  What does this term actually mean?  What should I do about it?  Is this something I should really care about?  This then becomes FUD (Fear, Uncertainty and Doubt) that prevents truly great products from being adopted because of all the noise.  You can see this happening with SDS on Wikipedia where they claim SDS is simply a marketing term and doesn't really have a definition or purpose.

That's really sad because SDS is actually one of the more revolutionary things to come out of the storage world I quite a while.

So, what is SDS, really?

 

Software Defined Storage (SDS) is a Storage Management Architectural Pattern that allows for the remote management and configuration of storage assets.  Because SDS is a management architecture, it is completely abstracted from the underlying hardware infrastructure.  In other words, SDS describes a “Control Plane” architecture that is separate and distinct from a “Data Plane” (or “Data Path”) architecture.  SDS is being driven by the movement of datacenter architectures to highly automated, policy driven management frameworks (such as VMware’s vCloud Suite or OpenStack).  This movement is closely related to "Cloud" and to what is sometimes referred to as "Software Defined Data Center" or SDDC.  These frameworks require highly abstracted management layers in order to isolate the Cloud Management Framework (CMF) from underlying infrastructure details and/or changes.  There are three main components to these Cloud infrastructures:  Compute, Storage and Network.  SDS is the control plane for the Storage component of cloud infrastructures.

SDS has the following mandatory attributes: 

1)      All functions must be available via a simple remoting interface.  This is normally done via a web style (SOAP, REST, etc.) interface but this is not a requirement.

2)      SDS is defined as a “Control Plane” or out of band management channel.  This is normally done via an IP based management network but this is not a requirement.  Note that SDS cannot be implemented in band by definition due to the restrictions of physical connectivity.

3)      SDS solutions must offer a single control plane (also referred to as a “control surface”).  Underlying systems can be disjoint or multi-vendor but the SDS solution must be unified to claim that it is actually a SDS solution.

4)      SDS is independent of the “Data Plane” or I/O path.  This implies that all current and future storage protocols (FCP, FCOE, iSCSI, NFS, etc.) can be driven by an SDS based interface.  However, all dependent components must also be managed by a single control plane.  For example, FCP based solutions must have a single control plane for zoning and LUN masking.

5)      SDS implies deep integration with physical storage assets and supported operating systems and hypervisors.  Being able to present, remove, backup, replicate and perform other storage operations implies a deep level of integration with the underlying physical asset and the hosts (physical or virtual) being serviced.  However, SDS does not specify how this is performed.  SDS is not synonymous with virtualized storage.

 

It is important to note that SDS is not synonymous with cloud nor is a SDS compliant platform required in cloud scale architectures.  However, SDS does provide many of the storage abstractions required by these types of architectures.  Also, SDS is not synonymous with “Virtualized Storage” which is also commonly associated with cloud scale architectures.

It is important to note that abstraction and “virtualization” of Data Plane constructs (LUNs, iSCSI, Storage Aggregation Layers, Storage "Hypervisors," etc.) is separate from but related to control plane constructs.  Innovations such as auto-tiering, Flash based cache, de-duplication, virtual storage controllers, software based arrays, etc. are all concentrated in the data plane.  Each of these provides opportunities for SDS innovation via the control plane but they, themselves, are not directly related to SDS nor is SDS dependent on any one of these data plane technologies or architectural models.

Anyone care to offer a different definition?  Let's get it on!