The Software Defined Storage (SDS) model in its early days was often compared to Software Defined Networking (SDN). Both used virtualization as a foundational technology and replaced hardware constructs with software loaded onto general purpose, open, commodity platforms. The early vendors of SDS such as EMC also applied SDN’s data plane/control plane abstraction model to SDSalthough that reference has died down considerably. Since then, SDS has gone its own separate way.
However, the comparison remains worth exploring even now. SDN has become a fundamental cloud construct—as fundamental as server virtualization—and as such has achieved far more success to date than SDS. The question is why?
SDN vendors point to how they have been able to greatly simplify the management of large networks making the attributes of cloud computing possible. These include application agility, management automation, and the utility usage model. As compared to the previous networking paradigm, SDN’s centralized control (or “control plane”) coupled with simpler architecture and management requirements, make SDN a cloud enabler—hence SDN’s ability to penetrate both hyperscale and traditional enterprise IT environments in volume.
SDS on the other hand has yet to achieve the same degree of success. When SDS vendors tried the same conceptual presentation applied to storage they only confused potential customers. Beyond that, the idea of turning a general purpose server into a production-quality storage array simply by adding software caused enterprise storage administrators to wonder if they were now being asked to take on the role of their preferred storage vendor’s support and maintenance staff. Where is the warranty here? Who do I call for problem resolution and when? Do I diagnose a problem first and then call?
After sitting through numerous presentations from SDS vendors I have noticed that they typically have two things in common:
Where they appear to be getting the most traction with these arguments within enterprise IT is in situations where two “flavors” of IT have evolved. One is dedicated to running and maintaining the applications that have supported the business for years on mainframes, client-server architectures, and now virtualized server farms running Windows and Linux. The other often comes into existence through executive edict: Thou shall be agile, mobile, and cloudified. And to get there, thou shall be software-defined. This agile, cloudified, software defined flavor of IT is where SDS has found willing adopters.
However, early adoption of SDS by cloud builders is by no means a guarantee of long-term success for the following reason: Unlike SDN, there is more than ample opportunity for SDS to be seen by the enterprise user as cost efficient when acquired, but cost prohibitive if a more complex and staff-intensive management model is a longer-term result. I have heard this complaint for example with regard to Ceph—a software-defined, open source-developed block, file and object storage platform that runs on commodity server hardware: very easy to acquire, but very hard to get working and manage in a production IT environment. And the long term economic cost has not yet been explored in depth. I have also heard of an instance where a user took months to learn how to manage a proprietary vendor’s SDS solution before putting it into production.
To overcome these hurdles, I believe SDS has to offer greater value than the ability to pay as you go and deploy on commodity hardware. Like SDN, SDS has to be more of an enabler of new business opportunities and/or new functionality not available from hardware-bound storage. The opportunity is there for SDS vendors to make the impactful value statements, but as yet I have only seen a handful make them.
