There’s no question that your comments are valid for a certain class of requirements. For 98% of the applications out there, local attached storage using some sort of RAID configuration to provide greater throughput and data protection is more than adequate. So for the example of your friend’s photo sharing service, a simple set up (even if he decides to go with a roll-your-own file server solution) is likely to be sufficient. For something like Flickr though, probably not so much, either from a capacity or a performance standpoint. There comes a point in the scaling of the operation (if you’re lucky) where agility is trumped by other considerations.

I completely agree with Aleksander above – if you’re going to shell out the kind of money it takes to make the jump even from local disks to mid-range network attached storage, unless it’s strictly about capacity requirements and you don’t care about availability and introducing/carrying over an SPOF in the storage tier, plan to start buying two of everything.

Dan: Very good questions. And I agree: this depends on the situation of the startup as to what the right solution is for them.

To answer your SLA question:

“Were the issues solved within the SLA period that the company was sold? Were they previously led to believe that spares could be sourced locally, faster or would be customer field installable?”

My understanding was that YES, there was an SLA in place but NO the hardware wasn’t able to be fixed in that time frame. I don’t know what, if any, compensation occured based on that situation.

Regarding the issue with replacing a RAID controller, they’re more widely available and also cheap enough to keep a couple of spares on hand in case of failure.

Adrian and Aleksander: You’ve hit on something I’m hoping will be viable soon: SSD storage solutions. From what I hear from others who have been testing these, so far they’re still unreliable and suffer from write-limitations that are far too low for commercial use. Many online apps don’t really have a gigantic working data set, but need raw throughput which is why so many people use distributed caches like memcached. Why not just keep everything in memory if your cost/MB for SAN storage is low (compared with RAM)? Hopefully, soon this will be a real option.

2Adrian:
High spindle count is not only to lower access time, but to rise transfer speed too. Look on today’s SSD specs – single drive has 60-80Mb\s only.

2David:
A friend of mine is a certified storage engenier running a huge SAN. Developers are calling 500G database “small”. A 12Tb storage – tiny.

So, it’s all depends… There are number of ways to achive similar avialibility of web site, SAN – on of them.

Your comments are interesting. There certainly are pros and cons for each, which will dovetail into the specific requirements of specific startups. However on the face of it, unless your Real Life conversation was much broader, I think you may have missed a trick.

You cite vendor hardware support as the biggest single stumbling block. What you don’t mention is what kind of support contracts the anecdotal cases were covered by. Were the issues solved within the SLA period that the company was sold? Were they previously led to believe that spares could be sourced locally, faster or would be customer field installable?

On the flipside what had the aforementioned people all purchased motherboards, controllers and disks from Frys. Six months down the line a controller goes up in smoke. You have no relationship with Frys to ensure that they carry the same controller you previously purchased from them. They may not be able to offer advice as to whether the current products on their shelves will serve as a drop in replacement. Where do you turn that will beat a two or four hour brand name SLA?

Before you say “but SLAs cost money”. I know. But these are, as you say, the things that minimize risks to your company. When it comes to storage vendors you are ploughing your money into two tangible items: software and support.

Support is obvious. It is all of the above, plus in a lot of cases a resource to verify “I have X and do Y will Z definitely happen?”. Software is all the clever stuff which is sometimes indistinguishable from the word “product”. These are high availability, a good mechanism for snapshots, a simple path to expansion, etc etc. Maybe your commodity hardware and OSS software can do some or all of these things. Can it do them all as effectively?

Don’t get me wrong. I am not employed by or sponsoring a brand name vendor. I am an OSS creature at heart. And it is because of this I’ve experienced the growing pains of commodity storage and bleeding-edge open source solutions. Step changes are not the same as scaling. Sometimes you have to pick best of breed from the outset.

From an operational cost point of view, you save on administrational complexity, power consumption and rack space, and as mentioned, avoid failures that depend on complex vendor specific debugging to resolve them.