Let's kill off the meaningless concept of SW-defined storage

Please kill "Layer 3 Switch" as well

From the outside, who gives a monkey's whether the Router is implemented using s/w, ASICs or monkeys toggling the lines. The time that has been piddled away because the managers truncated it down to just "Switch"...

Your point?

Other than to be a ranting dickhead?

Why SDS gets a black eye

Part of the reason for this hopelessness arises from the fact that most folks treat SDS as a singular entity. That is the wrong approach...and in fact leads to confusion, and more hopelessness. If you start with data organization as the core foundation for SDS solutions - with the premise that data persistence is a necessity for storage to be called storage, and how SDS solutions fundamentally differ from each other in terms of how they organize data as a lower level service (block) or higher level service (object). Then comes data services which is where the external storage characteristics get defined, and finally the delivery model. The delivery model is where many get hung up. Appliances that are based on SDS controller software are really meant to be for buyer convenience, nothing else. The key here is the decoupling of the controller software from the underlying hardware, allowing this software to run independently on any hardware. The net net is that a systematic approach to classification is a must for ensuring that we truly look at SDS solutions. One more thing: Orchestration and data persistence are the ying and yang of SDS - you cannot have one without the other. If only have orchestration, that is no different than a souped up SRM solution.

A useful distinction

The Prime Minister of my country has a habit of prefixing a jumble of lies with the introduction “let me be clear...”. It serves a useful purpose in priming you for the nonsense soon to follow.

Software Defined serves a similar purpose. For me, at least, it is an indicator that I am not the intended audience of whatever is to follow. I don’t say that out of conceit; I don’t have control of a enviable budget, nor should I.

I will never forgive whoever recycled ‘data sheet’ to mean ‘glossy brochure’. FWP, no doubt, but endlessly irritating.

SDS

So, if someone tells you they make SW-defined storage you then have to ask:

Is it SW-only and you choose your own HW?

Is it combined SW and HW?

Is it combined SW and proprietary or commodity HW?

Is it a filer?

Is it block-access?

If block access is it a real SAN or a virtual SAN?

Is it object access?

Is it real storage or a control plane only?

Is it some combination of file, block and object access? Which?

Is it cloud-based, on-premises or a hybrid?

Is it scale-out, scale-up or both?

Is it for Tier 1 data, nearline, backup or archive data or a mix?

Is it for all-flash, all-disk or hybrid media?

Clustered DataOntap is covering all your bullet points ;-)

NetApp Sales Norway

It's all about the commercials, and choice - not the technology

This is the same as e-Business, or whatever buzzword bandwaggon was rolling in Alice-land: it means what you want it to mean. However the inescapable fact is that "trad" storage is a bound-in, proprietary environment which charges a premium for pre-integration, and does not allow purchases to be made outside that vendor (you can argue SAN virtualisation, but at the controller level it's true).

SDS allow freedom of choice (albeit with caveats / compatibility testing, etc.), so that the basic environment is a COTS x86 server, with one or more internal or external JBODs housing the disks. So if someone claims to have an SDS solution, the key questions are:

1) Is the SW licence transferrable to a new hardware environment, or do I have to buy it again (forklift upgrade) when maintenance/support finally expires on the storage system?

2) Do I have supported choice over the hardware vendors underlying my storage software, so I can run competitive tenders for the servers/JBODs?

And that, my friends, is SDS. It doesn't matter whether it's Block, Object, File or whatever - that's detail, and where the car analogy falls flat on its face.

EMC ViPR SRM

What folks think about EMC ViPR SRM solution? What are the weaknesses of this product?

Disclosure EMCer here.

Chris - I agree that SDS is an over-used term (I think we're more than guilty of "software-defined *" labelling - so trying to call the kettle black, but rather maybe add to the dialog).

I hate to say it, but I beat you to a rant on this topic :-)

It's worth a read "Is the dress white and gold, or blue and black?":

http://virtualgeek.typepad.com/virtual_geek/2015/03/is-the-dress-white-and-gold-or-blue-and-black-sds-server-or-appliance.html

The fascinating thing for me (coming from talking to customers every day all around the globe) - the "illogical circle" I put in that post is UNIVERSAL (silly humans! :-)

We have 3 data planes at EMC/VMware that are absolutely, definitively SDS (sold without hardware): transactional = ScaleIO/VSAN; object/HDFS(and soon light NFS) = ECS Software. The "illogical circle" (though I get it) after a ton of conversations is that while those are ABSOLUTELY available in a software-only version, the customer desire for integrated consumption + support drives them to appliance (commodity hardware packaged with the software) consumption. Examples of this form of "packaging": ScaleIO = VxRack with open persona, VSPEX Blue/VSAN ready nodes = VSAN, ECS = ECS appliance.

We have 1 control plane at EMC that are absolutely, definitively SDS: the ViPR Controller (and the open-source trunk is CoprHD).

Netting out this first point - there is a real SDS, but to your point, that's not a sufficient discriptor - you need to pull out the clarifying points you raise. Netting out the second point - most customers in my experience like to play with SDS in a "bring your own hardware" model - but when they move forward for real, they tend to prefer appliance consumption (I wonder if Nutanix would be willing to share the ratio of appliance vs. software-only - I would suspect it would match my observations for our stuff).

There's a 3rd point.

NOW, we ALSO have "virtualized versions of our appliances" (vVNX - analogous to ONTAP Edge, but I wouldn't call that SDS, as it's a software version of something built around an appliance - and then is hobbled by the fact that hardware dependencies (in the vVNX - and I believe ONTAP Edge - cases the hardware necessary for HA clustering with any modicum of performance) limits their use cases. Likewise - there is a virtual Isilon node, but the current version again has a dependency (in this case, the NVRAM that exists in an Isilon physical node. There are also software-only XtremIO and VMAX - but not available in the wild.

Each of those case, YES, it's commodity hardware, but the reason it's really only available in physical appliance form (or hobbled software-only form) is a esoteric hardware dependency. This means that I think calling them (or other examples of that) "SDS" is a huge stretch.

**IF** we were to solve for the Isilon NVRAM dependency and make an Isilon true software only stack (vs the virtual Isilon), then I think it could be called SDS.

BTW - all the SDS stacks and virtual appliances are available for download in a free and frictionless way (just Google them).

Anyone calling something that you can ONLY get in something with strict hardware dependencies - well, that's just silly marketing driven off the ledge :-)

So - to net out my POV:

1) - True SDS data plane and control plane stacks have NO hardware dependency, but WHAT that SDS stack does is wildly variant - calling it "SDS" and thinking that's enough is stupid.

2) - That with the exception of the ULTRA large enterprises (think 100's of thousands of VMs, 100's of PB) and the hyper-scale folks - customers in **PRACTICE** don't have (and don't desire) the ability to manage bare metal hardware/firmware/support with SDS stacks - and the SDS consumption model that tends to be the most popular is packaged with hardware

3) - That Virtual Appliance forms of hardware appliances (usually hobbled) - it's a stretch to call those SDS.

4) - That trying to "SDS wash" a hardware appliance is just stupid :-)

Thanks as always for the dialog!

Buzzword Overuse

In a recent white paper from a major storage vendor who has jumped on the software-defined buzzword bandwagon as WageSlave so succinctly wrote above, I read the following that made me nauseous, "Data protection has always been “software-defined.” So now it doesn't matter anymore - any app ever written can be labeled software-defined. Ugh.

Software-Defined Storage is not hardware-defined

Chris, you are missing the point.

All hype-cycle marketing buzzwords become useless as vendors attempt to re-define the new thing to match their old thing. Your job is to sort it out for us...

The point here is that virtually all storage stacks have been running on x86 for many years, but now customers are getting wize to "hardware defined storage". Virtually all of today's "Hardware Defined Storage" offerings do little or nothing to the white-box x86 hardware they run on -- except to mark it up obscenely.

Software Defined Storage is the Very Good Thing that happens when customers can choose best of breed Storage Software the same way they choose their Database software -- independently of the server hardware it runs on.

Don't throw the baby out with the bath. Software-Defined Storage is good, it's the hype-cycle marketeering B.S. that we can do without...