Q: Should we put our system on Docker? We hear it makes deployment easier.
A: Let's not decide just yet. Give me three numbers first, then we'll talk.
Q: Which three?
A: One — today, how long does a deploy take, from packaging to a page that opens? Two — how many releases a year? Three — when a deploy fails, who crawls out of bed to deal with it?
The client did the math: 20 minutes, 6 releases a year, one ops person — occasionally the client himself.
That Time, the Answer Was No
Not because Docker is bad. With those three numbers on the table, the pain clearly wasn't in deployment. Twenty minutes times 6 is two hours a year. If you want savings, removing the two most error-prone steps inside those 20 minutes pays off faster: someone hand-editing config files, and rollback done by digging through last backup directories.
We did two small things. Deploy scripts went into Git, with the server copy read-only — same principle as the crontab move earlier. And we added a rollback script: pass it a version number and you're back on the previous release, no manual Nginx weight fiddling. About a day and a half of work.
Q: So when should we do it?
A: A few signals. Deploy frequency going from 6 a year to twice a week. The same codebase needing to run on three or more machines with different configs. People starting to argue over "but it works on my machine." Or needing two PHP versions side by side. Once two or more of these show up, containerization saves more than deploy time — it buys environment consistency.
Q: Isn't earlier better, so we're not stuck migrating later?
A: Quite the opposite. Containerizing while the system's structure is still changing is like renovating while replacing the foundation. We've seen a project where the containers were in, but the database lived in a container and uploads sat on a local disk — every release needed a manual data shuffle, more convoluted than before they started.
Q: What happened six months later?
A: Six months later the client raised it again themselves. By then they'd added two machines, hired a second ops person, and moved to biweekly releases. All three numbers had changed, so we did it together — starting with the stateless layer only, database kept outside. This time nobody hesitated.
A Frank Observation
When technology choices stall, it's rarely because someone doesn't understand — it's that nobody has pinned down where it actually hurts today. That conversation took 40 minutes, and 30 of them were spent counting those three numbers.
