There was a time at the height of my home video and audio craze that the number of devices I needed to watch a movie could no longer be counted on one hand. Amplifier, preamplifier, tuner, CD player, DVD player, TV, cable box . . .you get the idea. As I organized my vast array of remote controls on the coffee table, I was blissfully unaware of any issues. That was the case until my wife just wanted to watch a movie one night while I was gone, and she had a conniption fit trying to figure everything out. There was no way she was going to invest the time to learn what to power up, and what should connect to where to deliver a given entertainment “service.” I was in trouble. I either had to give up all of my beloved technical goodies, or pull the old single button TV set out of the basement.

The answer to this particular problem was to use a third party remote control that abstracted all the audio and video equipment, and more importantly, the services such as “watching a DVD.” We could now enter a single button that turned on the appropriate gear and made all the required settings and connections. The desired service would appear on the monitor screen. My entertainment center was now “virtualized.”

Now enterprise storage needs to be far more flexible and diverse than my audio & video system. Data is growing at rates that defy common adjectives, and is being created and viewed by a wider range of applications and devices. To meet this information demand, an ever-expanding plethora of storage products, technologies, protocols, APIs, and data types are now available. The enhanced flexibility puts more tools into one’s belt, but this increases both the complexity and potential for waste. A given storage solution used for one application may be underutilized while other applications are starving for capacity.

There are unique storage types (server side PCIe flash, all flash array, hybrid, traditional disk storage, physical and virtual tape), data transport vehicles (fibre channel, Ethernet, InfiniBand), data types (object, block, file), and access protocols (iSCSI, NFS, CIFS, REST). Additionally, there are different storage services, for example, deduplication, replication, snapshots, security, and performance. How these services are delivered can vary from vendor to vendor. Finally, there are multiple management and administration interfaces one must contend with, not unlike my large collection of remotes needed to watch a movie. The net result is that the OPEX costs are climbing much faster than the CAPEX costs. If the true power of data is to be effectively utilized while not breaking the bank, a new way to acquire, provision, and manage storage is needed.

Server virtualization has been implemented in most enterprise sites, and network virtualization has been growing rapidly. Storage virtualization helps simplify storage administration by abstracting the physical resources so that capacity is more easily provisioned and managed. However, storage virtualization does not abstract and provision a key resource: services. This leads us to one of the hottest topics in storage: software defined storage, or SDS. The theory of SDS is to abstract all elements of storage, including services. This enables silos of storage that were previously underutilized by single applications to be consolidated into a common pool for distribution.

SDS is new enough that there are multiple definitions, especially across multiple vendors. A couple of key macro level capabilities should include policy-based storage provisioning (capacity and performance), central management, a common set of data services across the pool, and heterogonous storage support. The need for heterogonous support may be questioned by some, but for SDS to be truly effective, removing vendor lock-in and being able to use existing infrastructure is key. Research on IT and application user requirements that are driving SDS is needed so that users are aware of what to look for in competing solutions.

Look for more on this topic in the future. If you have strong opinions or ideas on what should be included in this research, please feel free to contact me at jmiller@emausa, @jmillerema, or 303-543-9500.