I keep hearing this mantra of "same environment". But is it really ever the same? One of my previous workplaces insisted on everyone having bloody openshift locally, so your dev env supposed to be closer to prod. Guess what, it still wasn't by a long stretch, yet it ate half of usable laptop's RAM and was slow like hell.

Most people quietly switched to docker-compose templates shared through private repos within a month for quick local runs and then tested end-to-end in dev cluster when it was mature enough.

What I'm saying here is that architecture mismatch is really just another variable, and purpose of docker locally nowadays is not to replicate prod. That is unachievable and the sooner one accepts it the better. Still it's the best way so far to keep DLL hell at bay.

It defeats _one_ of the purposes of using Docker for development.

I expect that the official M1-supporting Docker Desktop will eventually, given a dual-arch image, allow you to choose which architecture to use. (One would run natively, the other under emulation)

There are situations where I'd use this feature, but 90% of the time I'd be fine using arm images locally and deploying x64.

(I could also imagine this working the other way -- an x86 dev machine and an arm deployment target -- which I think to some degree is supported by Docker today)

At least on AWS, it's slightly cheaper to deploy ARM servers. Look for this problem to also get solved on the server side by more ARM servers being put into production.

Isn't the point that the environment is very close (and the M1 may be a lot faster than a comparable machine) and that the CI will test the final code on x86 before deployment?

It's not ever the same, that's what qa/staging is for. Paired with ci and good Integration tests it's still works. Simplicity in a local dev env is king.

That was already a bad reason to start using Docker anyway, instead of fixing the devenv, yet another workaround.

As Java/.NET dev having heterogeneity between environments was never an issue.