5 ms·

Maybe if you only look at it through the lens of building an app/service, but containers offer so much more than that. By standardizing their delivery through r

by mihaelm 7mo ago

Maybe if you only look at it through the lens of building an app/service, but containers offer so much more than that. By standardizing their delivery through registries and management through runtimes, a lot of operational headaches just go away when using a container orchestrator. Not to mention better utilization of hardware since containers are more lightweight than VMs.

the__alchemist 7mo ago
Hah indeed that's my perspective. I'm used to being able to compile program, distribute executable, "just works", across win, Linux, MacOs. (With appropriate compile targets set)
Hackbraten 7mo ago
> Not to mention better utilization of hardware When compared to a VM, yes. But shipping a separate userspace for each small app is still bloat. You can reuse software packages and runtime environments across apps. From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular.
- esseph 7mo ago
  > From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular. Why? It's not virtualization, it's containerization. It's using the host kennel. Containers are fast.
  - Hackbraten 7mo ago
    I was referring to the userspace runtime stack, not the kernel. What I criticize is that multiple containers that share a single host usually overdo it with filesystem isolation. Hundreds of MBs of libraries and tools needlessly duplicated, even though they could just as well have used distro packages and deployed their apps as system-level packages and systemd unit files with `DynamicUser=`. You can hardly call this efficient hardware utilization.
    - arandomhuman 7mo ago
      The duplication is a necessity to achieve the isolation. Having shared devels and hordes of unit files for a multi tenant system is hell - versioning issues can and will break this paradigm, no serious shop is doing this. For running your own machine, sure. But this would become non maintainable for a sufficiently multi tenant system. Nix is the only thing that really can begin to solve this outside of container orchestration.
    - esseph 7mo ago
      The isolation is the POINT. You can't be assured that the library and version you need for you app is the same in installed by the system, for example. And it may not even be installed by the system, hence docker.
- Gigachad 7mo ago
  "bloat" has always been the last resort criticism from someone who has nothing valid. Containers are incredibly light, start very rapidly, and have such low overhead in general that the entire industry has been using them. Docker containers also do reuse shared components, layers that are shared between containers are not redownloaded. The stuff that's unique at the bottom is basically just going to be the app you want to run.
hrmtst93837 7mo ago
[flagged]

by mihaelm 7mo ago

the__alchemist 7mo ago

Hah indeed that's my perspective. I'm used to being able to compile program, distribute executable, "just works", across win, Linux, MacOs. (With appropriate compile targets set)

Hackbraten 7mo ago

> Not to mention better utilization of hardware When compared to a VM, yes. But shipping a separate userspace for each small app is still bloat. You can reuse software packages and runtime environments across apps. From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular.

esseph 7mo ago
> From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular. Why? It's not virtualization, it's containerization. It's using the host kennel. Containers are fast.
- Hackbraten 7mo ago
  I was referring to the userspace runtime stack, not the kernel. What I criticize is that multiple containers that share a single host usually overdo it with filesystem isolation. Hundreds of MBs of libraries and tools needlessly duplicated, even though they could just as well have used distro packages and deployed their apps as system-level packages and systemd unit files with `DynamicUser=`. You can hardly call this efficient hardware utilization.
  - arandomhuman 7mo ago
    The duplication is a necessity to achieve the isolation. Having shared devels and hordes of unit files for a multi tenant system is hell - versioning issues can and will break this paradigm, no serious shop is doing this. For running your own machine, sure. But this would become non maintainable for a sufficiently multi tenant system. Nix is the only thing that really can begin to solve this outside of container orchestration.
  - esseph 7mo ago
    The isolation is the POINT. You can't be assured that the library and version you need for you app is the same in installed by the system, for example. And it may not even be installed by the system, hence docker.
Gigachad 7mo ago
"bloat" has always been the last resort criticism from someone who has nothing valid. Containers are incredibly light, start very rapidly, and have such low overhead in general that the entire industry has been using them. Docker containers also do reuse shared components, layers that are shared between containers are not redownloaded. The stuff that's unique at the bottom is basically just going to be the app you want to run.

hrmtst93837 7mo ago

[flagged]