BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Implementing a software-defined storage architecture can provide flexibility and reduce costs, but it is not without its problems. From the length of implementation time to possible effects on system performance, organizations should look beyond the benefits to make sure software-defined storage (SDS) is a good fit.
Initial SDS execution takes longer
Software-defined storage technology, especially in software-only form, can make initial implementation more difficult. While it does bring flexibility, it provides a storage architecture designer with more options. This translates into a much more extensive hardware selection process: evaluate the server hardware on which to run the software-defined storage software, configure the networking for that server, and select the storage media (flash and hard disk drives) to go in that server or the arrays to attach to that server.
Vendor support for hardware
There are also concerns about support. A software vendor will support its software-defined storage product, but how much effort will it expend (or can it expend) to support a conflict between the hardware and software? Even if the IT planner follows a supported components guide, which limits flexibility, a software designer can only do so much if there is a bug in the underlying hardware. Ultimately, it's the user who takes systems responsibility for the SDS implementation.
This highlights one advantage to the bundled SDS approach: the vendor does all the hardware qualification and selection. As long as you're not overcharged for that hardware, the implementation time savings plus simplified support may well be worth a slight increase in price.
Performance impact of SDS
Beyond support and service, predictability of performance is another item to consider when implementing a software-defined storage architecture. SDS typically runs on general-purpose, server-class systems, not the purpose-built systems designed solely for storage with custom ASICs and hardware that storage vendors have historically used.
Predictability can be especially concerning when SDS is implemented into a virtual cluster (hyper-converged architectures). The hosts within these clusters are not only running the SDS software, but the various applications the organization needs to operate. A spike in processing requirements for an application may impact storage performance, while an increase in storage I/O demand may impact application performance.
A software-defined storage architecture typically promises to decrease both acquisition and operational costs, while simultaneously increasing storage infrastructure flexibility. The problem is that not all SDS products approach the market from the same perspective.
The software-only products more closely resemble what's probably the original intent behind this technology and are best suited to provide all of its attributes. The primary downside is that software-only SDS can involve a potentially more complex startup with higher costs. The bundled products offer a better startup experience, but limit flexibility and should be more competitive than previous hardware-focused products.
So which technique is best for your data? That answer largely depends on whether your IT team has the time and skills required to identify the various storage components on their own. If they do, a software-only product can save significant money and provide maximum flexibility. If those skills are lacking, then a bundled product may make more sense.
SDS architecture essential guide
Is software-defined storage all it's cracked up to be?