general/other Linux docker & docker compose in 2025

Imagine you have 10 microservices, a database, a message queue, an auth server, and a decent amount of frontend caching webservers (replicated to any amount needed). So every developer should in theory be able to boot this project on his machine.
I've had 1 game server with 2 daemons, a few other game servers, to a MySQL DB on one computer, and a periodic webserver daemon running on another MySQL DB on a different computer (and other stuff but +8 services, 2 DBs, 3 bare-metal computers); doing it the first time took a bit of time, but after noting it I can copy/paste that up within maybe 2 hours reproducibly :p

And it shouldn't be too, you simply don't have to waste a week because a particular service on a particular platform 'misbehaves'. Ideally, the very deployment scripts are reused for docker compose, and developer environment instantiation workload is gone, because it now derives from deployment, which is a major goal.
I'm not sure how it works real-world, but I feel system administrators and developers should be separate: A dev should focus on dev (not related to the OS), and the sysadmin should provide the environment for the dev (the sysadmin ideally prevents services from breaking for devs with testing). I guess it varies depending on what's being developed, but devs shouldn't need to be involved with Docker or the OS? It should just-work (I'm thinking something like a dev opening a laptop and firing up an IDE like IntelliJ to dev for Android: as long as the IDE works, anything lower-level shouldn't matter?)

Or might that be what DevOps is? (combo of dev and sysadmin?)
 
Software code always depends on the environment provided by OS - think of libraries and assistant services (like Redis, for example), as a bare example.

Docker address the biggest "it works on my computer" thing, letting people in charge of infrastructure run the same config and code as developer does on his computer.
 
Back
Top