4 ms·

Bad habits. There are people who with a straight face claim configuration management is unnecessary if you have a single shell script, aka Dockerfile. Over-sim

Bad habits. There are people who with a straight face claim configuration management is unnecessary if you have a single shell script, aka Dockerfile. Over-simplicity becoming complexity. You used to be able to write an app in C, pre-build it for a dozen platforms, then run it on a dozen platforms. Now you have to run everything on one platform (a virtualized containerized Linux environment) because anything else is literally impossible. You can still run the app anywhere - it just has five or six layers of virtualization, abstraction and tooling now. More complexity. Containers are supposed to just be processes, but you can't run them without preparing the host OS first, and you can't really use them en-masse without a complex scheduler and tooling. Nobody mentions it, but be careful your disks don't fill up just from deploying regularly. People think containers "cost almost nothing", and then all of their over-use of containers results in resource drain from the 15 million things necessary to configure and build and deploy and manage the things across distributed clusters. It's more resource-intense than people advertise. The container is supposed to be this read-only isolated self-sufficient jail, so good luck getting anything out of it without a bunch of hoops. You seriously need to specify 50 different config values just to do simple things like networking, writing to a persistent disk, picking what to run or stop, interacting with other apps. People say "a container is just another process" - except each one may be using an entirely different Linux distribution worth of software dependencies. And you still have to track what containers you're running, because you will depend on X release of Y container. Functionally speaking, containers are almost like a VM inside a VM. It gets that obtuse. I don't know that devs are actually saving time using containers vs a single dev platform. I think the problem all along was nobody knows how to maintain platforms, so they literally create and throw away whole platforms every time they build an app. Most of these comments are about Docker, but not necessarily specific to it in practice.

sedachv 9y ago
> There are people who with a straight face claim configuration management is unnecessary if you have a single shell script, aka Dockerfile. Apparently it is not only unnecessary, it is an anti-pattern: https://www.socallinuxexpo.org/scale/15x/presentations/configuration-management-anti-pattern https://www.socallinuxexpo.org/scale/15x/presentations/confi... > You used to be able to write an app in C, pre-build it for a dozen platforms, then run it on a dozen platforms. Now you have to run everything on one platform (a virtualized containerized Linux environment) because anything else is literally impossible. You can still run the app anywhere - it just has five or six layers of virtualization, abstraction and tooling now. I see more and more "here is a Docker image!" things pop up for tiny shell script utilities on github. It's like autotools with 100x the complexity and "portable" to exactly one platform. People have no clue what they are doing, they just want any excuse to use Docker. > The container is supposed to be this read-only isolated self-sufficient jail, so good luck getting anything out of it without a bunch of hoops. You seriously need to specify 50 different config values just to do simple things like networking, writing to a persistent disk, picking what to run or stop, interacting with other apps. This is my biggest pain point with containers, and where I feel Docker marketing is lying the most. Docker is pitched as making development easier, when in fact containers significantly impede debugging. You even need special tools (like https://github.com/emacs-pe/docker-tramp.el https://github.com/emacs-pe/docker-tramp.el) to do the most basic tasks like look at files. The marketing hype is that all you need to solve production problems is a log server and a few line graphs of metrics (better hope you instrument your app code for the right metrics...). Add in microservices and now you need distributed tracing too. This extra infrastructure is a ton of work to set up for small apps.

sedachv 9y ago

> There are people who with a straight face claim configuration management is unnecessary if you have a single shell script, aka Dockerfile. Apparently it is not only unnecessary, it is an anti-pattern: https://www.socallinuxexpo.org/scale/15x/presentations/configuration-management-anti-pattern https://www.socallinuxexpo.org/scale/15x/presentations/confi... > You used to be able to write an app in C, pre-build it for a dozen platforms, then run it on a dozen platforms. Now you have to run everything on one platform (a virtualized containerized Linux environment) because anything else is literally impossible. You can still run the app anywhere - it just has five or six layers of virtualization, abstraction and tooling now. I see more and more "here is a Docker image!" things pop up for tiny shell script utilities on github. It's like autotools with 100x the complexity and "portable" to exactly one platform. People have no clue what they are doing, they just want any excuse to use Docker. > The container is supposed to be this read-only isolated self-sufficient jail, so good luck getting anything out of it without a bunch of hoops. You seriously need to specify 50 different config values just to do simple things like networking, writing to a persistent disk, picking what to run or stop, interacting with other apps. This is my biggest pain point with containers, and where I feel Docker marketing is lying the most. Docker is pitched as making development easier, when in fact containers significantly impede debugging. You even need special tools (like https://github.com/emacs-pe/docker-tramp.el https://github.com/emacs-pe/docker-tramp.el) to do the most basic tasks like look at files. The marketing hype is that all you need to solve production problems is a log server and a few line graphs of metrics (better hope you instrument your app code for the right metrics...). Add in microservices and now you need distributed tracing too. This extra infrastructure is a ton of work to set up for small apps.