Live data from Hacker News

AWS doesn't make sense for scientific computing

noahlebovic.com

151–160 of 281 posts

Re: AWS doesn't make sense for scientific computing

#151

[retracted]

Where do you see that? On your link I see:

  Data Transfer OUT From Amazon EC2 To Internet
  First 10 TB / Month $0.09 per GB
  Next 40 TB / Month $0.085 per GB
  Next 100 TB / Month $0.07 per GB
  Greater than 150 TB / Month $0.05 per GB
Which means if you transfer out 90 TB in one month, it's $0.09 * 10000 + $0.085 * 40000 + $0.07 * 40000 = $7100.

Re: AWS doesn't make sense for scientific computing

#152

Having had the responsibility of providing HPC for a literal buildings full of scientists, I can say that it may be true that you can get computation cheaper with owned hardware, than in a cloud. Certainly pay as you go, individual project at a time processing will look that way to the scientist. But I can also say with confidence that the contest is far closer than they think. Scientists who make this argument almos…

Also it assumes full utilization of hardware. If you have variable load (such as only needing to run compute after an experiment). The overhead costs of maintaining a cluster you don't need all time are probably much lower than resources you can schedule on-demand.

Re: AWS doesn't make sense for scientific computing

#153
>Even 2.5x over building your own infrastructure is significant for a $50M/yr supercomputer.

Can’t imagine you are paying public prices on any cloud provider if you have a $50M/yr budget.

In addition, if, as the article states, the scientists are ok to wait some considerable time for results, then one can run most, if not all, on spot instances, and that can save 10x right there.

If you don’t have $50M/yr there are companies that will move your workload around different AWS regions to get the best price - and will factor in the cost of transferring the data too.

I was architect at large scientific company using AWS.

Re: AWS doesn't make sense for scientific computing

#154

[retracted]

Where do you see that? On your link I see: Data Transfer OUT From Amazon EC2 To Internet First 10 TB / Month $0.09 per GB Next 40 TB / Month $0.085 per GB Next 100 TB / Month $0.07 per GB Greater than 150 TB / Month $0.05 per GB Which means if you transfer out 90 TB in one month, it's $0.09 * 10000 + $0.085 * 40000 + $0.07 * 40000 = $7100.

Sorry, you are right. I need another coffee today.

Re: AWS doesn't make sense for scientific computing

#155
As an HPC sysadmin for 3 research institutes (mostly life sciences & biology) I can't see how cloud HPC system could be any cheaper than an on-prem HPC system especially if I look at the resource efficiency (how much resources were requested vs how much were actually useed) of our users SLURM jobs. Often the users request 100s of GB but only use a fraction of it. In our on-prem HPC system this might decrease utilization (which is not great) but in the case of the cloud this would result in increased computing costs (because bigger VM flavor) which would be probably worse (CapEx vs OpEx) Of course you could argue that the users should do and know better and properly size/measure their resource requirements however most of our users have lab background and are new to computational biology so estimating or even knowing what all the knobs (cores, mem per core, total memory, etc) of the job specification means is hard for them. We try to educate by providing trainings and job efficency reporting however the researchters/users have little incentive to optimize the job requests and are more interested in quick results and turnover which is also understandable (the on-prem HPC system is already payed for). Maybe the cost transparancy of the cloud would force them or rather their group leaders/institute heads to put a focus on this but until you move to the cloud you won't know.

Additionally the typical workloads that run on our HPC system are often some badly maintained bioinformatics software or R/perl/pythong throwaway scripts and often enough a typo in the script causes the entire pipeline to fail after days of running on the HPC system and needs to be restarted (maybe even multiple times). Again on the on-prem system you have wasted electricity (bad enough) but in the cloud you have to pay the computing costs of the failed runs. Again cost transparency might force to fix this but the users are not software engineers.

One thing that the cloud is really good at, is elasticity and access to new hardware. We have seen for example a shift of workloads from pure CPUs to GPUs. A new CryoEM microscope was installed where the downstream analysis is relying heavily on GPUs, more and more resaerch groups run Alpafold predictions and also NGS analysis is now using GPUs. We have around 100 GPUs and average utlizations has increased to 80-90% and the users are complaining about long waiting/queueing times for their GPU jobs. For this bursting to the cloud would be nice, however GPUs are prohibitively expensive in the cloud unfortunately and the above mentioned caveats regarding job resource efficiencies still apply.

One thing that will hurt on-prem HPC systems tough are the increased electricity prices. We are now taking measures to actively save energy (i.e. by powering down idle nodes and powering them up again when jobs are scheduled). As far as I can tell the big cloud providers (AWS, etc) haven't increased the prices yet either because they cover elecriticity cost increase with their profit margins or they are not affected as much because they have better deals with elecricity providers.

Re: AWS doesn't make sense for scientific computing

#156

Its much more complex than described. The author is making a brilliant argument for getting a secondhand workstation and shoving under their desk. If you are doing multi machine batch style processing, then you won't be using ondemand, you'd use the spot pricing. The missing argument in that part is storage costs. Managing a high speed, highly available synchronous file system that can do a sustained 50gb/sec is hard…

Checkout Apache Iceberg which makes it fairly trivial to get high throughput from S3 without much fine-tuning. Bursts from 0 to 50Gbps should be possible from S3 without much effort, just have object sizes that are in the NN+ MiB range. Personally, Lustre is a mess, it's expensive and even more pain to fine-tune.

From https://iceberg.apache.org

> Iceberg is a high-performance format for huge analytic tables.

How would that help speedup S3? Genuine question?

Re: AWS doesn't make sense for scientific computing

#157

Is genomic code typically distributed-memory parallel? I'm under the impression that it is more like batch processing, not a ton of node-to-node communication but you want lots of bandwidth and storage. If you are doing a big distributed-memory numerical simulation, on the other hand, you probably want infiniband I guess. AWS seems like an OK fit for the former, maybe not great for the latter...

The fastest way to do a lot of genomics stuff is with FPGA accelerators, which also aren't used by most of the other tenants in a multi-tenant scientific computing center. The cloud is perfect for that kind of work.

That's interesting. It is sort of funny that I was right (putting genomics in the "maybe good for cloud" bucket) for the wrong reason (characterizing it as more suited for general-purpose commodity resources, rather than suited for the more niche FPGA platform).

Re: AWS doesn't make sense for scientific computing

#158
Cloud never has made sense for scientific computing. Renting someone else's big computer makes good sense in a business setting where you are not paying for your peak capacity when you are not using it, and you are not losing revenue by underestimating whatever the peak capacity the market happens to dictate.

For business, outsourcing compute cost center eliminates both cost and risk for a big win each quarter.

Scientists never say, Gee it isn't the holiday season, guess we better scale things back.

Instead they will always tend to push whatever compute limit there is, it is kinda in the job description.

As for the grant argument, that is letting the tool shape the hand.

business-science is not science, we will pay now or pay later.

Re: AWS doesn't make sense for scientific computing

#159
> Hardware is amortized over five years

hardware running 100% won't last five years

if hardware is not needed to be running 100% at full steam for five years, you can turn down instances on the cloud and you don't pay anything

in 2 years you'll be stuck with the same hardware, while on the cloud you follow cpu evolution as it arrives to the provider

all in all the comparison is too high level to be useful

Re: AWS doesn't make sense for scientific computing

#160
No way. I vehemently disagree.

When a company reached a certain mass, hardware cost is a factor that is considered but not a big factor.

The bigger problems are lost opportunity costs and unnecessary churns.

Businesses lose a lot when the product launch is delayed by a year simply because the hardware arrived late or have too many defects (Ask your hardware fulfillment people how many defective RAM and SSD they got per new shipment).

Churn can cost the business a lot as well. For example, imagine the model that everyone been using is trained in a Mac Pro under XYZ desk. And then when XYZ quit, s/he never properly backup the code and the model.

Bare metal allows for sloppiness that the cloud cannot afford to allow. Accountability and ownership is a lot more apparent in the cloud.

Post reply on HN