Much to my surprise, the most contentious portion of my June
SPDECon discussion on software-defined storage was the seemingly innocuous
slide I added at the end: In it, I simply decreed that hardware widgets couldn’t be a part of a software-as-storage
solution. This seemed to be a self-evident
assertion and, accordingly, I put it at the end of my slides thinking that no
one would notice it. We never got to the
Q&A part of my talk because this discussion usurped all of the extra
session time.
After a good amount of thinking on the subject, I think I have changed my mind somewhat. Software defined storage is tragically a hardware-constrained technology. We run out of compute cycles, and the speed of light may be too slow. These sorts of vexing architecture problems are more directly and easily solved with specialized
hardware. Clearly, the people in the room last June who made a living from solving
problems with hardware had a legitimate concern. After that smack-down, I have
done fair amount of evolution on my thinking on hardware in a software-defined
world.
It is looking like I will be doing the same talk again tomorrow at SDC. This time, I am using a different deck. It might turn out to be a bit more depressing if you are expecting a cookbook on how to build SDS. While I am not going
to spoil my own discussion topic, I will say that it is instructive to look at
places where platform properties have successfully been abstracted, so that the
software doesn’t cease to work when specific hardware is missing. One example
of this is the advanced SCSI functionality that has gone through standards over
the last few years. VAAI, ODX, and the like are all hardware specific functions
that make life substantially better for people without de-virtualizing their
virtualization platform.
All that said, I’m sure I’m going to learn something new
again…
No comments:
Post a Comment