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.
I meet enough IT organizations to fully appreciate that not everyone is in the same position.
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?
If your primary motivation is simply paying less for raw storage capacity, that benefit might be there for you — or not.
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.
One is bottoms-up.
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 …
As I look at where VSAN is finding early traction in enterprises, it’s most typically a small piece of a much larger environment.
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
If you’ve stuck with me through all these long-winded articles, you hopefully have a new appreciation for what’s quickly becoming possible with software-defined storage.
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?
An informative post indeed. Thank you for sharing this knowledge.
You can also visit my site New Trends.
Posted by: Mary Fernandez | May 25, 2014 at 09:29 PM
Extremely informative post, Chuck.
I have been doing some reading about SDS ad SDDC for quite sometime now, and found few of the industry experts predicting that SDS might soon fizzle out as the space lacks innovation. Of all the components in SDDC - SDS might not go too far in race with the counter part SDN.
How do you see this?
Posted by: TwitApeksha | June 29, 2014 at 07:12 AM
Software Defined Storage provides storage of data for you on cloud server to secure and store data. This provides virtual storage space and proved very effective and easy to access. It is an effective way for business companies to as they require large storing space and secure servers.
Posted by: SteveParker | September 17, 2014 at 01:34 PM
Software Defined Storage provides storage of data for you on cloud server to secure and store data. This provides virtual storage space and proved very effective and easy to access. It is an effective way for business companies to as they require large storing space and secure servers. 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.
Posted by: Peter jackson | October 05, 2014 at 05:32 AM
Hey Chuck, some simple but key messaging here to start small and remember the scale. As always keep up the posts always makes for excellent reading Chuck
Posted by: John Saunders | October 07, 2014 at 08:48 PM