If you’re in IT, and attending the usual industry events, you can’t help but notice the explosion of companies, from those making software to those making hardware, claiming to have Software-defined solutions. I even bumped into someone (we’ll leave him nameless) who claimed that his company’s flash controller was “software-defined”, because after all, it was software that defined how the hardware should be managed; right? Right …
Yes, software needs hardware, but that doesn’t make the resulting solution Software-defined. While there are an increasing number of Software-defined solutions out there, it’s still a bit of the Wild West, and buyers best beware. Have some healthy caution as you explore solutions and understand how your vendor defines Software-defined. Getting that base-level understanding is important, because the solutions that flow from the definition have different characteristics that either will or won’t work with your use case.
So, how do we define Software-defined? Well, we are Nexenta after all, the storage software company; we would say that the only true SDS solutions are ones where the software is hardware agnostic, architecturally flexible, and able to deliver business agility (along with the usual storage software features). But don’t take our word for it, for a deeper dive into SDS definitions, check out George Crump’s latest blog “What Exactly is Software Defined Storage“. The important takeaway here is that the definition of SDS matters when you’re trying to solve a problem – it defines the benefits that the solution is capable of delivering to you.
Next week we’ll be starting a blog series on how to Raise Your SDS IQ, where we’ll walk through the six different types of SDS, as the industry defines them, and explain where and why they excel, and fall down. So, watch this space as we work to build out your buyer’s toolkit; that way you won’t be the guy (or gal) with the knife at the gun fight ;).