3 ms·

Real problem is low skilled developers. Most people working in tech these days have no idea how anything works. Everyone just hacks at the problem until they ge

Real problem is low skilled developers. Most people working in tech these days have no idea how anything works. Everyone just hacks at the problem until they get an output. There is no real engineering anymore. Tool like docker just try to mimic what the big tech companies are doing and hope for similar outputs. Most people who use docker don't know how much computing power and network usage they are wasting. Companies dont care as long as they can show some revenue. I can grantee 99% of projects using docker or any sort of containerization are wasting 99% of compute resources. Just waiting for those low skilled people to reply how wonderful docker is and to say "if its not working you are not doing it right "

maxk42 4y ago
Sad to see this is the lowest-voted comment here while simultaneously people above in the thread are replying with things like "I'm not sure how I'd provision servers without something like Docker" thereby proving your point. The vast majority of comments have nothing to do with containerization which is the purpose of Docker and unfortunately Docker just isn't that great at it. Meanwhile, they use it for configuration and in lieu of system administration which has multiple drawbacks and does indeed waste resources. I'm sure I'll be downvoted as well but thought I'd comment so you don't feel so alone. Keep doing things the right way.
- foverzar 4y ago
  > The vast majority of comments have nothing to do with containerization which is the purpose of Docker and unfortunately Docker just isn't that great at it. Meanwhile, they use it for configuration and in lieu of system administration which has multiple drawbacks and does indeed waste resources. Maybe that's because Docker largely iterates on existing container technology, and its purpose IS configuration? Nothing prevented you from containerizing processes before Docker, and initially it was merely a configuration frontend for LXC, which in turn handled all the containerization stuff. The actual value that Docker had added to good old jails/zones/chroot/lxc workflows is tooling and infrastructure for building, distributing and running images - there is nothing preventing you from creating simple similar tooling in plain Bash. Docker is largely about configuration and Dockerfiles, it doesn't create anything novel in regard to containerization tech. + It's just a popular standard.
throwawayu32 4y ago
Well that was humorous, with the username topping it off. The kicker is it remains a mystery whether this is satire or not.
KronisLV 4y ago
> I can grantee 99% of projects using docker or any sort of containerization are wasting 99% of compute resources. Genuine question: where would this overhead come from? I've used Docker (I know, Podman is supposedly better in some regards) for a while now on Windows for local development (Hyper-V back end) and on my servers (*nix boxes) and I haven't seen that many issues, even with something like Docker Swarm or Hashicorp Nomad for orchestration. I have, however, heard and/or experienced bad things in regards to: - disk I/O performance on Windows locally (WSL2 back end was slow for me, vice versa for others) - disk I/O performance on Mac - anything to do with Windows containers - the resource usage of Kubernetes (K3s, K0s, microk8s can help work around this, but not wholly; this might be the piece of software with the highest overhead in many stacks out there, if people go ahead and use it) Or are you referring to something else? Because frankly, a while back in my homelab I tried running a separate VM per project (not even per app) and at around 10 of those my disk I/O was so crippled the whole system was unusable - that might have been because the VMs were running full Debian instances and I had HDDs instead of SSDs (hey, I'm poor), as opposed to running somewhat cut down containers based on Debian or whatever (<40 PIDs). In contrast, containers have generally been pretty decent, especially because I can indicate CPU/RAM limits more easily than I otherwise could with systemd slices, which is helpful when something like MySQL decides that it would like to eat all of your RAM, or you need multiple MySQL instances on the same node for testing or different apps or whatever. My experience so far is that containers largely hold true to the promise of allowing an increased density without doing something a bit more shady like running one large MySQL instance with multiple users/DBs (the same would apply to PostgreSQL or any other "common" piece of multi-tenant software), which in practice makes debugging and updating everything a painful mess. I will concede that it's also a matter of ways of thinking about software, centralized vs decentralized (not even distributed systems per se) and all that. > Just waiting for those low skilled people to reply how wonderful docker is and to say "if its not working you are not doing it right" Bringing up the "No true Scotsman" argument ahead of the time is probably a good idea, but also makes this sound like something that's supposed to dismiss anyone who might have had different experiences from yours, which doesn't feel in good faith. I can see why running certain containers (e.g. anything built on Oracle Linux or other heavyweight base images for whatever reason) might coincide with large images and sluggish performance, or containers that have full init systems inside of them etc. The disk I/O issues on dev boxes should also need to be taken into account, of course. But in general, they seem "good enough" and I find it hard to believe the 99% figure. Maybe that's a broad statement/joke, not sure. Disclaimer: I've run software directly in the past, have used systemd (which I actually find passable, contrary to the seemingly popular belief), sysvinit, OpenRC, as well as have deployed it with Ansible. The learning curves of all those aside, I feel like software can run well with either approach, but I haven't run into that many issues with containers either. They do feel like a simplified init system that gives you lots of stuff out of the box and reduce thinking about your services as apps on a phone (standardized packages, common ways to configure etc.). Except for Kubernetes: most people out there don't need it, though I can understand why enterprises would go for it and have used it with varying success in the past. I'm also curious about how the people here feel about Vagrant and Packer, if you've any opinions on those.

maxk42 4y ago

Sad to see this is the lowest-voted comment here while simultaneously people above in the thread are replying with things like "I'm not sure how I'd provision servers without something like Docker" thereby proving your point. The vast majority of comments have nothing to do with containerization which is the purpose of Docker and unfortunately Docker just isn't that great at it. Meanwhile, they use it for configuration and in lieu of system administration which has multiple drawbacks and does indeed waste resources. I'm sure I'll be downvoted as well but thought I'd comment so you don't feel so alone. Keep doing things the right way.

foverzar 4y ago
> The vast majority of comments have nothing to do with containerization which is the purpose of Docker and unfortunately Docker just isn't that great at it. Meanwhile, they use it for configuration and in lieu of system administration which has multiple drawbacks and does indeed waste resources. Maybe that's because Docker largely iterates on existing container technology, and its purpose IS configuration? Nothing prevented you from containerizing processes before Docker, and initially it was merely a configuration frontend for LXC, which in turn handled all the containerization stuff. The actual value that Docker had added to good old jails/zones/chroot/lxc workflows is tooling and infrastructure for building, distributing and running images - there is nothing preventing you from creating simple similar tooling in plain Bash. Docker is largely about configuration and Dockerfiles, it doesn't create anything novel in regard to containerization tech. + It's just a popular standard.

throwawayu32 4y ago

Well that was humorous, with the username topping it off. The kicker is it remains a mystery whether this is satire or not.

KronisLV 4y ago

> I can grantee 99% of projects using docker or any sort of containerization are wasting 99% of compute resources. Genuine question: where would this overhead come from? I've used Docker (I know, Podman is supposedly better in some regards) for a while now on Windows for local development (Hyper-V back end) and on my servers (*nix boxes) and I haven't seen that many issues, even with something like Docker Swarm or Hashicorp Nomad for orchestration. I have, however, heard and/or experienced bad things in regards to: - disk I/O performance on Windows locally (WSL2 back end was slow for me, vice versa for others) - disk I/O performance on Mac - anything to do with Windows containers - the resource usage of Kubernetes (K3s, K0s, microk8s can help work around this, but not wholly; this might be the piece of software with the highest overhead in many stacks out there, if people go ahead and use it) Or are you referring to something else? Because frankly, a while back in my homelab I tried running a separate VM per project (not even per app) and at around 10 of those my disk I/O was so crippled the whole system was unusable - that might have been because the VMs were running full Debian instances and I had HDDs instead of SSDs (hey, I'm poor), as opposed to running somewhat cut down containers based on Debian or whatever (<40 PIDs). In contrast, containers have generally been pretty decent, especially because I can indicate CPU/RAM limits more easily than I otherwise could with systemd slices, which is helpful when something like MySQL decides that it would like to eat all of your RAM, or you need multiple MySQL instances on the same node for testing or different apps or whatever. My experience so far is that containers largely hold true to the promise of allowing an increased density without doing something a bit more shady like running one large MySQL instance with multiple users/DBs (the same would apply to PostgreSQL or any other "common" piece of multi-tenant software), which in practice makes debugging and updating everything a painful mess. I will concede that it's also a matter of ways of thinking about software, centralized vs decentralized (not even distributed systems per se) and all that. > Just waiting for those low skilled people to reply how wonderful docker is and to say "if its not working you are not doing it right" Bringing up the "No true Scotsman" argument ahead of the time is probably a good idea, but also makes this sound like something that's supposed to dismiss anyone who might have had different experiences from yours, which doesn't feel in good faith. I can see why running certain containers (e.g. anything built on Oracle Linux or other heavyweight base images for whatever reason) might coincide with large images and sluggish performance, or containers that have full init systems inside of them etc. The disk I/O issues on dev boxes should also need to be taken into account, of course. But in general, they seem "good enough" and I find it hard to believe the 99% figure. Maybe that's a broad statement/joke, not sure. Disclaimer: I've run software directly in the past, have used systemd (which I actually find passable, contrary to the seemingly popular belief), sysvinit, OpenRC, as well as have deployed it with Ansible. The learning curves of all those aside, I feel like software can run well with either approach, but I haven't run into that many issues with containers either. They do feel like a simplified init system that gives you lots of stuff out of the box and reduce thinking about your services as apps on a phone (standardized packages, common ways to configure etc.). Except for Kubernetes: most people out there don't need it, though I can understand why enterprises would go for it and have used it with varying success in the past. I'm also curious about how the people here feel about Vagrant and Packer, if you've any opinions on those.