All this talk about software-defined storage seems to be missing the point, according to Jon Toigo. Hasn't software always defined properly constructed IT infrastructure?
I don't know about you, but I'm getting pretty tired of all the marketing taglines and buzz-phrases that are being used as substitutes for technical descriptions of storage products and services. The one that has been grating on my nerves even before this fall's conference season is "software-defined storage." (Actually, software-defined anything irks me -- infrastructure, networks and so on -- but since this is a storage-focused publication, I'll vent my bile on that topic.)
Let's start with the obvious question: Hasn't software always defined properly constructed IT infrastructure? When I entered IT (back when it was data processing, not bring your own device or cloud or agile computing or mobile computing …), we were taught to build infrastructure "purposefully," meaning after careful consideration of what the hosted application workload required for the best possible performance.
Purpose-built infrastructure provided the necessary processing power, networking bandwidth, access paths, storage capacity and performance required for an application to deliver its business value. In short, software always defined good infrastructure.
Admittedly, in the 1990s, the idea of purpose-built was conflated with the problem of "isolated islands of automation" in the minds of many smart practitioners. Standing up applications on unique purpose-built platforms, critics argued, created inefficiencies from an integration and investment standpoint. Purpose-built infrastructure tended to share some components in common, like storage, so maybe it would make sense to build those common elements as a "horizontal infrastructure" that could be leveraged by many applications. SANs and network-attached storage were manifestations of this idea of shared infrastructure in the storage realm, though both were technically still direct-attached storage if you delved deeper into their architecture.
So we spent a decade cobbling together all our storage islands into an interconnected storage network that wasn't technically a "network" by any accepted scientific definition of the term. Standards (that weren't actually standards) were created around the Fibre Channel fabric interconnect, and while they facilitated the attachment of massive numbers of disk drives, they provided no in-line management of the resulting fabric and enabled two or more vendors to create standards-compliant switches that wouldn't work with each other to save their lives.
Truth be told, sharing a common storage infrastructure didn't prove to be as business-savvy as vendors originally suggested. For one thing, it took an extraordinarily long time for port costs to fall, especially when compared to Ethernet. For another, lack of coherent management meant experts were required to deploy and maintain storage infrastructure (increasing labor costs), and it opened the door to vendors who fielded arrays into the fabric that proffered expensive value-add functionality and on-array managers that resisted common or fabric-wide management -- so much for economies of scale.
Bottom line: The reason why some folks now pine for a return to the purpose-built storage of yesteryear -- so-called software-defined storage -- is that they believe using one vendor's technology, from the application layer and the hypervisor layer right down to the network and storage layers, is the only way to bring performance, agility and economy back into the reality of IT. To some, software-defined storage is a synonym for private storage clouds, which was a synonym for Storage as a Service, which was a synonym for managed storage.
Storage hardware vendors and server hypervisor vendors don't seem eager to talk about managed storage because doing so would (1) run contrary to their desire to sell proprietary and segregationist wares, and (2) potentially force them to admit that they never truly delivered SANs in the first place. Had they done so, we would have collections of JBODs with their special services hosted like so many shared applications in a common controller environment. That way, if an application required a certain set of value-add functions to support its workload (continuous data protection, deduplication, encryption, mirroring, replication and so on), a virtual volume would be created from raw disk and the necessary service functions would be associated with it on the fly. The volume would then be presented to the workload simply and efficiently, with its performance and capacity monitored and managed via a universal methodology like REST from the World Wide Web Consortium.
While we have the capability to deliver such a SAN today, which would effectively mitigate both the Capex and Opex costs of storage, the industry chooses not to and users choose not to compel them to do so.
So we're stuck with meaningless industry banter about software-defined storage that does little to illuminate a true architectural model, let alone move us any closer to advancement in computer science. I had hoped that the financial constraints imposed by a recessionary economy would force a gut check so we could have an adult conversation about storage. But as yet that does not seem to have happened. Bummer.
About the author:
Jon William Toigo is a 30-year IT veteran, CEO and managing principal of Toigo Partners International, and chairman of the Data Management Institute.
- Why Adopt Software-Defined Storage? –DataCore Software Corporation
- Software-defined Storage Evaluation Guide –DataCore Software Corporation
- Software-Defined Storage for Backup and Recovery –Hedvig Inc
- The State of Software-Defined Storage, Hyperconverged and Cloud Storage –DataCore Software Corporation