[johnduhart]

I've been extremely skeptical of ARM EC2 instance types getting any sort of traction, as I don't believe most companies would bother to port their software to another architecture. This line pointed out something I never considered:

> Based on these results, we are planning to use these instances to power Amazon EMR, Elastic Load Balancing, Amazon ElastiCache, and other AWS services.

Amazon running their PaaS services on top of their own silicon is really an interesting prospect. I wonder how much hardware is allocated to running their platform services vs. EC2 instances for customers, as there's definitely an opportunity for Amazon to port these workloads and decrease the dependence on Intel.

[BenoitP]

> as I don't believe most companies would bother to port their software to another architecture

For a Java/Node/Python application, this means changing one line in a docker file, and running preprod/integration tests.

[adev_]

> For a Java/Node/Python application, this means changing one line in a docker file, and running preprod/integration tests.

Ironically, the theory contradicts the practice and native code is often the easiest to port on new archs.

I have ported to ppc64be, POWER, armv7 and aarch64 several HPC stacks, it is often the native app made in C/C++/Fortran which is the easiest to port/recompile/cross-compile simply because:

- Their build system has been made from the beginning to handle multiple architectures.

- The compilers for C/C++ are the first thing to be ported and tested on a new arch.

At the opposite, python / node / java embed pretty often native modules hidden somewhere, with hand rolled compile scripts in pip / npm / maven and which are everything excepted robust and portable.

[matt2000]

This hasn't been the case for most Java projects I deal with, native dependencies are fairly rare. Can't comment on Python or Node.

[zten]

Python libraries frequently aren't only in Python, and use native bindings. Node packages less so, but it still happens.

Java might surprise you, too, especially on EMR. I've found math, compression, and machine learning libraries that reach out to native code using JNI.

[colechristensen]

All of the major distribution families support Arm archs and the heavy lifting for most of the things that reach out to native code have already been ported.

Native libraries are most often used to make boring things faster, use popular C libraries, and are already ported.

Unless your in-house library is using native bindings for custom code, it very likely will be a drop-in replacement.

ARM isn't so esoteric these days like it might have been 5-10 years ago.

[zten]

Definitely exciting news! For some reason I was picturing that you might have difficulty building things like xgboost or getting an optimized version of BLAS, but that doesn't seem to be the case. (the former is supported and the latter is important enough that ARM ships their own version)

[Dunedan]

That's probably why EMR doesn't support ARM-based instances [1].

[1]: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-s...

[_msw_]

Disclosure: I work at AWS

Stay tuned!

[Matthias247]

Assuming you have no native dependencies, which most bigger applications have somewhere in their dependency graph.

[sanxiyn]

This is why writing 100% Pure Java is so important.

[sliken]

Heh, and useless. I was about 20 lines into small example. I needed the stat() command... not in java.... sigh.

[stevekemp]

I rented a cheap ARM-based machine last year, just for running off-site monitoring from.

My monitoring application was written in golang, and that made cross-compilation trivial - although I guess I'd made a little extra-effort to keep it all native and avoid CGO.

[enitihas]

The performance won't be the same though, as things might be much more optimised for x86-64.

[solatic]

It's just a question of whether your company is willing to embrace vendor lock-in with AWS. Sure you can do lots of cool things with proprietary AWS services. Probably more than a few customers can save a boatload of money by porting legacy workloads to ARM. But the price is being utterly dependent on AWS and losing control over your cloud bill.

That's not necessarily a bad trade-off, mind you, it depends on what business you're in, what your architecture looks like, and what your org's capabilities are. But it is a trade-off and customers should be mindful of the downsides when they make these decisions.

[aripickar]

I don't know what the total breakdown is, but at AWS we get a bill every month for our own spend, and managers get it for the whole team. We don't have to pay it, obviously, but it's to show what the spend is.

[foolfoolz]

it’s really cool that AWS internally has this as a feature but there’s entire startups with good funding and customers that exist to solve this exact shortcoming of AWS billing

[baybal2]

> I've been extremely skeptical of ARM EC2 instance types getting any sort of traction, as I don't believe most companies would bother to port their software to another architecture.

I think you miss a much bigger elephant in the room: Amazon is too small to get good offer when negotiating with fabs.

May sound weird to people from silicon valley.

Fabs, above all, like reliable clients with stable business because cashflow certainty is of vital importance in the fab business. Small orders are invariably very pricey, but so are big orders from companies that are "come and go" clients, whose own prospects and plans are uncertain.

[cowsandmilk]

> Amazon is too small to get good offer when negotiating with fabs.

Amazon literally has custom silicon in every machine they add to AWS now in the form of the nitro system. They are pretty damn big customers that are not “come and go”. If ELBs start using graviton, that’s a sizable subset of the instances in AWS data centers that isn’t even reliant on external customer demand.

[baybal2]

Nitro is an FPGA card as I was told, a very different kind of beast.

> damn big customers that are not “come and go”.

I think, they are. There is no guarantee for a FAB that they will not revert to vendor CPUs if over the years their team can't keep their design competitive. And their accounting...

Only way to guarantee so if for them to do a contract with a cash bond — a practice not uncommon in the industry, but the digit will be much bigger than for, say, a commodity 65nm asic, and amount of wafers they need.