AWS makes its own Arm CPUs default for ElastiCache in-memory data store service | Hacker News Reader

AWS makes its own Arm CPUs default for ElastiCache in-memory data store service

theregister.com

25 pointstimthorn8 comments

It's not really surprising. From what I've heard from former co-workers there, there's a big push on all services to evaluate and ideally migrate to ARM by default for their control plane services.

That says quite a bit about the savings Amazon is seeing from them, given how notoriously conservative they are over tech (I know they produce bleeding edge stuff, but internal tech approaches are super conservative, with good reason)

"Intel and AMD won’t like that, because not many users are ready to run code cut for Arm so they’re not yet a huge threat to sales of Xeon or EPYC CPUs."

The only service this applies to is EC2. Every other AWS service runs on Amazon's own code, and users won't care about the hardware as long as the API stays the same.

Strictly speaking, that applies transitively to the many AWS services layered on EC2 that allow/depend on BYO binaries, such as Lambda, EMR, ECS, EKS, Erratic Beanstalk and more besides.

Kind of - you can BYO binaries but the vast majority of the time you'll be BYO code instead. A Django project doesn't care what architecture it runs on so long as Python is compiled for it, ditto with Node and RoR and all the other interpreted languages. Java should also be fine as long as the runtime works on the arch since it's only bytecode anyways. Really the only people who would need to care are the people deploying Rust and C binaries, but I'd guess those people are already used to compiling for different architectures anyways (you need to build for Amazon's Linux AMI to run a binary on Lambda, for example).

I'm speaking from experience; since I'm actually using some of those I can tell you that assumption doesn't hold in the real world.

It's a myth that programs written for interpreted/dynamic/scripting languages are automatically portable, because many nontrivial uses pull in FFI-based or otherwise compiled extensions, so a deployment package does include platform-specific code. I can't speak for Django but this is definitely the case for Rails: a Rails application that's been bundled with its dependencies for deployment in Lambda includes x86-64 binaries. I just checked one of our standard templates, and it has 18 gems using compiled extensions. I'm reasonably sure I'd find similar if I go look through our Node stuff, and in any case, it's a documented concern[1].

The point being, where they don't already have it, such AWS services will likely add platform/arch metadata to their deployment packaging, and users shouldn't assume a seamless transition when the option to switch becomes available.

[1] https://aws.amazon.com/blogs/compute/nodejs-packages-in-lamb...

Ah, this is a fair point. I hadn't considered this, but my build process does indeed include a compilation step done on Amazon Linux to pull in all the packages and build them with node-gyp. That then gets uploaded to Lambda.

So you're correct that people will have to care if they don't already generate builds through CI; otherwise it should be relatively simple so long as none of the included packages drop down to assembly for some weird reason.

Not sure if they've done it yet, but ELBs are going to be on Arm too.

https://aws.amazon.com/blogs/aws/coming-soon-graviton2-power...

Graviton2 is great. We had similar experiences with KeyDB, and while you still get better peak performance on Intel - the Graviton is more economical if you don’t need absolute top end perf.

Reply on news.ycombinator.com