It depends on what the build process looks like, but I find buildx to be really, really slow–and that can be costly if you're paying for the compute time to do that. (The slow part is if you have to do any compiling for the non-native platform on your host. I have tested this doing x86 compilation on an M1 system, and Arm complication on an x86 system.)
AWS has a guide for using CodeBuild where you split the work to build each Docker image using the platform of its target, and then create a manifest at the end.
I also took a similar approach using CircleCI. A multi-arch build can take 5 minutes using parallel, native builds instead of 45+ minutes (it actually timed out).
Pros: way faster and cheaper builds if you have to pay for the compute time
Cons: a much more complicated setup
I agree that buildx is really slow for multiplatform images, the advantage is provides is that if you want don't have a machines for that architecture you cannot build nativly, and with buildx you can build images for multiple platforms on your own self hosted runner.
I agree with the cons and pros you mentioned, but I am hoping that the qemu and buildx will continue to improve.
True – I'm definitely glad it's there, and I would totally use it for personal/casual projects where I likely won't have a fancy AWS/CircleCI/etc setup. At work though, its use would actually add to our bill and hold things up for teams.
AWS has a guide for using CodeBuild where you split the work to build each Docker image using the platform of its target, and then create a manifest at the end.
https://aws.amazon.com/blogs/devops/creating-multi-architect...
I also took a similar approach using CircleCI. A multi-arch build can take 5 minutes using parallel, native builds instead of 45+ minutes (it actually timed out).
Pros: way faster and cheaper builds if you have to pay for the compute time Cons: a much more complicated setup