Cloud Provider Performance Comparison – Perl and More | Hacker News Reader

Cloud Provider Performance Comparison – Perl and More

blogs.perl.org

70 pointsmfontani22 comments

That's awesome.

As consumers, we really need more independent benchmarks.

Reading bullshit like "AWS FOOBAR MAKES RUNNING MACHINE LEARNING IOT FINANCIAL MEDICAL APPLICATIONS 20% FASTER" doesn't help me to architect systems.

I was looking for side project ideas, thanks for providing one.

A similar comparison on CI workloads between desktop CPUs and Cloud(Azure) here: https://buildjet.com/for-github-actions/blog/a-performance-r...

I'd be interested in how Vultr compares. In my experience, they provide better bang for the buck vs the ones in this list. Also, there's a decent website for such benchmarks: https://www.vpsbenchmarks.com/

So what this tells me is to buy a Mac mini and throw it in the corner of the office.

I think part of the benefit you get from cloud is that if you only need 5 machines on the weekdays, but 10 machines on the weekends, you can easily scale up and down (instead of running and managing 10 machines). Another is reliability. It is not uncommon to have AWS/GCP instances stay on for years (since the underlying hardware is abstracted way), etc.

If you don't care about that, then the balances changes. If you're OK with 1 on prem server, you can just buy a AMD or Intel workstation, and tweak the hardware config (e.g. RAM, kernel, software, etc.), BIOS to your liking.

The cloud is so much more expensive than dedicated that you need far greater than 2x spikes in usage to make it worthwhile. For instance a video game that suddenly goes viral and you need to scale up 1000x overnight.

All cloud providers have pretty poor uptime records. Unless you set up multiple geo zones (extra complexity) your app will go down when aws-east does.

This. We pay $90k/yr just for an EC2 DB instance when the hardware would have cost us $50k for 3 years including the rack to stick it in and the transit.

It should be hybrid but everyone is busy sucking dick in the AWS fashion show.

It’s because of how accounting works (opex vs capex). I don’t know if there are tax reasons but a major reason opex is preferred to capex is that the former is tied directly to cash flows. Cash flows are the lifeblood of a business being profitable and makes it easy to balance costs and revenues whereas capex is a long term investment (ties up your capital).

There are secondary order effects going on here to explain this. Also, in your example the 50k number isn’t including the rack space rental costs, technicians to maintain the hardware, and OPs people to keep the deployed software running (software updates etc).

There's no tax or cash flow reason here. We have full autonomy and it's a fraction of our revenue and profit.

Rack space is included in my pricing there. As for technicians, we still have to employ the same number of people. Instead of having 2x DC techs and 2x DBAs we now have 4x devops engineers and 2x DBAs.

There is no saving here for us.

To note we have 12 of these nodes.

Well there you have it, if money isn't really an issue, the cliche works well, no one got fired for suggesting the cloud.

The way I look at it, try to go server less (jamstack) otherwise roll ur own distributed cdn and web servers (linode, digital ocean). For db use the cloud (dbaas). Once you have financial success (team of 3-5 on just ops) go in house.

It's relatively easy to run 10 machines. It's harder to run 100 machines. Even harder at 1000 machines. Then you start talking about 10,000+ machines and you're talking about a lot of people process & logistics, taking up your organizations time.

Then you talk about the bureaucracy an organization might have to provision new machines, or provide elasticity, and the hinderance it has on your development velocity.

It's at this scale the benefits of cloud really shine. The improvement to your development velocity, the shift from large CAPEX purchases to monthly opex, and the ease at which you can shift infrastructure direction.

It's similar to why a lot of businesses rent office space vs buying it outright. Or why you might pay for Bon Appetit to manage your cafeterias vs doing it yourself.

Really most organisations that end up in the cloud don't need elasticity. I have worked with a number of companies and they all run entirely static sized clusters. They don't even benefit from scaling down the cluster out of peak hours because their load is that small.

The CAPEX vs. OPEX argument does really not hold water. Scalable clouds are 100s to 1000s of times more expensive than using your own hardware. That's a pretty absurd ROI to get from a loan, even on high-interest economies.

Also renting non-scalable hardware is a perfectly viable option with costs more similar to owning it. Renting non-scalable hardware makes the same change from CAPEX into OPEX.

> Scalable clouds are 100s to 1000s of times more expensive than using your own hardware.

This is trending into hyperbole. a c6g.metal at AWS is $21,502 for a 3 year all upfront reserved instance. You're telling me you can pay just $21 for 3 years to get a 64 core/128gb machine racked in a datacenter?

Don't forget that if you have millions in EC2 spend that you'll be able to negotiate an additional discount.

You can get a 16c/64gb semi managed (break/fix hw) for ~ $40USD/mo of course this isn't the same IPC of a 64c cpu

Well, reserved instance means it's not scalable.

More generally, if you are renting entire servers, you are not on the scalable part of the cloud. You are getting something much closer to a colocated machine than to a lambda, and paying just a 3 to 4 times mark-up over a rented server (where the owner will care about the hardware, not you).

And, of course, you have to compute your network usage on the cloud. It's almost certainly already included on the renting.

we actually do lots of background ocr and only need a few "small" web machines 2cores 4gig totally enough (3 of them for ha) and the ocr processing takes like 8 cpu's 32gig to be "fast" and we need to spin up 2 or 3 additional machines between 9 and 18 o clock this is way way cheaper in the cloud, especially if you need "infinity" storage (without too much hurdles) (especially storage is still a hard problem)

> It is not uncommon to have AWS/GCP instances stay on for years (since the underlying hardware is abstracted way), etc.

This isn't hard to achieve with reasonable quality hardware and reliable power (which likely includes some amount of UPSes).

The scaling is nice, but as another poster said, 2x swing isn't enough; it would be more effective to buy for your peak and just let them idle on non-peak. If the swing is 10x, then cloud might be more economical. But you also need to build your system differently for frequent cluster changes, vs a stable cluster. Having a short cycle for hardware aquisition is nice, of course, if your load changes quickly.

The Amazon c6i and other _6i types are very fast and put the lie to the Graviton2 cost story, however, it's instructive that at this present moment all _6i instance types are stocked out in us-east-1. So, they're fast but you can't use 'em.

To be fair, to achieve the best multi-threaded performance in Azure the Dv2/Dsv2 version provides real cores and not threads.

Reply on news.ycombinator.com