Software defined storage (SDS) is a fairly new tech-term related to pooling together storage assets, often at an Enterprise organization. Many media pundits are having difficulty fully defining the term, mainly because so many solutions out there exist that have a different technological back-end.
This confusion is okay at a high level, because ultimately IT is looking for solutions to storage scalability and connectivity and many variations on this concept work.
However, the devil’s always in the details, and not every solution works for every organization. If you’re just starting to look at this technology, take a look at this post for more direction as to where the solutions have been historically and where they’re moving to.
What Exactly Is Software Defined Storage (SDS)?
Since so many definitions exist for software defined storage, let’s start with a few qualifiers.
Software defined storage solutions should:
- Be hardware that is run by a software layer that is independent of itself
- Have a centralized management tool that users can view storage availability from
- Pool together various storage silos (SAN, NAS, Desktop, Cloud, etc…)
Basically, a software defined storage solution acts like a universal remote for your home theater. It brings together all of your various storage assets and allows centralized management and tracking from one tool. With SDS, the hardware is run by this centralized storage management tool for virtualization and optimization purposes.
The History of Software Define Storage
Because the definition is so broad today, we turned to a few industry experts to help us with the history of the term so we could better understand it.
Here’s what Mike Matchett, a noted storage expert and Sr. Analyst and Consultant for the Taneja Group, who provide relevant and timely information on storage and storage-centric server technologies, had to say:
The roots of all things “software-defined” really started in the networking space, when some clever folks finally realized that general purpose CPU’s had advanced to the point where functionality at speed and scale could be provided in software rather than need to be baked into ASICS, firmware or other hardware…
In storage the term is a little muddier, as storage also needs to persist data. At first SDS, like in SDN [Software Defined Networking], meant a separation of the “data plane” from the “control plane”. In other words, storage devices could be built that would essentially work like building blocks, remotely programmable and controllable through API’s (mostly with the famous REST API approach, although that’s not the point). The intelligence, or control level of management could be provided by a third party that might just have information or perspective on what needs to be done that comes from outside that which is seen when you are “inside” the data plane.
However, like the term “cloud”, [SDS] was overused by marketing teams to rather more mean that their storage solutions were now being written and delivered as software. While software implemented storage is certainly more likely to be programmable in the SDN sense, not all of it actually is. And much hardware actually is now remotely programmable.
— Mike Matchett
In addition, Eric Daimler (PhD), Principal at Skilled Science, also mentioned how the term became hard to define over time.
[SDS] has no unique meaning anymore, if it ever did. Its genesis was to follow the hype around software defined networking, which had a clear idea of a control plane that was separated from the data plane enabling dynamic configuration and control independent of the hardware vendor….network switches could become simpler because the smarts had been moved to software.
In contrast, there was little agreement on SDS and it became a marketing term defined as “what I sell”. The closest storage equivalent to the SDN control pane vision is probably DataCore and IBM SVC, these have been relabeled as SDS but when they started out over 10yrs ago we just called it virtualization.
— Eric Daimler
The New Class of Storage Solutions
Because of the ambiguity with regards to software defined storage, a new classification is needed that’s not just another marketing term. The problem is most SDS solutions accomplish or partially accomplish our 3 criteria listed earlier. However, this leaves out the user element, which Mike hints at when he says that “storage must persist data”.
When storage persists data, that means that even though the processes that placed the data there may be gone, the data must still exist on its own in the hardware. SDS solutions should accomplish this. However, the root cause of data is often user interaction, basically end user interaction and processes, which is often forgotten about by most modern software defined storage solutions. That’s because they build they’re SDS solution solely with IT in mind, not the end user.
This speaks to what we’re trying to accomplish at SmartFile through FileHub™, our on-premise File Exchange Platform. We’re taking software defined storage one step further by evolving beyond IT. We’re building a tool that, while it’s built for IT, it’s also designed for users.
Remembering the End User in Software Defined Storage
Users have unique ways to access their storage pool. Since we connect the storage into one location, we can also allow access to it through a variety of secure methods.
This means that your developers can use an API to access web content, your marketing team can share files with external vendors through the browser interface, your IT team can batch files through FTP, your least tech-savvy users can have a mounted drive for desktop access, and email attachment headaches will be replaced by people using our outlook client.
Most users will never know they’re accessing data through the SmartFile application layer even though they’re using divergent connection methods. Even the web interface can be branded to replace SmartFile’s colors and branding with your own.
Still, despite different connection methods, storage silos are brought together and accessible via a user friendly interface that administrator accounts use for monitoring, compliance and their own storage needs.
Other users, depending on their account level, can create other users and manage folder structure within the interface as well. All activity that runs through this on-premise appliance (uploads, deletes, connection types, file versions, etc…) is monitored and tracked through this accessible SmartFile application.
This equips administrators in new ways that other software defined storage solutions simply can’t handle, because they weren’t designed for the end user. It’s one thing to understand storage statistics, which many existing SDS solutions excel at, it’s another thing to monitor user accounts and actual data that is created, edited or removed.
The next iteration for SDS providers is this user piece that SmartFile’s FileHub™ already provides. If you’re interested in learning more, contact our sales team.