Software-defined storage: Making sense of the data storage technology
A comprehensive collection of articles, videos and more, hand-picked by our editors
Software-defined storage is a relatively new concept that vendors are beginning to capitalize on. But there's no clear consensus yet on what the term actually means. Mark Peters, a senior analyst at Enterprise Strategy Group, describes it as an abstraction of the storage from the hardware, with control of the storage residing in a software layer. Companies such as VMware, Simplivity and Tintri, among others, are starting to offer storage solutions pitched as software-defined technology. In this podcast, Peters delves into what software-defined storage is, and what the emerging technology means for value-added resellers. Read the transcript below or listen to the podcast.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
What is software-defined storage? Is it just a concept or is it a real class of product?
It's a concept. Software-defined in general is very cool right now -- VMware bought Nicira, that was software-defined networking -- when people spend a billion bucks or more people tend to take notice. But like a lot of things in this business, the semantics don't always help. Take cloud as a good example. There's lots of storage in the cloud -- you could even argue there's storage that's specially designed to be in the cloud. It's for the cloud but it's not cloud storage, per se. And the same thing is going to be true here. There's no box yet -- you can't go buy a box that is software-defined storage. So semantics sometimes get in the way. Just to use the same example, a private cloud -- you could argue that's just a well-run data center.
But to come back to what it actually is after having said it's a concept, software-defined storage is really, if you like, uber-virtualization. It's where the control and management of what are probably already virtualized storage resources reside. You could argue in this respect that you could use different words. You could say that, in fact, software-defined networking was more like the networking hypervisor, and in the same manner you could say software-defined storage is a storage hypervisor. So the whole question about software definition is "where does it sit?" Where does the control and management of storage sit?
You probably already [have] an abstracted system view of your storage because we've been doing that for years -- distinguishing between the real and the physical storage; even RAID does that. And that's how we now do things like thin provisioning and all the things that we've gotten used to. So now … software-defined storage takes that up a layer and moves the control somewhere into a software layer.
Now, that raises a lot of questions. What elements of your storage are already virtualized? Is it just the capacity and the provisioning, or is it the QoS [quality of service] and the performance? That sort of thing. So in other words, having described it as a concept, you now need to think about all the places it could go. It could purely be viewed as a storage application that runs on a server; it could be viewed as part of the operating system -- the software could obviously sit there. Obviously some people already sell things called storage hypervisors. It could be part of an orchestration layer -- like CloudStack or OpenStack -- all of which you could argue are becoming operating systems anyway. So there's a lot of different ways that it can be implemented. I don't want to suggest that by talking about the confusion and the range that it isn't a good thing -- I think software control of virtualized hardware, whether that [be] storage network or anything else, is ultimately a good thing. People just need to be aware of the variations that exist.
What do you think the implications are for VARs of software-defined storage?
Well, the first thing they need to know is that it's there. I think obviously it's incumbent upon VARs to understand waves and terms and movement in the industry. And then I think it really depends on the nature of the VAR itself -- what is the value-added part of an individual VAR? Here's the good and the bad news: Very often, what VARs provide is help from the management, the software and the services side, and assuming that's the case, this could be very good news for them because you've just moved more control out of a box that you might buy up into a software layer that you can probably help your users with. On the other hand … if your software layer turns up in the operating system or a hypervisor, that's not something that you as a VAR deal with, and then you could find that the world somewhat sidesteps you. Even there you could look for silver lining and say that, "Okay, I may now be relegated to sell the commodity hardware on which this software-defined storage runs," so I guess you've got to make sure you [have] that on your card as well as anything else. But knowing what sort of VAR you are, and being aware of what's going on in the industry, are both important things because VARs are expected to know, to guide and to advise. It's the same sort of thing you would do as you would help any of your customers, clients define what cloud means to them. No one turns up and says "I want to buy a cloud," and no one should turn up and say "I want to buy a software-defined storage thing"; it doesn't exist. A VAR's duty (obligation) -- value and profit -- comes from being able to guide and help.
What kind of customers need to know about software-defined storage?
The answer is pretty similar, in some ways, to the VAR -- everyone [needs to know about software-defined storage]. It's definitely a move. Whether that name stays with it or whether we change the name over time, I don't know, but I think the honest answer is that this is almost a matter of faith or religion to some degree. What really matters -- apart from keeping an eye on what's going on -- is how you view storage. Don't forget, I just said earlier on that this is about where the control and management of storage sits. So what is your long-term view of how storage should be?
Interestingly, I [don't have] the exact numbers but I think I can remember them good enough. ESG [Enterprise Strategy Group] just published a storage market survey, having investigated a lot of people around the world, and when we asked people what their long-term view of data storage [was] -- whether it would be offloaded to the cloud, whether it would become less specialized and the functionality would sit at the virtualization or the operating system level, which is kind of akin to software-defined, or whether it would stay as a specialized hardware, software and staff -- what we found was that those people thinking it would stay very specialized completely were the majority, just under 60%. And just over 30% were more on the software-defined, operating system, virtualization kind of level. But what's really interesting is, when you drill down, the number of people that think it will remain specialized goes up with the number of people who define themselves as very strategic thinkers about storage, and it goes down for those who do things more practically. The reverse is true of those who think it will go more to the software-defined style. Those who spend a little less time looking at storage, who regard it more of a tactical thing, the number of people who view that happening goes up when you break it down by people who view it in that manner. So all I'm saying is it depends on how you view storage because you are talking about where the control resides -- who in your organization do you want to be managing storage? Who do you want to be managing your IT infrastructure? Where does that control sit?
So to get back to the question, the types of customers who should pay most attention are those who think that's where the control should go. Other people should pay attention from a monitoring perspective, but probably be less bothered by the details or actually implementing it.