Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching to AWS Graviton slashed our infrastructure bill

squeaky.ai

Post reply on HN
Print view View original

101–110 of 140 posts

Re: Switching to AWS Graviton slashed our infrastructure bill

#101

Post by jiggawatts »

makestuff wrote: post #58
matt-p wrote: post #10

Imagine how much they'd save by not using AWS in the first place

I have only ever used AWS, what is the go to cloud provider these days? I know GCP and Azure are catching up, but are people just going back to renting some boxes in a data center and just hosting their stuff on there?

Some orgs deploy Kubernetes on clusters of "bare metal" servers, which is very efficient and cost effective if done above some minimum scale that amortises the cost of the SREs needed to operate the beast.

However, the cloud is not just about compute. The ability to have zone- and region- redundant blob storage that scales to petabytes and has "many nines" of availability is very hard to emulate. Similarly, there are many other turnkey technologies in most clouds that have only complex and expensive on-prem versions.

For example, something like Azure Storage Account "Queues" are basically free and very easy to set up and use. The second you start looking at a highly available cluster of servers providing a queue or service bus, the minimum cost is orders of magnitude higher than a small Azure storage account.

And so on, and so forth...

Re: Switching to AWS Graviton slashed our infrastructure bill

#102

Post by likeabbas »

Dowwie wrote: post #20
andrewstuart wrote: post #4

I found graviton to be a mixed bag. It was certainly extremely fast when using the very high end instances and I tested it successfully using a Rust based message queue system I was writing and it got some ridiculously fast number like 8 million messages a second, from memory, using the fastest possible graviton instance (this was about 18 months ago). I did try to switch some of my database servers to it a couple of…

I'm curious about that Rust-based message queue system

fluvio.io ?

Re: Switching to AWS Graviton slashed our infrastructure bill

#103

Post by arecurrence »

_joel wrote: post #67
arecurrence wrote: post #40

Earlier quoted context omitted.

Completely agree... the only exception I've run into is that for small operations build tooling often doesn't work well with arm64. EG: GitHub actions can build a container in a few minutes in x64 or 35 minutes in arm64... likewise aws-cdk literally could not run an arm64 fargate ecs deployment for months after support was added (They simply did not support the required attribute in the container definition). I would…

Are you building on arm64 natively or via qemu. A few mins vs 35 for the same roughish spec of CPU, seems a bit off, even with optimisation considerations. I've found arm64 builds on amd64 take longer when using one build context/arch (but doing multiple platforms), but that's as it's being emulated. It's the oppostite on my M1, the buildx amd64 takes longer.

oh it was with buildx (which uses qemu) as GitHub Actions run in x64. I was showing a specific example of arm64 build tooling challenges small startups encounter (Github Actions lack of arm job runners in this case). My arm64 builds on arm64 architecture scream.

Re: Switching to AWS Graviton slashed our infrastructure bill

#104

Post by Terretta »

StillBored wrote: post #93
Terretta wrote: post #8

The marriage of an all arm64 dev env and a Graviton op env is a match made in heaven. Everyone please do this so we collectively fix all the things to work with this. :-)

I upvoted to compensate for the downvotes, but I really curious why you think its a match made in heaven vs just using a random x86 laptop and an x86 cloud instance? My take, is that you want to cheer Arm on in this space, not because there is some huge technical advantage, or the arch meets your fancy or whatever, but because it is adding another competitor to the space. One that brings its own baggage, but having t…

40% cost savings and better perf

also I didn't mean all the things have to work like this only, I meant all the things that are broken need to be fixed

I was not clear

Re: Switching to AWS Graviton slashed our infrastructure bill

#105

Post by xenophonf »

gryf wrote: post #56
throwaway821909 wrote: post #54

Earlier quoted context omitted.

Can you use a plain Hyper-V VM? i.e. with Hyper-V Manager

Tried that but unfortunately there are some painful addressing and routing issues when you are subjected to when dealign with a corporate always on VPN. Ergo you can't actually contact clusters which you have to admin via kubectl.

What's stopping you from running kubectl.exe or Cygwin? Frankly, I still think Cygwin's better than WSL in many ways.

Re: Switching to AWS Graviton slashed our infrastructure bill

#106

Post by scarface74 »

lostmsu wrote: post #79
scarface74 wrote: post #62

Earlier quoted context omitted.

Do you propose they carry desktops back and forth from their office and to conference rooms?

Every conference room could have a device to facilitate presentation.

What device is going to have my PowerPoint slides, my IDE, my logged in AWS account, etc and everything else I need for demos?

Where I work, every conference room in every corporate office has a TV and a dongle that you can plug in via either HDMI or USB C.

Re: Switching to AWS Graviton slashed our infrastructure bill

#107

Post by joshspankit »

jiggawatts wrote: post #97
yazaddaruvala wrote: post #80

Earlier quoted context omitted.

FWIW, in these situations you're better off proposing: "I'm going to reuse this VM, to help our ... fleet scale better." That way your management continues to use their allocated budget, and your real prod systems work slightly better (also will eventually require less additional $ to scale up - helping the company i.e. shareholders). The thing to remember: You would assume all middle management really manages are a…

> help our ... fleet scale better." Heh, I tried that too! I found a lot of setups using old HDD disks that were at 100% of their IOPS limits and CPUs that were idle. When they were built, Azure didn't have Premium SSD, so that's forgivable. I offered to rearrange where the expenditure goes, such that they have newer and faster CPUs, Premium SSD, but fewer cores which means a reduction in licensing costs. Cost neutra…

It’s as though they interpreted David Graeber’s Bullshit Jobs as a managerial playbook

Re: Switching to AWS Graviton slashed our infrastructure bill

#108

Post by jdmichal »

neodypsis wrote: post #92
andrewstuart wrote: post #6

Earlier quoted context omitted.

pg

Was this a while ago or was it a recent experience? I'm asking because I'm planning on using a serverless instance of PG and was interested in trying the ARM64 version.

We've been running RDS PostgreSQL on r6g instances for the past few months with no issues.

Re: Switching to AWS Graviton slashed our infrastructure bill

#109

Post by _joel »

arecurrence wrote: post #103
_joel wrote: post #67

Earlier quoted context omitted.

Are you building on arm64 natively or via qemu. A few mins vs 35 for the same roughish spec of CPU, seems a bit off, even with optimisation considerations. I've found arm64 builds on amd64 take longer when using one build context/arch (but doing multiple platforms), but that's as it's being emulated. It's the oppostite on my M1, the buildx amd64 takes longer.

oh it was with buildx (which uses qemu) as GitHub Actions run in x64. I was showing a specific example of arm64 build tooling challenges small startups encounter (Github Actions lack of arm job runners in this case). My arm64 builds on arm64 architecture scream.

You can do a self hosted runner on arm though, even on a Raspberry Pi (if inclined), so not sure it's prohibitively expensive to a startup, could even afford a spot graviton :D

I've got to say though, I've not experience that delta in build times, even emulated on my machine.

Re: Switching to AWS Graviton slashed our infrastructure bill

#110

Post by sbarre »

gryf wrote: post #53
sbarre wrote: post #47

Earlier quoted context omitted.

For what it's worth, I work in a large 30,000 employee company. Everyone gets a Windows machine by default. 6 years ago our department of 200 people "went rogue" and started provisioning Macs, because it was the only way we could hire developers and provide a good developer experience for the work we were doing. This took some convincing, but it was possible. We agreed to be unsupported by the in-house help desk, but…

Unfortunately we're in a regulated industry so getting a PO signed off for one Mac is nigh on impossible without involving the entire corporate machinery.

We are also a highly regulated industry. Not finance but pretty close.

I sympathize with you though, it sounds like there's no will to do it, which sucks :(

Post reply on HN