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…