Whoah. Everyone has an opinion about Software Defined Storage (SDS) these days. That's awesome!
Unfortunately, we have some really funny ideas running around about what SDS really is. The only way to prevent this is to build up a standard
definition and then compare alternates against this definition. When they don’t hold up, you have to call out
those willing to twist the term. Here
are some common SDS myths that we’ve seen running around the internet lately:
Myth 1: SDS Isn’t Real
Our favorite is that claim that SDS is not a real thing and
therefore I can call any product I want SDS.
This one is particularly awesome because it refutes itself
instantly. If there is no such thing as
SDS, why on earth would you even use this term?
If it means nothing, then by definition your product or architecture is
not SDS because SDS is nothing.
See? Silly argument. SDS is a real thing and we see customers
asking for SDS features daily. For
vendors who claim that SDS isn’t real:
stay on the path you’re on. More
money for the rest of us.
Myth 2: SDS is the Same as Storage
Virtualization
This one is more interesting. In this case, people are comparing two terms
that are pretty loosely defined and claiming they are the same. Tougher to refute because both terms a bit
fuzzy so comparing them is twice as hard as just talking about one. In looking deeper at this argument, we mostly
see this being proposed by folks who already make Storage Virtualization technologies. This is red light number
one. When someone takes a new term and
applies it to something they’ve been doing for years, you should be
suspicious. Yes, it’s possible that they
were way ahead. Most likely, they’re
just twisting the facts. Second, it
appears that most people who use the term “Storage Virtualization” apply it to
the notion of providing a software aggregation layer on top of existing storage
back ends. While this is super
interesting technology, it is certainly not new and it mixes data plane and
control plane architecture. One thing we
know for sure is that SDS implies a segregated control plane. This means that traditional Storage Virtualization
products are not SDS. They may embrace
SDS style control planes but the notion of a virtualized data plane is not
required for SDS so they’re not synonymous.
Myth 3: SDS means Software Delivered
Storage
This one is really fun.
Basically, there are some vendors out there who have very cool software
only storage products. We won’t name
them to protect the innocent, but ten seconds on Google and you can find
them. They are claiming that because
they’re software only (no hardware as part of the bundle) that they’re
SDS. That’s pretty silly. If you take a look at most of the major
“legacy” storage players out there, what you will see is a software solution
that’s bundled with hardware. The vast
majority of SAN/NAS products out there are software running on pretty standard
Intel/AMD hardware. They choose to
bundle the hardware and software into a package to make it simpler do deploy/service and perhaps
to gain some revenue on the hardware, but fundamentally all the value in the
platform is software. By breaking this
delivery model and selling just software, does that mean I have an SDS
solution? Obviously not. SDS is not a business model. SDS is a Storage Management Architectural
Model. If software only vendors want to
create an abstracted control plane, then that’s great and they can support
SDS. However, a traditional SAN can do
the same thing if they choose to do so.
There is nothing inherent to SDS that requires you to have a software
only business model.
Myth 4: SDS means Object Storage
Ummm. What? We would not include this at all but there
are some folks who seem to think this.
The notion that object stores are somehow related to SDS is pretty
bizarre but it seems to be common.
Perhaps because many more modern storage systems are starting to be
object based?? We don’t really
know. The reality is that object stores
are not new. Things like S3 and CDMI
have been around for years and some of them have SDS attributes and some
don’t. Object stores are really cool,
but they’re data plane constructs. They
are completely orthogonal to what SDS is trying to achieve.
Myth 5: Traditional SANs Cannot
Support SDS
Again, quite a silly notion.
As we have discussed, SDS is all about abstracting control surfaces from
data plane and data services. There is
no inherent reason why you cannot do this on a traditional SAN or NAS
platform. What is true is that many of
these platforms were designed before the concept of SDS was formalized but it’s
not true that they cannot adapt to this new management paradigm. It’s up to the SAN vendors to decide how/if
they want to join the SDS world or not.
Since we are highly abstracted from the underlying implementation there
is no reason why we cannot support traditional architectures along with newer
software only or object store based systems.
Who's got more Myths?
