3 ms·

> Once you know Docker you will realize that all other ways of deploying applications are outmoded. This is a strong and absolute statement to be making in a f

> Once you know Docker you will realize that all other ways of deploying applications are outmoded. This is a strong and absolute statement to be making in a field as broad and diverse as software engineering. My experience from being on both sides of these statements it that they're often wrong, or at least short sighted. In this case, while I get the packaging benefits of Docker, there are other ways to package applications that don't require as much extra software/virtualization/training. So the the question isn't as much about whether Docker/K8S/etc. provides useful benefits as whether or not those benefits are worth the associated costs. Nothing is free, after all, and particularly for small to moderate sized systems, the answer is often that the costs are too high. (And with hardware as good as it is these days, small-to-moderate is an awful lot of capacity.) I've personally gotten a lot of value out of packaging things up into an uber jar, setting up a standard install process/script, and then using the usual unix tooling (and init.d) to manage and run the thing. I guess that sounds super old fashioned, but the approach has been around a long time, is widely understood, and known to work in many, many, many worthwhile circumstances.

jschwartzi 7y ago
Indeed. Containers suck when your entire filesystem is 60 megabytes.
- rstupek 7y ago
  When I know how to use a hammer, everything starts looking like nails?
flowerlad 7y ago
When something breaks you log in to the machine and make incremental updates to fix it, right? This approach leads to non-reproducible deployment environments. Immutable systems are better, and Dockerfile is essentially a written record of how to reproduce the environment.
- mschaef 7y ago
  > When something breaks you log in to the machine and make incremental updates to fix it, right? Not generally, and you do a good job explaining why I don't in your next sentence. > This approach leads to non-reproducible deployment environments. It's true that there's some discipline involved, but it's not necessarily a huge amount. For me, what it tends to look like is a build that produces some sort of deployable artifact, an idempotent install script, and following standard Unix patterns. Except for maybe that last bit, this is exactly what you'd do in a Docker environment. And of course, Docker and the like are always still candidates for adoption, if the circumstances warrant. Part of what surprises me about conversations like this is that the idea of an environment in a known and stable state isn't a novel development. The question is really about what degree of environment stability you need to achieve to meet your requirements and then the specific tools and procedures you choose to adopt to meet that goal. Docker is once choice, but not the only choice, and even if you chose it, there is still a set of disciplines and procedures you'll need to follow manually for it to be effective.

jschwartzi 7y ago

Indeed. Containers suck when your entire filesystem is 60 megabytes.

rstupek 7y ago
When I know how to use a hammer, everything starts looking like nails?

flowerlad 7y ago

When something breaks you log in to the machine and make incremental updates to fix it, right? This approach leads to non-reproducible deployment environments. Immutable systems are better, and Dockerfile is essentially a written record of how to reproduce the environment.

mschaef 7y ago
> When something breaks you log in to the machine and make incremental updates to fix it, right? Not generally, and you do a good job explaining why I don't in your next sentence. > This approach leads to non-reproducible deployment environments. It's true that there's some discipline involved, but it's not necessarily a huge amount. For me, what it tends to look like is a build that produces some sort of deployable artifact, an idempotent install script, and following standard Unix patterns. Except for maybe that last bit, this is exactly what you'd do in a Docker environment. And of course, Docker and the like are always still candidates for adoption, if the circumstances warrant. Part of what surprises me about conversations like this is that the idea of an environment in a known and stable state isn't a novel development. The question is really about what degree of environment stability you need to achieve to meet your requirements and then the specific tools and procedures you choose to adopt to meet that goal. Docker is once choice, but not the only choice, and even if you chose it, there is still a set of disciplines and procedures you'll need to follow manually for it to be effective.