3 ms·

Not sure what 'containerize' means in this context, but adding a Dockerfile, building the image and changing your box to use docker should definitely not reduce

Not sure what 'containerize' means in this context, but adding a Dockerfile, building the image and changing your box to use docker should definitely not reduce velocity or increase deploy time to half an hour...

deckard1 6y ago
it's never that simple. With docker you have to worry about how containers talk to each other. Which at a bare minimum means exposing ports and adding a network layer. Suddenly you find yourself in the weeds with docker-compose and debating whether or not it's actually suitable for a production environment, when they recommend using swarm instead. Then you find out swarm is on shaky ground and now you're hearing about nomad and ten different other solutions just to avoid k8s. Infrastructure-as-code is a wonderful idea. But the reality is it's a full time job. There will always be orphaned containers and things that need cleaned up and automated. And if you don't, then your environment will run out of space or RAM and all devs will be sitting there doing nothing. Building docker images also takes time, especially if you don't optimize the image. The simplest deploy workflow I've seen was a git hook (post-update, I think) that ran a few commands when the repo is updated. It'd really be hard to make up for the efficiency of that workflow after messing about with docker for days.
- dbmikus 6y ago
  If it's a monolith you don't have to worry about composing multiple containers. I've put a monolith in Docker so I could plop it on Google Cloud Run.
- slow_donkey 6y ago
  There's a smell if containers are forcing you to radically change your ops strategy. Networking between boxes doesn't change, networking between processes on the same boxes is slightly more complicated but you can always fallback to host if really needed. None of that pushes you to use kube / swarm, they solve completely different issues.

deckard1 6y ago

it's never that simple. With docker you have to worry about how containers talk to each other. Which at a bare minimum means exposing ports and adding a network layer. Suddenly you find yourself in the weeds with docker-compose and debating whether or not it's actually suitable for a production environment, when they recommend using swarm instead. Then you find out swarm is on shaky ground and now you're hearing about nomad and ten different other solutions just to avoid k8s. Infrastructure-as-code is a wonderful idea. But the reality is it's a full time job. There will always be orphaned containers and things that need cleaned up and automated. And if you don't, then your environment will run out of space or RAM and all devs will be sitting there doing nothing. Building docker images also takes time, especially if you don't optimize the image. The simplest deploy workflow I've seen was a git hook (post-update, I think) that ran a few commands when the repo is updated. It'd really be hard to make up for the efficiency of that workflow after messing about with docker for days.

dbmikus 6y ago
If it's a monolith you don't have to worry about composing multiple containers. I've put a monolith in Docker so I could plop it on Google Cloud Run.
slow_donkey 6y ago
There's a smell if containers are forcing you to radically change your ops strategy. Networking between boxes doesn't change, networking between processes on the same boxes is slightly more complicated but you can always fallback to host if really needed. None of that pushes you to use kube / swarm, they solve completely different issues.