[HN Gopher] Cloud Provider Performance Comparison - Perl and More
___________________________________________________________________
Cloud Provider Performance Comparison - Perl and More
Author : mfontani
Score : 59 points
Date : 2022-03-07 14:44 UTC (8 hours ago)
(HTM) web link (blogs.perl.org)
(TXT) w3m dump (blogs.perl.org)
| hughrr wrote:
| So what this tells me is to buy a Mac mini and throw it in the
| corner of the office.
| deadmutex wrote:
| 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.
| jdvh wrote:
| 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.
| bushbaba wrote:
| 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.
| marcosdumay wrote:
| 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.
| hughrr wrote:
| 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.
| hughrr wrote:
| 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.
| vlovich123 wrote:
| 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).
| hughrr wrote:
| 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.
| getcrunk wrote:
| Well there you have it, if money isn't really an issue,
| the cliche works well, no one got fired for suggesting
| the cloud.
| getcrunk wrote:
| 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.
| karmeliet wrote:
| To be fair, to achieve the best multi-threaded performance in
| Azure the Dv2/Dsv2 version provides real cores and not threads.
| deltaci wrote:
| A similar comparison on CI workloads between desktop CPUs and
| Cloud(Azure) here: https://buildjet.com/for-github-
| actions/blog/a-performance-r...
| jeffbee wrote:
| 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.
| pid-1 wrote:
| 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.
| christophilus wrote:
| 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/
___________________________________________________________________
(page generated 2022-03-07 23:01 UTC)