While much of it can be safely identified as “settled science”, interesting portions predictably morph and evolve quickly at the edges.
In my cozy little world, it’s clear that one category is showing obvious signs of splitting cleanly into two completely different beasts that share the same name — software-defined storage.
In many ways, this split has very little to do with vendors and technology — and everything to do with how customers are putting the technology to work.
I’ve written a lot on the topic — maybe too much! — but I’ve also gotten good at boiling things down to its fundamentals: in this case, the ability to dynamically compose storage services using an API.
That's what makes it "software defined".
Today, most storage exposes static service levels, and does so on convenient storage boundaries, e.g. a LUN. Under SDS, storage services can be dynamically requested, and are provided on convenient application boundaries, e.g. a VM.
That's the big idea, in a nutshell.
Note that this definition has little to do with how storage is actually implemented: external arrays, or using software running on servers.
And that’s where it gets interesting.
Reinventing The Past?
Thankfully, they are acquainted with just how rigid and inflexible external arrays can be, so the notion of software-defined can be appealing.
The idea of providing dynamic services based on application policy — without manual intervention on each and every request — can be a huge win: happier internal customers, less over provisioning waste, and more time to focus on issues that really matter.
In the VMware portfolio, that’s where VVOLs come in — a control plane for storage that moves towards this dynamic services consumption model. Arrays advertise their capabilities, applications express their preferences via VASA, and VVOLs are returned: customized storage containers that align to application boundaries.
The world of external storage arrays will be with us for many, many years to come. These portfolios will have to be evolved: not only core technology, but also how they’re consumed. VVOLs helps to do that.
But storage folks aren’t the only audience for software-defined storage, it turns out.
Building A New Future?
The second audience for software-defined storage isn’t really interested in storage as a standalone topic. These aren’t storage people. They don't want to be storage people.
For them, it’s not about migrating the legacy models forward, it’s about establishing a new model.
They don’t want to acquire and manage storage separately. They don’t want to invest in a storage team, or specialized storage expertise. They want storage functions to be integrated into the same exact tools and workflows they use for server virtualization.
I’ll call this group the “hyperconverged” folks for lack of a better term :)
When you ask them about their motivations, the answer is almost always the same: operational efficiency. Rather than trying to build better bridges between two worlds, they want to combine those worlds into the exact same thing.
The precise details of the storage technology become less important than how well it fits in with their desired model going forward. It's all about the operational model.
And that’s a very different agenda than the first crowd.
Differences In Perspective
When speaking to the storage-centric folks about software-defined storage, their interests are usually the same: what’s the storage management console look like, what features do you support and how do you support them, how do they compare with the arrays we know, etc.?
It’s a very familiar storage conversation, only this time we’re talking about storage software running on servers. Same familiar model, different tech.
The hyperconverged customer conversation is quite different.
They’re not looking for a separate storage management console; they want storage that’s deeply integrated into their virtualization environment, most usually vSphere. As a group, they are usually less concerned with individual point features and implementation details.
Their measurement system is simple: does this new technology let me get my work done more efficiently? In the VMware world, that’s VSAN. It wasn't build for storage people -- it was built for virtualization people.
Note that with regards to the original definition — dynamic service levels from storage — can be achieved either way by either group.
One industry concept, two very different measurement systems. A split appears to be inevitable, especially when two very important audiences want two very different things.
Who’s In Control?
Behind the scenes, there are two distinct organizational models that are quietly competing.
All storage should be controlled by storage professionals.
The second is driven by the observation that dedicated storage professionals maybe aren’t needed for everything, and there’s value to be gained by consolidating portions of the storage function with the virtualization administrators.
Not all storage needs to be controlled by storage professionals.
Note that this isn’t an either/or discussion in most cases. There are plenty of good reasons to continue to use external storage arrays for some workloads, and thus invest in the dedicated expertise needed to run them effectively.
Nor can it be stated that each and every workload always demands an external storage array, and its required dedicated expertise. It’s about finding the right mix.
What’s Really Important To This Second Crowd?
In a phrase — deep integration.
Everything — including software-defined storage — gets evaluated first and foremost by how deeply it integrates: technology, management, operations, workflows, support — you name it. They want their storage technology built in, not bolted on.
Why? It's all about the new operational model: a simpler, easier approach that enables fewer people to get more work done, faster and with less friction.
The Split Is Already Here
If you take a quick survey of software-based storage products in the marketplace today, you’ll see confirming signs. There’s clearly one class of product aimed at storage professionals, and another class aimed at the all-in-one virtualization administrator.
They want very different things. They have good reasons for doing so.
And — as a result — we’ll end up with two categories to debate about going forward :)
Like this post? Why not subscribe via email?