Correct me if I am wrong, but isn't this whole dev-prod hardware parity argument contradict with the rise of Docker? I don't know much about ARM or CPU architectures in general, but I have never heard companies testing their Dockerized applications with Docker on different CPU architectures just to make sure that the application works as expected; it can be because everything is on x86 already, but at this point Docker is assumed to be a cross-platform dependency that will be the same between different hosts / OS / architectures. What prevents an abstraction layer like this to be used when it comes to ARM, hence making the whole "If you develop on x86, then you're going to want to deploy on x86" argument incorrect?
x86 Docker containers will not run on ARM, even if you install Docker for ARM. Docker is an entirely useless layer to support cross-architecture deployment.
Heck, even full-blown VMs (the real ones, that docker partially replaced) are mostly useless, for performance reasons.
The question was not specifically around Docker. What I wonder is, why wouldn't there be a seperate layer that abstracts away these platform differences, just like Docker did for operating systems?
Exactly, but I am not well-versed about the challanges and potential difference that might surface in kernel level and since Linus thinks it is not applicable, I was wondering if there is / would be an equivalent in the user space that would allow reproducibility for different architectures, something like architecture independent containers maybe. I would like to believe that we have come to a position where we can consider the application and platform as completely independent entities, which would eliminate these concerns regarding dev/prod parity possibly.
All these questions are mostly out of my ignorance though, I am trying to understand why the architecture change would require a huge effort as long as the underlying stuff is well abstracted.
