Needless to say, the definition of software-defined storage (SDS) is anything but clear in today’s storage industry. But why is that so? Is it just another obscure industry buzz-phrase? Is it because we don’t have enough acronyms to work with in the technology field so someone decided to invent another one? Well in either case, I can tell you definitively and without a doubt, it involves the marriage of software and hardware. What good would either one be without the other. That should be pretty clear. So far so good, right?
So, if we need software (intelligence) and hardware (disk devices), then how is this different than it’s always been? Great question. It’s not fundamentally. The only difference is that we have shifted away from a tightly-coupled software-hardware storage solution to a loosely-coupled one. Understanding SDS comes down to understanding the software and hardware boundaries (and from vendor to vendor this will be different, which may be contributing to the confusion perhaps).
Arguably, storage abstraction (and thus storage virtualization) lies at the foundation of SDS (see my three part series on that discussion here). Abstraction in some form has always existed and will always exist at various levels throughout the stack. But with SDS, the implication is that hardware-independent abstraction and the bulk of the heavy-lifting-features occur higher in the stack, furthest away from the disk device to achieve the broadest reach across technological boundaries. Once high-level loosely-coupled abstraction has been achieved, then the other principles fall neatly into place. Below is a summary of what the ‘software layer’ in SDS should provide globally across the architecture: