Join Newsletter
Forgot
password?
Register
Trusted Business Advisors, Expert Technology Analysts

Taneja Blog

Taneja Blog

How Do you Software-Define Storage? Explaining the “real meat” behind SDS

"What is Software-defined Storage?" This is by no means an easy question to answer, and there are a lot of people pushing different visions and definitions. For our part in this conversation, I try to remain attentive to a longer term ideal vision (where the market should go) while staying attentive to reality today, and where practitioners can actually get tangible benefit from solutions that may be early or partial incarnations of that long term ideal, but still offer significant benefit today. 

The challenge is that the market is in its infancy and may or may not mature.  The idea of software-defining storage to many listeners may even seem preposterous (and with good reason). But the good news is that solutions that may still be a good bit from the "ideal vision" offer pretty compelling benefit and value today.

Software-defined is often met by skepticism from a lot of practitioners. The main thing that makes storage a unique creature is that it is astoundingly physical in nature. Think back on this legacy of data encoding, storage, and retrieval, and think for a second about just how physical storage is. In some of these historical cases you could even see the data bits (think punch cards). 

That physicality has created decades of burden for the IT practitioner. It has in fact made storage substantially different than any other IT systems. Just think for a second about how we use processors or even networks: These systems process an instruction and generate output and are then immediately ready to be used again.  Today they are highly timesliced, running multiple streams of processing that are interwoven with each other in order to make full use of the resource.  And once that processing stops, the timeslice can be used by another process.

Compare this for a moment to storage. In contrast, storage is a much more limited resource.  We permanently store data, and storage is thereby consumed. Storage rapidly fills up, and we run out of space. We do not today store multiple bits on a physical destination at different points in time, because we need to retain those bits across large numbers of points in time. Because that data is permanently stored, and we need to reference it across many points in time, it becomes a physical anchor. We might move a processing instance to another processor easily enough - even one out in the cloud - but moving data is much more difficult. In fact, because of this there is considerable strength to the argument that the vastly different performing and behaving NAND flash or DRAM solid state storage may be better utilized as a cache pool that can be used in a transient and highly shared way.

Physicality creates an enormous number of challenges for the IT practitioner because storage often restricts the capabilities of the IT infrastructure. It is not easy to physically retrieve stored data in the way that the infrastructure is able to use it (for example, with sufficient speed and bandwidth).  Moving data is arduous, but must happen often to preserve its long term accessibility (this makes things like backup and even cloud movement difficult - the enterprise is less flexible than desired, and as workloads move complex paths to stored data cause all sorts of issues).

How can we possibly talk about software-defining such a thing, and is the idea of software-defined storage (SDS) just marketing hype or can it actually help address some of the limitations of storage today? There actually is real meat behind SDS, and there's tremendous potential it can help with some of the challenges we face every day.

But the thing we need to be thinking about is how SDS stands to have significant impact on your operational challenges around complexity, efficiency, and agility.

We have done some recent work in this area, and have some additional work about to be published.  Some of this work has revolved around VMware's VSAN, some around Tintri VMStore, and still more around Virtual Storage Appliances in general (we have this great comparative landscape here). But I'll even suggest that it isn't purely about products becoming entirely run from software - even the changing nature of storage architecture is becoming more software-based (versus software-defined) and is compelling vendors to offer more flexibility and value in the purchase and licensing of storage systems (like with IBM's Storwize V5000). All of this is well worth taking a look at as they are unique twists on how a software-centric era for storage may change the on-going cost of storage for your organization.

Finally, in conversations with practitioners I usually suggest that they start thinking about a few things as they look at SDS solutions and ponder their relevance to their IT challenges:

  • Will SDS lower my time and effort with process X?
  • Will SDS help me make use of underutilized resources?
  • Will SDS help me meet SLAs more easily, and will it help me do so while ensuring data protection and resilience?
  • What do I need to be looking for in SDS solutions today to make sure they can give me the best mix of capability and long term investment protection?
Bookmark and Share
  • Premiered: 04/09/14
  • Author: Taneja Group
Topic(s): software-defined Storage SDS IBM Storwize V5000 Tintri VMstore VSA

Comments

There are no comments to display. Scroll down to leave your own!

 

Leave a Comment

You must be logged in to comment. Click here to log in or register if you don't have an account.