We have finally released our Software-Defined Storage (SDS) Coverage Report. The first of the SDS reports covers ioFABRIC, Hedvig, and DataCore products. The coverage graphs show these vendors’ product suites along multiple axes. While we do not draw any specific conclusions, if you want that, please contact us. We do draw some general conclusions. One is that SDS for any particular vendor is not like SDS for any other vendor.
The definitions of SDS vary greatly. The belief that software serving up storage is sufficient to be considered an SDS product is prevalent in the industry. We happen to disagree. As you can see from Figure 1, the multiple-axis graph leans heavily away from just presenting storage via software, and toward Policy, Data, and Security functions.
The research shows that some companies are striving in those directions while covering Automation and Orchestration as well as some level of underlying Analytics. SDS is more than presentation, it is more than Augmenting storage with deduplication, etc. It is more than Optimizing storage with caching and compression. SDS is more than Aggregating underlying storage devices. It is a host of newer elements that allow one to do more without hardware requirements. SDS should make cloud-native applications easier to deploy.
The research shows where the SDS world is heading. It also shows how companies are getting to those desired goals or state. Some are definitely getting there faster, while others are being laggards. Once we move past the “we do everything in software, so we are SDS” mindset, we notice several trends. These are:
- Analytics plays a growing part of SDS
- Initial data placement and ongoing data locality are major concerns moving forward
- Everything being driven by a uniform data policy across all platforms
- Data functions are the future of SDS; specifically, how do we move the data closer to processing or processing closer to the data?
- It is not all about caching; caching is actually a very small part of SDS
- Storage still needs better security
The lack of security functions—the most basic things, such as role-based access controls, encryption, etc.—is hurting storage in the long run. We need SDS to become smarter as the attacks are getting smarter. Why should replication, replicate data over the same blocks already used when it would be trivial to detect rate of change? Once the rate changes sufficiently, we most likely have a ransomware attack. Perhaps the use of canary files could also alleviate the incredibly fast replication of encrypted data. If all I do is replicate, then my storage security needs more oomph. We need to detect ransomware within SDS, perhaps as a data function.
We are getting there. SDS has many components, with the major ones listed in Figure 1.
One thing we also noticed was a growing desire to have SDS be part of the cloud-native movement with integration into Docker. However, getting storage defined within Docker, Kubernetes, etc. is not as easy as it appears. We have written before about how storage is treated by Docker. SDS needs to be more than just presenting storage into containers. It needs to present the right storage into containers.
We are seeing growth in many aspects of SDS by many organizations. We chose these three (ioFABRIC, Hedvig, and DataCore) as a representation of those companies creating SDS platforms.
For more information, please read the report.