IMO, shipping OCI images doesn't tether your backend to Docker anymore than shipping IDE configurations in your Git repository tether you to an IDE. You could tightly couple some feature to Docker, but the truth is that most of Docker's interface bits are actually pretty standard and therefore things you could find anywhere. The only real reason why Docker can't be "done" the way it is on Linux elsewhere is actually because of the unusual stable syscall interface that Linux provides; it allows the userlands ran by container runtimes to run directly against the kernel without caring too much about the userland being incompatible with the kernel. This doesn't hold for macOS, other BSDs, or Windows (though Windows does neatly abstract syscalls into system libraries, so it's not really that hard to deal with this problem on Windows, clearly.)

Therefore, if you use Docker 'idiomatically', configuring with environment variables, communicating over the network, and possibly using volumes for the filesystem, it doesn't make your actual backend code any less portable. If you want to doubly ensure this, don't actually tether your build/CI directly to Docker: You can always use a standard-ish shell script or another build system for the actual build process instead.

It's not as if you're locked to Linux though. Most if not all of my applications would run just fine on Windows if I wanted to. It's just that when I run them myself I use a container because I'm already choosing to use a Linux environment. That doesn't mean the application couldn't be shipped different but rather it is just an implementation detail

I don't think Linux is going away as the main server OS anytime soon, if ever. So that just leaves local dev

To that end- I prefer to just stick with modern languages whose first-party tooling makes them not really have to care what OS they're building/running on. That way you can work with the code and run it directly pretty much anywhere, and then if you reserve Dockerfiles for deployment (like in the OP), it'll always end up on a Linux box anyway so I wouldn't worry too much about it being Linux-specific

Yeah I'm not too worried about what's on the deployment end, but rather the dev environment. I don't want to spend any time wrestling Docker to get it to function smoothly on non-Linux operating systems.

Agree that it's a strong argument for using newer languages with good tooling and dependency management.

the dev workflow usage of docker is less about developing your own app locally and more about being able to mindlessly spin up dependencies - a seeded/sample copy of your prod database for testing, a Consul instance, the latest version of another team's app, etc.

You can just bind the dependencies that are running in Docker to local ports and run your app locally against them without having to docker build the app you're actually working on.

I've run Docker devenvs on Linux, Windows (via WSL2 so also Linux but only kinda) and Mac.

The closest I've come in years to having to really wrestle with it was the URL hacking needed to find the latest version willing to run on my 10-year-old MBP that I expect to run badly on anything newer than 10.13 - the installer was there on the website, just not linked I guess because they don't want the support requests. Once I actually found and installed it, it's been fine, except that it still prompts me to update and (like every Docker Desktop install) bugs me excessively for NPS scores.

It's, more or less, practically impossible to be OS agnostic for a backend with any sort of complexity. You can choose layers that try to abstract the OS layer away but sooner or later you're going to run into part of the abstraction that leaks. That plus the specialty nature of Windows/Mac hosting means your backend is gonna run on Linux.

It made sense at one point to use Macs but these days pretty much everything is electron or web based or has a Linux native binary. IMHO backend developers should use x64 linux. That's what your code is running on and using something different locally is just inviting problems.

The problem of course being that x86 linux on laptops is still and might always be terrible. Using an ARM Mac to develop your backend services is not ideal but probably still a better user experience than the 0.01% where a modern language does something vastly different on your local machine than in production (which is btw also very often ARM these days, at least on AWS).

I've used Ubuntu, WSL2 and currently a M1 mac and if I need to be mobile AT ALL with the machine I chose a Mac any day. For a desktop computer Ubuntu works great though

> That's what your code is running on and using something different locally is just inviting problems.

That’s quite the assumption. Graviton is very popular. I haven’t touched x64 stuff in a very long time. Perhaps such generalization is a bad idea.