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

Software-defined storage has become a meaningless and useless concept. It doesn't tell you anything useful beyond the vague idea that software drives the hardware. Well, yes, when virtually every storage hardware product you use is based on commodity hardware then it would, wouldn't it? I met a person the other day who said …

  1. Anonymous Coward
    Anonymous Coward

    Can we kill SDN as well please?

    after all Cisco (and other makers) routers/gateways etc have been configured using SOFTWARE for years.

    1. Anonymous Coward
      Anonymous Coward

      Re: Can we kill SDN as well please?

      Hardware-centric network is totally different from software-centric storage.

      They are evolving into more software, and being called software-defined.

      What about storage?

    2. P. Lee

      Re: Can we kill SDN as well please?

      Although it could be defined in the VMWare sense - virtualised routers (traditionally hardware) running as applications on what would normally be considered application (as in database, file-serving, email) servers.

      Software-defined storage is a nonsense because the storage function can't take place in the software layer.

      1. JeffyPoooh
        Pint

        Re: Can we kill SDN as well please?

        "...the storage function can't take place in the software layer."

        Of course it can. Just use an array.

        ...LOL

        1. Anonymous Coward
          Anonymous Coward

          Re: Can we kill SDN as well please?

          "Just use an array." ... ahhh, SDS written by a BOFH.

  2. Anonymous Coward
    Pint

    Anything else is just pseudo-sophisticated marketing bollocks; ordure fit only for fan blade coating.

    Now that we've pretty well dusted SDx marketing, what do we talk about now. Still beer-o-clock here!

  3. JeffyPoooh
    Pint

    Step 1 - define precisely the boundary between software and hardware

    Most disk drives will include some sort of programmable hardware (FPGA or similar). How the 'code' that configures this hardware is managed is infinitely variable. So the boundary between software and hardware becomes hopelessly blurred. If you disagree, then give it time; you'll eventually see the point.

    The biggest lie of all is the BS claim, "This product is software-defined, so it won't go obsolete." As far as I'm concerned, you're allowed to smack upside the head anyone making any such claim.

  4. no-one in particular

    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"...

    1. hplasm
      Boffin

      Re: Please kill "Layer 3 Switch" as well

      To be fair, Layer 3 switches understand routing (to a certain degree) whereas just Data Switches don't.

      And Layer Cake switches will shoot you in the face if you try to make them route packets, whether they have a mockney accent bit set or not.

      1. no-one in particular

        Re: Please kill "Layer 3 Switch" as well

        The point is "Layer 3 Switches" *are* Routers and should just be *called* Routers!

    2. Tom 13

      Re: Please kill "Layer 3 Switch" as well

      You posted that wrong. The correct formulation is:

      The first thing we do when the revolution comes is ...

  5. John 104

    Your point?

    Other than to be a ranting dickhead?

    1. no-one in particular

      Re: Your point?

      On the random assumption that you are referring to my post:

      Because I've witnessed wasted time and arguments when a multi-lingual and multi-company project required Router functionality but one group kept saying "ok, we will provide the Switches" and the other side said "No, they need to be Routers". It took a stupidly long time even before someone said the full phrase "Layer 3 Switch" and a reference to the manufacturer's blurb before it became clear that the blasted things are just Routers. Of course, there are places in the design where we *do* just need Switches and where we have Switches - but we still get diagrams floating around where someone has written "Switch" in a tiny box and gawd only knows which one they are referring to.

  6. ashn

    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.

  7. nilfs2
    Joke

    I want software defined marketing jargon

    so I can turn it off and delete it

  8. mevets

    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.

  9. Stian Aarhus

    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

    1. Mk4

      Re: SDS

      Hahahahahahahahahaha - oh, I haven't laughed so hard in a long time! For that I thank you, but I'm still going to mark your post as abuse of my intellect, if not actually abuse of the comments. :-)

  10. WageSlave

    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.

  11. sahooj

    EMC ViPR SRM

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

  12. virtualgeek

    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!

  13. Anonymous Coward
    Anonymous Coward

    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.

  14. Anonymous Coward
    Anonymous Coward

    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...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon