The other day, I was involved in a twitter interchange (Twinterchange?) with some friends Scott Lowe (@Scott_Lowe ) David Robertson (@Daverdfw ) Christopher Kusek ( @cxi ) and Derek Glover ( @Revolize ) which basically had Scott speaking of the amophic and undefined nature of what Software Defined Storage (SDS) has in the marketplace, to whit I responded that @PernixData and @Nexenta had some answer to that.

Scott’s statement, though a bit of a challenge to those in the field, and maybe a little incendiary, was nonetheless not entirely inaccurate. There’s an element of “Marketecture” to this label. In much the same way as “Cloud” “AAS” and all the other marketing names, the name comes first, as the market moves toward the goal. I don’t actually believe that we’ve achieved what the goal is in terms of SDS.

So let’s start with Software Defined Networking. Who really has it? What is it? Why do we want it? And where would it benefit the field? In the simplest terms, SDN is a software control layer that sits on top of the physical layer of networking components that would allow the management of these assets at a granular level giving some or potentially all of the tools that may reside in the switch. VLan Tagging, trunking, etc. can be done at the physical switch, and with the SDN layer can now be done within the virtual infrastructure. These things can all be managed with the right software tools within the software layer. This seemed to reach a culmination when Nicera was purchased by VMware roughly a year ago, but that was only the beginning. It’s anticipated that large organizations in the traditional networking space, like Juniper and Cisco are working on vast SDN tools to add to their more traditional physical offerings.

By extending the physical tools into the virtual space, we offer up a set of options to a new set of management personnel, a new set of challenges, and maybe a new set of opportunities. The traditional embedded switch guys may freak out. They don’t want to let go of their catalysts, or Nexus’s. They’re afraid of the loss of control, and they’re concerned that there may be security flaws. In some cases, there may be. The truth is, security is an issue. Anything poorly implemented whether it’s software or hardware is potentially flawed. But, not necessarily, is SDN by anyone’s particular implementation flawed.

I also want to credit my colleague Vaughn Stewart, from NetApp with the following definition in his recent posting: “As a pillar in the SDDC stack, Software Defined Storage (SDS) allows the pooling of hardware storage resources and allows them to be programmatically defined in software. This design provides the means to storage service to be provisioned and consumed based on policy and to be deployed on a wide range of hardware spanning vendor optimized to commodity to cloud.”

So, about SDS, and in full disclosure, I work for Nexenta, from whom I believe has a fairly well defined approach to SDS. This post, from founder Evan Powell, launching the title SDS, I believe was the first to attempt to define what the industry was hoping to move towards with what Scott referred to as amorphous in terms of this distinguishment: http://blog.nexenta.com/blog/bid/230748/Software-defined-Storage-from-Nexenta-Evan-Powell-Nexenta-CEO . I believe that the key here is that no matter what kind of Software Defined infrastructure you look towards, it needs to sit on a hardware infra. There is a detachment, though, that removes the reliance on the boundaries that forces the structure to physically sit on top of any one entity at any one point. Much like vMotion/Storage vMotion, and clouded workloads allow these components to migrate dynamically, these “Software Defined” entities will ultimately grant the administrator the capacity to migrate profiles, orchestrate, extend and elevate the capacities of the physical layer into the virtualization layer, or in my thinking “Above” the physical layer into the software.

VMware has jumped into this by purchasing Virsto, in an attempt to go northbound to get into this arena. Again, while we aren’t sure what this means, one can only speculate, that the goal is to have the hypervisor manage the storage, or have a panel within the console in a similar manner to what Tintri has been doing (also with many folks who’ve come from VMware, in an effort to bind a software based element to the storage.

One of the startups most intriguing to me is PernixData. I have yet to see anything specific, as they’re very much in stealth mode, but some of the key bloggers in the industry, Duncan Epping, Frank Denneman, and Cormac Hogan have all written about them, with key principals coming also from VMware, have what appears to be a hypervisor based IO-Management which seems to be completely Software-Defined. To me, this brings a very much solution_based answer to Scott’s open ended question.

And, to be sure, I’m not nearly updated to what EMC will be offering on the not as-of-yet released Project Viper.

This is an interesting space, and a great time to be in the industry. This newly created Software Defined element is growing, and yet one component of the Software Defined Data Center (SDDC). Keep your eyes open, because this is a dynamic space.

I will be following this post up soon with another post soon, as there is more to be said on the subject. There’s maturation taking place in the space as well.