Ballard Spots SS Disc, Very Deep

News has arrived. Bob Ballard, noted wreck diver, has spotted the SS Disc at the bottom of the Mariana Trench, pulverized to itty bitty bits. Oh! The horror. The humanity. (Mixing metaphors a bit.)

Some weeks ago, I reported the collision of the SS Disc with an iceberg, and the resulting carnage. Little did I know that the damaged hulk would find its way to warmer waters in the very deep Pacific. Well, now we know. In the ensuing time, all four of the prominent public companies doing SSD (STEC, Fusion-io, OCZ, LSI) have suffered the aftereffects, perhaps, of Mr. Market getting a bad case of the grizzlies. One year lows are well within sight. Or, have the four horsemen done something wrong, at least not doing the right thing?

Never one to ignore the siren song of speculation, here's what appears to be going on.

First, EMC has jumped on the flash bandwagon with the purchase of XtremIO; STEC may get a headache since many had predicted that EMC would swallow STEC. From the (now tagged as EMC) XtremIO web site: "XtremIO is the only vendor building an enterprise-grade, scalable all-flash (not flash cache, flash-tiered, or hybrid) storage system." I suspect Texas Memory, among others, might quibble with the "only" bit. They refer to the components as SSD on one page, but also as a "flash array" on another. What's that line from "Chinatown"; "She's my sister AND my daughter!"

Second, none of the vendors makes any public noise about the "killer app" which requires their SSDs. XtremIO, among others, make noise about on-line de-duplication. This is getting closer. But, fact is, flash/SSD as primary store supports high normal form relational databases, where only huge HDD arrays, short stroked up the wazoo, can get close, with little to no price advantage. But this leads to another issue.

Here's a recent language discussion in the context of moving from java to ruby; replacing a codebase that "works" with one which (may) work better. Much the same argument has been made about three tape drive sort-merge sequential operations software that "still works"; "we don't need no stinkin' four table joins!". Which is why so much COBOL code running on IBM big iron ignores the relational strengths of DB2. The SSD vendors are, slowly, through the de-dupe meme moving toward parsimonious data footprints as critical to SSD adoption. Ain't never going to get cheap enough or dense enough to challenge HDD.