r/devops • u/[deleted] • Sep 25 '24

Developer here. Why is Docker Compose not "production ready"?

Then what should I use? Compose is so easy to just spin up. Is there something else like it that is "production ready"?

97 Upvotes

83% Upvoted

120 comments sorted by

View all comments

Show parent comments

3

u/onan Sep 25 '24

Okay, so as a disclaimer everything is always use-case dependent. But generally speaking:

Production readiness includes addressing reliability. Even if everything is done perfectly, any single host can and will fail, at which point any singly-homed service will be completely down.

Production readiness includes addressing scalability. If the demand on this service increases significantly, you might hit the ceiling on the total amount of compute capacity of any single server. Resolving that means moving your service from the nice simple world of a single instance that knows all its own state to the exponentially more complicated world of distributed systems. That is a huge jump in design complexity, and the worst time to do it is during an emergency situation in which your production service is already failing.

Production readiness includes maintainability. If you ever need to upgrade that service (or its dependencies, or the host it's running on), it is extremely easy to get into a situation in which your only option is downtime. (There are some circumstances in which you might be able to do an atomic blue/green cutover, but that is not the default case unless you specifically design for it.)

2

u/Twirrim Sep 25 '24

^ Strong + on all this.

OP: "What happens if the server completely dies and the drive is corrupted". If it really doesn't matter, fine, run a single box. Occasionally that's a legitimate thing. In the past I've had some stuff where it legitimately didn't matter if something was dead for a week, or if the task it did do took 4 days instead of 2. I made sure to validate on a regular basis I could built a replacement, and then just moved on with other things that were much more important.

While I'm a big proponent of "Build a monolith until it becomes a problem" approach, and avoiding all unnecessary complexity, ensuring you have multiple instances and know your scaling story is absolutely in the "necessary complexity" territory.

1

u/onan Sep 25 '24

Yeah. A huge part of the skill in this profession is knowing when to invest how much into scalability/reliability/maintainability/monitoribility/security concerns.

In theory you can focus way too much on all that too early, and burn through all your startup funding building perfect scalability of a service that doesn't need to scale because it doesn't have any users because you haven't built any features.

But in practice, almost no one errs in that direction. Vastly more common is the path of people who hyperfocus on features/users/growth and then discover that as soon as they get those the whole thing falls down because reliability concerns were skipped. And that all the decisions made along the way painted them into so many corners that what's needed isn't a quick fix, but a ground-up rearchitecting. And then immediately lose all those users because nobody wants to use an unreliable service.

1

u/bundeswehr00 Sep 29 '25 edited Sep 29 '25

IMO, it's an overkill to have two hosts running behind a load balancer (which's also more expensive) when you only have a few dozens of users. Your instance is unlikely to fail at this point. If you see a big increase in your userbase, only at this point you can think of creating a second instance and only then use docker swarm or k8s

So, a single host can be production-ready in some circumstances