Your vision of software-defined storage seems a bit network-centric to me. No surprise, I guess, given where we're each coming from. ;) Here's the thing. Data has an inertia that neither computation nor networking do. It's *really* expensive to rearrange where data is stored. We're not talking seconds, which is still an eternity in many computing domains. We're talking hours. Days. Even weeks. If you want to change replication levels, it's going to take a while. If you want to enable or disable encryption, it's going to take a while. If you want to add or remove storage and have the system migrate data so that your disks and servers are all equally utilized . . . you get the idea. Changing protocols or tweaking layer-two attributes is kind of missing all the problems that storage people actually need to worry about.

Software-defined storage is about changing the "shape" of data as it sits at rest, more than it's about changing the way that you access it. How much durability? How many aggregate IOPS (not MB/s)? What ratio of raw to usable space? Give me storage with these characteristics and *poof* it's there, but now it needs to persist far longer than any network connection (and through more kinds of failures). It's not "holistic" to ignore everything that needs to happen on the other side of the servers' NICs or HCAs. If there needs to be more synergy between SDS reconfiguring the storage and SDN reconfiguring acccess to it then great, but neither should be looking down their nose at the other for failing to do it all.