For responses to other parts of your comment (and other people’s comments), see my subsequent post, Head in the clouds.

To repeat what Ben Langmead said above, the total cost of ownership of a computer, even for a university, is much higher than its purchase cost. For instance, how many computers does each sysadmin manage (or how much time does it take to manage new operating system patches, software installs, etc.)? How much space do they take up? The power for these beasts is not inconsiderable.

When you run machines hammer and tongs with disks flying and memory working full tilt, they tend to wear out pretty quickly.

My wife’s having trouble with her cluster at NYU because the building’s heating and cooling are both tied to the same faulty plumbing system; so even though it’s winter here in NYC, when the heat went out, so did the machine room cooling, so they had to shut down all the machines for a day or two. Just like when the AC went out in the summer.

NYU’s machines are also prone to infection by viruses. They had to completely rebuild their SOLiD cluster for that reason, which also set them back in time and money. It’s such a huge problem that SOLiD service reps just show up with giveaway 1GB thumb drives they won’t even take back.

Amazon’s pricing seems to have gone down from what you’re quoting. Amazon’s EC2 extra-large instance gives you a four-core 15GB machine for US$0.68/hour, or a two-core, 8GB machine for half that. If you can get away with a 32-bit OS on a single core, it’s only US$0.085/hour. That translates into 100 days (400 core days), 200 days (400 core days), and 800 days for $1700.

Do you really only run an analysis once? I see people continually rerunning with different settings, different software, against different assemblies, with public (e.g. GEO) data, etc. All of which requires more overhead at particular times, not necessarily a huge cluster all the time.

My hope is that cloud computing will help generate innovative ideas and help to implement novel business plans.

cat *.fq | bwa | sam2bam | ./findsnps | ./filter4reality | sort |uniq -c | sort -n | head

then go check your fave blog for a minute or two, come back and see the results.

someday.

An excellent analysis – I am also a bit of a cloud scpetic (somebody has to be). You are absolutely right, there is enough time to analyse a GA run on a pretty cheap computer. Even with storage, as long as you dont keep more than a couple of runs worth of raw data, you are looking at a relatively cheap system. Amortise that over the lifetime of the instrument (or number of runs) and it comes out pretty competitive at around $150 per run all in (yes with heat and power etc). (This, and yours, are a class of calculation that goes right back to the early days of Solexa – nothing new).

Even if cloud is a bit cheaper, we’re clearly not talking 10-100X – there’s a lot of wastage elsewhere in most operations that can drown out such small cost savings – like failed runs, libraries and reagents kits which can easily add up to many thousands (not to mention employee costs which are always the largest).

(There are also benefits to owning the hardware, like control – and Im not convinced that all of that software can be run concurrently, with many different resource usage profiles, in way that maintains the low costs and short execution times, at least not without a lot of re-writing of software. A lot of next-gen seq bioinf apps have heavy and demanding IO requirements, im not sure that can be generically abstracted in a way that ensures every user gets what they want all of the time…..)

c

In my view, cloud computing can only be popular when someone design a generic modular framework. In a simpler case of crossbow, I think it would be essential for it to allow other aligners/SNP callers to be plugged in. Crossbow can define the interfaces or the required command-line options and any aligners/SNP callers that implement this interface can run in a cloud. It would be even better to define a more generic interface for other applications such that a command-line tool can be used in a cloud. This will be harder, though.

Analyses like the above are, I think, a great way of advancing the field’s conversation about cloud computing. I’m really glad you’re taking it up.

My main comment is that you’re comparing the cloud cost against only at one type of cost: the one-time cost of buying new machines and adding them to your (already large; at least at Wash U) pool of computers. That isn’t the only relevant number for a lot of people, especially those in smaller institutions and academic departments, because (a) there are recurring costs for electricity, cooling, space, and (b) there isn’t necessarily a huge pool of computers (and support staff, and space) to begin with, so the initial cost and effort barrier can be much larger than the cost of the machines per se.

To someone facing larger barriers, the fact that computation costs so much less than the sequencing machine (or more importantly, the sequencing consumables) will probably push them toward the cloud rather than away. Your situation is relatively special; The Genome Center has an existing, large pool of computational power, steady work, and a lot of like-minded sequencing people under one roof. Academics don’t necessarily have any of those things.

I’ve only heard anecdotal accounts of people calculating recurring-cost comparisons for local vs. cloud, and I’m told that cloud beats local by 2 or 3x. That’s secondhand, so I hope you’ll try it yourself.

Thanks for the interest – I look forward to the future posts.

Best,
Ben

As you may have see in the last paragraph of my post (http://hpcinfo.com/2009/11/22/benchmarking-the-cloud-for-genomics/) a significant premium is paid to get this done in 2.8 hours using 320 cores instead of 6.5 hours using 80 cores. Due to the non-linear scaling, the cost per-hour goes from around $8 per hour to around $29 per hour of elapsed time (this is using the EC2 costs only whereas you are counting the storage costs as well in the $125).

Also, lacking an analysis of the CPU usage efficiency on the EC2 nodes, one cannot necessarily say that we’d need the same quantity of cores to complete the analysis in the same time frame.