You can run on ARM servers in production. They're even cheaper than x86 servers. (Though also slower, at least AWS's version.)

Realistically, ARM is probably the future, and just needs something to push society in the direction of the future. A lot of people use Macs, so this forces people to become interested in switching, which has some value. Remember when the original iMac had USB instead of ADB ports? Everyone was mad about it. But USB was the future -- you can plug that iMac's mouse into pretty much any computer you have and it still works.

(I've been wanting an ARM desktop for a while, but it seems there is trouble standardizing something like BIOS/UEFI, and the CPUs you can buy are more expensive and slower than x86 alternatives. I'm also not sure if anyone ever decided what the standard "ARM" configuration looks like... binary calling conventions, endianness, supported instructions? But, if Apple can make a competitive ARM chip, so can others, and the standards will follow. We'll see!)

> You can run on ARM servers in production. They're even cheaper than x86 servers. (Though also slower, at least AWS's version.)

Where can I buy ARM server comparable with x86 server on performance? I'm not interested with clouds, I want bare metal server. I'm not aware of any server brand like HP or Dell producing ARM servers. I'm also not aware of any CPU manufacturer producing computer desktops with ARM comparable with x86, outside of Apple macs. I'm not convinced that ARM is the future. For me the future is both architectures co-existing.

> I'm not interested with clouds, I want bare metal server.

You can have both.

https://aws.amazon.com/blogs/aws/now-available-bare-metal-ar...

I promise that is not what 90% of people mean when they say they want bare metal, and not what 99% of people mean when they say they don't want "cloud"; it's still AWS's machine.

Honestly, if they mean "owned machine in colo" they should say that rather than "bare metal". Those are orthogonal concepts. (You can have VM instances on a private cloud on owned machines as well)

If you're actually interested in buying servers this is not a pedantic difference.

It wasn't though, the same Dockerfile, but not the same image. The images are ephemeral and stateless, being only a projection of the Dockerfile.

Running the same image on dev machine and prod was an illusion brought by the fact the underlying architecture was the same. It’s not reasonable to expect images to magically be cross-architecture.

> It also violates the idea of being able to run the exact same image on your laptop (ARM Mac) and in prod (x86 server).

99% of people are running node/python/RoR/PHP on Ubuntu/Debian/Arch. It works the same for most cases. (possible caveat: I'm not sure if numpy and TensorFlow is supported already but it probably is)

But for basic stuff, it's a non-issue

You still can't use the same container image across architectures, even if the important parts are interpreted code. You can package the architecture-independent parts for both x86 and ARM, of course, but as you sort of touch on, that still leaves dependency issues and surprise differences in the platform ("oh look, this is so fast on my mac where there's hardware acceleration for the C library used in this hot path" followed 3 weeks later by, "why is this so slow on our x86 servers?").