Software-defined storage architecture and hyper-converged architecture are like apples and oranges, and there is...
a lot of confusion in the marketplace.
Let's start with software-defined storage architecture. When you look under the covers of software-defined storage, you'll find a control plane and a data plane. If the control plane and data plane are basically bunched together -- meaning there's no clear-cut separation between them -- it is not a software-defined storage product. Until now, all of the storage array products in the past 10 to 12 years fell into this category.
EMC VMAX, Hewlett-Packard 3PAR, Hitachi Data Systems, IBM DS8000 and NetApp were all clearly in the category of hardware-defined storage rather than software-defined storage because a control plane and a data plane were both under the control of the developer. There was no requirement that the developer separate the two. This architecture created a proprietary system.
But when you separate those two pieces, the control plane not only manages the hardware from one company, but also allows all of the other foreign storage you may want to bring in to be managed as well. That's why software-defined storage today is typically associated with commodity hardware; it's a software solution that does not require high-performance storage products from the likes of EMC or IBM. Instead, you can buy commodity storage and build a respectably performing storage system out of it. That's the practical angle to software-defined storage.
But software-defined storage also makes it easier to scale and manage proprietary storage. Depending on its implementation, it may even deliver storage applications that were not available in the proprietary storage underneath. That is one purpose for products such as ViPR from EMC or SAN Volume Controller from IBM. Some products are born software-defined, such as Maxta MxSP, Gridstore and several others on the market today.
Now let's contrast that with hyper-converged systems. Hyper-converged systems include compute, storage, networking, virtualization and a variety of other technologies, such as WAN optimization, inline deduplication and inline compression.
So, a hyper-converged system is an infrastructure in a box, whereas software-defined storage is storage (not a complete system).
Can you buy software-defined storage as part of your hyper-converged system? I think it is fair to assume that all hyper-converged solutions have software-defined storage DNA inside. That's what enables (or at least makes it easier to enable) many of the functions we see as integral to a hyper-converged product. Things like virtual machine-centricity.
Confusion arises because several storage vendors that started out with a software-defined storage product decided they had the architecture to deliver beyond storage and to become a hyper-converged provider. A classic example of this is VMware's Virtual SAN, which started as a storage product but was then extended to a hyper-converged option via the firm's EVO:RAIL announcement. Other examples of this include Maxta and Gridstore. Sometimes, such vendors refer to their products as hyper-converged storage, leading to some confusion. To me, the term hyper-converged always goes with the word system or solution since it has all the pieces to deliver a full infrastructure. And software-defined storage is always storage only. I think the vendor community is now applying these terms correctly and hopefully, moving forward, this will eliminate the confusion.
So, how should a customer decide if a software-defined storage architecture or hyper-converged system is right for them? The answer is easy. If you are looking for a storage product, look for software-defined storage. If you are trying to replace your entire infrastructure or add to your infrastructure, look at hyper-converged solutions.
Storage for VMs add hypervisor support
Clearing up frequently asked software-defined storage questions