I thought it fitting that I close out this series on software-defined storage with a bit of practical advice for those of you who are intrigued — and motivated — to move in this direction.
To be transparent, it would be inaccurate for me to say that there’s a landslide of significant SDS deployments to date. Yet interest is very, very high.
That’s to be expected: I remember the early days of cloud, big data, etc. All were once exotic concepts, but all are quite mainstream today.
And I’ve met enough architects who have that gleam in their eye to be encouraged :)
At the risk of repeating myself endlessly, here’s the quick definition of software-defined storage we've been using:
the ability to dynamically compose storage services, aligned on application boundaries, driven by policy
Although it's a terse definition, it quickly unpacks into a very large and powerful set of of concepts. Similar definitions can be constructed for software-defined networking, software-defined compute, et. al.
Three important disclaimers:
- Just because storage is implemented in software doesn’t make it software-defined.
- Just because storage software comes packaged in an array doesn’t mean it can’t be part of a great SDS environment.
- Just because a vendor uses the term liberally in their promotional materials doesn’t mean they have the slightest clue (many examples!)
As long as the key attributes of the SDS definition are satisfied, I would argue that -- regardless of specific technology -- you’re moving in the right direction.
The First Question: Is SDS Right For You?
Let’s face it: SDS is new tech and new process, and not everyone may be in a position to move ahead at this time.
While virtually everyone aspires to better ways of doing things, the opportunity to do so is usually constrained by the pragmatic: the crisis du jour, a higher priority project, no funding, no resources, toxic politics, etc.
Server virtualization made clear sense for many years before it was widely adopted, as not everyone was in a position to move ahead at the same pace.
And, depending on your situation, the timing and situation might not be ideal for you to move ahead with software-defined storage.
That’s OK — things have a way of changing before long.
Check Your Motivations
No joke: doing something for cheaper is a powerful motivation when adopting new IT technologies. But exactly what are we doing cheaper here?
After all, parts is parts :)
However, if your motivation is more along the lines of a new operational model that’s more efficient and agile than today’s approach, that’s clearly there.
What’s “cheaper” with SDS is delivering better storage services, more quickly, with less effort *and* at a lower cost.
If your goal isn’t a better operational model (more agile, more efficient, less waste, etc.) I fear that you’ll ultimately be disappointed with the growing crop of SDS products.
Decide: Top-Down — Or Bottom-Up?
At this stage in the market’s development, there are two clear motions when it comes to SDS.
The idea is to create a software abstraction over existing traditional storage assets, and turn them into a more streamlined service that can be consumed for a variety of use cases: physical, virtual, etc. EMC’s ViPR clearly fits this mold. And, depending on your situation, this may look very appealing indeed.
But there’s another viewpoint — and that’s top-down.
In these situations, IT is building a cloud-like platform — maybe their second or third. They now fully appreciate the primary importance of automation and the associated control plane. Everything runs in a VM. The legacy isn’t a primary concern. And the new environment is presumed to be reasonably homogeneous.
For these people, the richness and expressiveness of the control plane matters, and (repeating myself here) the ability to dynamically compose storage services, aligned on application boundaries, driven by policy. VMware’s VSAN — and forthcoming VVols for external storage — reflect this line of thinking.
Start Small …
When I talk to these people, their motivations are clear — they want to get hands-on experience with a real software-defined storage product that’s designed to work with what they already have, e.g. vSphere and everything they’ve built around it.
There’s no substitute for hands-on: to understand how it works, what’s involved, key differences, where it fits, etc. As the initial investment isn’t unduly exorbitant (for VSAN, it’s a cluster of three or more servers compatible with the HCL + software licenses), the primary barrier ends up being investing in the time required.
… And Think Big
One of the more eye-opening exercises I was involved in years ago was tracing the flow of a storage service request for a specific company — from its origins in a business meeting where someone says “we’re going to need more space”, all the way to that storage service being stood up and ready to consume.
The surprise wasn’t really a surprise: something like 85+ discrete steps, spanning 9 different functional groups with an average elapsed time of 100+ days. Not to mention rampant over-provisioning.
Sounds like how we used to do server builds. And people wonder why public clouds are so popular …
Mapping out that same process in detail within your own organization might be a useful exercise. You’ll likely find that the full organizational cost of processing a request often exceeds the cost of the resource itself. Now, multiply that by the number of service requests in a year, and you’ll likely come away with a very big number.
If you’re thinking big — that’s the prize: building a better model. Satisfying storage service requests — quickly and precisely — using an efficient application-centric workflow — and consuming optimized resources. Sort of like Huffman coding for storage service delivery :)
Planning Your Journey
Like server virtualization that came before, software-defined storage has the potential to transform how we think about storage in all of its facets.
The technology is becoming available; all we have to do is figure out how to apply it our individual environments.
The journey is yours.
Good luck, and godspeed.
This article is part of a series on software-defined storage.
Like this post? Why not subscribe via email?