As we continue our series on software-defined storage (or SDS), I think it’s time to turn a critical eye on the current state of affairs, and be completely transparent on many of the obstacles and challenges that inevitably lie ahead.
The move to a entirely new technology stack -- and the associated operational model -- can be a long journey. It's nice to know what to expect along the way ...
If you’re new to this series, you might want to catch up on previous posts here — otherwise you’ll find the discussion rather hard to follow :)
#1 -- It’s Awfully Noisy Out There
A bit of google-fu will show around 20 technology vendors who have used (or abused?) the “software-defined storage” term, in addition to a half-dozen industry analysts and countless hordes of bloggers, including myself.
Needless to say, not all of the conversations conceptually line up :)
#protip: vendors, analysts and bloggers -- if you're saying anything about software-defined storage, do your audience a favor and define your terms and concepts.
I’ve done the best I can with this series to methodically walk through concepts, terms and definitions. I would only hope that others would do the same, based on their world views. When cloud was new, we saw an awful lot of “cloudwashing”, e.g. dressing up your same old stuff with a new buzzword.
If you’re watching the storage landscape, it looks like we're entering a "SDS-washing" period. That's unfortunate, but inevitable.
Just as we saw with "cloud", a noisy landscape doesn't exactly encourage people to move forward with confidence.
#2 -- The Technology Either Isn’t Here, Or Isn’t Fully Baked Yet
If you’ve run through my lengthy series of blog posts, you’ve probably come away thinking that “gee, not a lot of proven stuff in the market that works this way”.
And you’d be quite correct.
But the point of this whole SDS discussion is to illustrate where things are going, and not recap where we are today. The IT infrastructure industry is heading down the highway at high speed -- and storage is along for the ride -- so it's just a matter of time for the pieces to fall into place.
Put differently, your perspective is likely be quite different in 12-18 months time.
Even then, you’ll still see gaps (aren't there always?) but you will also see a much more complete picture in terms of technology you can actually put your hands on.
And some interesting pieces of the puzzle are available today, if you choose.
#3 -- There’s A New Operational Model Implied
For those IT shops who are moving to (or have moved) to an ITaaS (IT as a service) model, the leap to incorporating SDDC and SDS concepts isn’t all that enormous — the foundations for the required operational framework are already in place.
However, for those IT shops that are still using a familiar and traditional operational model, none of this will likely matter. Software-defined storage is operated as a service, not a silo.
With that, I fear we’ve lost a lot of people.
#4 -- And There Are Still Some Potentially Unanswered Questions
Like any new set of concepts and technologies, there will be areas that deserve deeper probing and questioning. One such area: the decoupling of data services from the data plane.
Let’s take familiar snaps, clones, etc. As implemented in a traditional storage array, the data service has intimate knowledge of metadata (track tables, bitmaps, etc.) and physical data placement, as well as the ability to directly manipulate cache.
The result are snaps that (usually) perform well.
An open question is whether this desirable property can be replicated when snaps are decoupled from the data plane. There are a few examples where this has been done reasonably well, but until we see more implementations, it's an interesting question.
A similar concern comes when considering stacking data services: snaps, replication, dedupe, encryption and similar. Certain combinations are obvious; others take a bit more thought around how the interactions should work.
#5 -- Any Abstraction Solves Problems — And Can Create New Ones
Take yourself back to the early days of server virtualization. Yes, we had a powerful new abstraction.
But now resolving something like a performance issue now had to be approached differently, as there was a new abstraction in the mix. It took a while for the tools — and the expertise — to catch up with what the technology could now do.
A valid issue, to be sure, but not insurmountable.
Software-defined storage is a new abstraction — actually, several abstractions — so it would be safe to expect much of the same experiences: same problems, but with a different approach required.
#6 -- There Will Be Resistance From Many Quarters
Let’s face it — today’s storage array technology basically does the job, and — properly implemented — does the job reasonably well. So did physical servers, back in the day ...
Why fix something that (ostensibly) isn’t broken?
I expect to be hearing this from many quarters: established storage vendors who haven’t invested in SDS technology, storage professionals who are justifiably skeptical, various pundits, etc.
By now, you know the answer to the rhetorical question: because much better is becoming possible. The world is a savagely competitive place, thankfully. Those that invest in the required technology and operational model — as the technology matures — will be far better positioned than those that wait until the dust settles, when the answers are obvious to all.
There’s another barrier to be considered: organizational friction. Good IT service delivery rests on a foundation of operational processes that are both mature — and inherently resistant to change.
Changing the technology is relatively easy; changing how people use it is far more challenging.
#7 -- A Long View Will Be Required
We’d all like to think we have the required long view.
And we do — for about 30 seconds — and then it’s off to the next meeting, handling the next crisis, responding to the next urgent request, etc.
To continually focus on achieving a higher goal — maybe over a few years — that’s a very difficult task for most.
But the path forward doesn’t require a major disruption -- there are small and reasonable steps that can be taken.
In a future post, I’ll offer my suggestions as to how motivated IT architects can move forward incrementally.
--------------------
Like this post? Why not subscribe via email?
Comments