Seagate just reinvented the disk interface using Ethernet

Yes, it means your switch must not fail. But if you worry about your switch failing, you have that worry if it's not handling storage too, and you deal with it with redundancy. Moving the storage to hang off a switch does not change that - if you have a single switch and it fails, your servers are just as unavailable either way.

But hanging storage off your switches means it is possible to have servers take over drives of failing servers, which makes many other failure scenarios easier to handle.

In terms of pipes, yes, that is a concern for some uses. It won't be fast unless you go to 10GE, and 10GE switches are still hopelessly overpriced. But "most people" do not serve up gigabits of content, and could do just fine with slower drives hanging off cheap 1Gbps switches.

I already assume not only that my drives will fail, but that the network and servers will fail too. Which means I need to replicate data over many servers on different networks. In that case having the drives be directly addressable over TCP/IP is not an added complexity, and it opens up so many opportunities in improving flexibility of server enclosures etc.

On the other hand it opens up a massive opportunity for people to create their own storage fabric using these drives as building blocks. That means instead of having to hit up EMC for a big drive array, you will eventually be able to get an open-source implementation of same if you want, or one built on open standards so you're not locked into a particular vendor.

For companies like Facebook, Google, Apple or Yahoo that are storing petabytes of information, a drive subsystem like this is surely a dream for their engineers. Now instead of having to attach the drives to servers that do little more than wrap S-ATA or SAS into Ethernet for merging into a larger storage cluster, the drive does that all by itself.

Plus, imagine how Backblaze might be able to re-engineer their pod (http://blog.backblaze.com/2013/02/20/180tb-of-good-vibration...) to use this.

Right, but having local disks reduces the sources of failure, reduces contention, reduces latency, reduces the complexity of failures, and is thus much nicer to work with. Computers and networks would be easier for us to debug if they had a binary works well/doesn't work at all, but we all know they don't. Especially networks.

The simplest and sanest architecture is keeping dumb disks local to where computation is running (and yes, that may also include duplicating data across several servers). Anything else is asking for more crazy classes of failure. Been there, bled there, not going back there.

--

Case 1: Startup X makes a webapp cluster that looks up user information and returns results. It calls a library, which looks up a hash key to query a disk, and returns data.

Problem 1: Lack of load balancing. If there are three disks, and user FRANK is on disk two, and user FRANK's data is getting queried 50x more than the other users, that second disk is toast performance-wise.

Problem 2: No redundancy plus short lifespan of disk means when the disks die the user data goes too.

--

Case 2: Big Company Y creates a storage application layer to intelligently do things with the data. They have a small cluster of machines with apps that take queries and do things with the data, and manage the data using key/value pairs on disks attached to a private storage switch.

Problem 1: Dependent on ethernet (and its overhead, and latency) for each query doesn't perform as fast as other disk interconnects; have to use hacks to increase performance. Network management now critical component of your storage functionality.

Problem 2: Because the Virtual Memory Manager is no longer managing a filesystem cache, all key/value fields must be cached by the application, so you're re-implementing a VMM layer in your storage application. (Because nobody is stupid enough to not cache random disk queries)

Problem 3: Relational queries become almost completely useless. Performance drags due to all the individual queries, and you end up building a new cache layer just so your database can speed up searches, or at worst case end up with an index-only cluster of these disks.

--

As you can tell by reading Backblaze's site, there are lots of different uses for storage and different requirements for each. But one thing that's pretty widely acknowledged is it's more efficient to have a really long single piece of storage versus lots of very short pieces. I imagine Backblaze will look at this and go: Why don't we just make our own?

Hmm, which raises the question: how much RAM should a hard disk have? In a regular architecture, that database lookup could be meaningfully cached (and you could design and provision exactly to ensure your entire set is cached). Opaque K/V "disk" seems less appealing from this angle