In a recent article we discussed three potential problems with software defined storage (SDS). When we write these types of articles the goal is to bring to light areas of consideration for IT professionals contemplating taking the SDS plunge. The purpose is not to raise FUD (fear uncertainty and doubt) but to instead, raise awareness to our readers about potential problems.
In the article there were three problem areas that we wanted to bring up: the inability to leverage current infrastructure, the lack of complete data services and the lack sustainable economics.
Of the three potential problem areas one of the biggest is that many SDS solutions can’t use the current infrastructure. They require a new server-side architecture instead of leveraging the existing shared architecture. Or if they do leverage current hardware it has to be “dumb” hardware, meaning that the current services can’t be utilized at all.
In that article we were careful to state “many” SDS solutions had this problem – but not all. In addition we’re not saying that server side architectures are bad in and of themselves. There are concerns with these architectures, in fact another article “Server-Side, Converged Storage vs. Shared Storage” is one of the top 2 or 3 read articles on our site every month.
How much weight the IT professional applies to this first problem depends on their data center and the pertinent use case. For example, it’s less of an issue for a greenfield data center than it is a legacy data center with an investment in an existing storage network.
That is not to say that a legacy data center would not find benefit in an SDS solution, even one that was server-side. But there are areas of concern. The organization needs to either be prepared to live with those concerns because the rest of the capabilities of the solution are worth it, OR, IT needs to develop workarounds for those areas. Either path (including avoiding SDS altogether) is fine, we just want IT pros to go into these situations with eyes wide open.
The second area, a lack of complete features, should be a primary concern as well, since most SDS solutions position themselves as complete replacements for the data services offered by the storage hardware that is in place. And remember, in some cases those solutions want that hardware replaced with a server-side, converged architecture. Replacing current software to get something more is a noble cause, especially if it can unify across storage platforms. But, that replacement has to be complete, with all features intact.
We stand by the assessment that there is a wide variation in feature sets coming out of the SDS community, with a variety of missing features as well. Some vendors, for example, can only move data, others can only do deduplication, others can only do snapshots, etc. One of the most common missing features is replication, also known as the ability to create a disaster recovery copy of data. If the SDS solution wants to be the focal point of primary data management, it seems that creating an off-site copy is critical.
Another, even more rare, missing in action example is the ability to provide a service to migrate data into the new SDS architecture. As most IT professionals know one can’t just do a ‘drag and drop’ copy into that architecture. Typically you have to either replicate data at a block level, use some sort of third party migration tool or recover from a backup copy.
It seems that this second area of concern is one that would be less of an issue over time, but we’re not finding this to be the case. There is a whole new set of SDS vendors coming to market that are not feature complete on purpose. They hope to compliment what the data center has instead of replacing it with new capabilities.
The third area of concern, economics, is a little more difficult to summarize because vendors, especially software vendors, package licensing in a variety of ways. They can’t count on revenue from hardware so they have to figure out how to develop a sustainable revenue model from software only. This is not an impossible business model, but it is new to primary storage and as a result there is a variety of approaches.
In this area of concern we are again trying to raise awareness, not FUD, as we move into a software defined era. We want the IT professional to make sure that they are considering SDS solutions that are as granular in nature as possible in the way they charge for their software. Ideally, all features would be turned on for a per-GB (yes per-GB) price point. Also, this model should allow for capacity expansion without further licensing, so as to not shut down the business while a purchase order is created. The actual capacity in use should then be trued up on a quarterly or annual basis.
The difficulty in writing these types of articles is that someone will always take exception. We at Storage Switzerland have no issues with that and provide a comment area for alternative points of view. To my knowledge we have never disregarded a comment that didn’t agree with our content. We stand behind the points raised and consider them a valid set of tests that an IT professional should apply when they consider an SDS solution.