Analogy: "As a hobbyist rocket builder, what are reasons NOT to build a rocket hangar?" Sort of like: 1. Do you take 2 hours to spin up a server with a few we

Analogy: "As a hobbyist rocket builder, what are reasons NOT to build a rocket hangar?" Sort of like: 1. Do you take 2 hours to spin up a server with a few web apps. Maybe you'll have to do it 1 or 2 more times within the next year. 2. Take 200 hours to learn Docker, in order to be able to spin up that same server in about 10 seconds. You'll only have to do it 1 or 2 times within the next year. Whereas the real use case is #3, where you tack onto #2 the following: + where you have 20 developers + meanwhile 4 developers per year churn through your team + you have dev ops experts who can take advantage of all the connectivity & modularity of Docker & its ecosystem (including Kubernetes) In this case, it's useful to have people who know Docker. Whereas if you're not doing any of the things above (and/or other container-related activities), then no need to dig into it (unless it's for fun, which Docker is pretty fun to learn and can teach a dev new things). Mostly: The cost vs benefit does not exist at your scale. Its economics: Cost vs benefit. The cost of time to learn it and put it into practice (and understand its quirks), vs benefit of it on a prototype or small project is a negative relationship. Docker is cool, it's useful, but it's just an extra layer of stuff you won't need unless you need its extra dev ops benefits. That said, I don't need Docker, but I still find it fun & interesting to learn Docker. I've used it for tangential purposes: - Personal projects: such as experimenting with something new: to run Grafana or a new type of database that I don't want to install directly but want to play around with and even integrate into a project. - At work: to connect to a database