5 ms·

"Containers are silly" might be the literal worst take I've seen in this space, especially if one is at all interested in "onboarding more moderately techy folk

by jrm4 3y ago

"Containers are silly" might be the literal worst take I've seen in this space, especially if one is at all interested in "onboarding more moderately techy folk" to the idea of homelabs, and self-hosting, which I think is incredibly important. Once you know Docker, you can abstract away SO MUCH and get things up and running incredibly quickly. Let's say you have someone who now hates Spotify. Perfect. Before Docker it was a huge pain to try to set up one and hope you get it right. After Docker? Just TRY ALL OF THEM. Don't like Navidrome/mstream/whatever? Okay, docker-compose down and try the next one.

watermelon0 3y ago
TBH, containers are the wrong way of doing things, but they are the least bad solution of shipping software that we currently have.
- ycombinatrix 3y ago
  scratch containers aren't so bad
- zer00eyz 3y ago
  This is the truth. Containers as a bag that you put shitty software in to isolate it from the rest of your system and its peers... The whole downstream, vs upstream, who should package what and where do you get software is showing us what the real problem is. Software, should be easy to instal. Containers are a terrible way to do that.
  - stavros 3y ago
    What's easier than containers? It sounds to me like you let your hate of the problem carry over to hating the solution. I have a Python web app, what's a better way to distribute it than containers?
    - apitman 3y ago
      I basically agree with you, but it would be nice if containers were a bit simpler. Apptainer does some really nice things for example.
    - watermelon0 3y ago
      As much as I like scripting languages, the fact that you cannot build a single statically-built executable is the main problem when it comes to distribution. Go/Rust are miles ahead in that regard, and the only reason to use containers with them is the sandbox aspect. (There are ways to create a self-contained executable including Python interpreter, code, and all dependencies, but it's far from ideal, and just going with Docker is a lot less problematic.)
      - stavros 3y ago
        Sure, but I have a Python web app.
    - deleted 3y ago
      [deleted]
    - zer00eyz 3y ago
      I like python, I write python. I think python is the high fructose corn surup of programing, its in everything, embedded, web, ML, data science .... >> What's easier than containers? Easy is the wrong metric. It is easy to not scoop your dogs poop when you take him on a walk. It is easy to drop your trash on the ground and not take it to a can... Easy is a BAD METRIC. Python is one of the problems. your code + Runtime + random libs + venv. thats a lot of nonsense that could be a binary blob. Part of this is the fault of python (or js, or ruby or...) a lot of it is on us as software devs. And micro services had a hand in this... Your N services dont run on N*X pieces of hardware. They run on far less and end up on virtual networks taking to each other over https when they could be using direct communication. It's even more laughable if they go out to a load balancer first. Software packaging and delivery is a problem. We should figure out a few good ways to fix that.
      - 3y ago
- KronisLV 3y ago
  > TBH, containers are the wrong way of doing things And yet, people still use VMs because the majority of software isn't perfect and pollutes whatever system it's running on to some degree. Just earlier today I saw a friend look at an install script for some software, which was set on freely installing apt packages, replacing the installed Node version, purging the apt repositories on the system (literally "rm -rf /etc/apt/sources.list.d/*", wtf) and a lot of things that no decently written piece of software should do on its own, at least not without explicit confirmation, but you still sometimes see out in the wild. The friend was reviewing the script after running it and wondering why their system was trashed. You often need some separation between what is your host system that needs to be pretty stable and the flaming mess that is whatever software that you'll install on it for productivity/entertainment/profit reasons, especially with easily configurable resource limits, custom port mappings, custom storage directories without access to the host system by default and eventually even horizontal scaling. Containers just happen to have really good DX around all of that and feel like the right way of doing things, in a flawed world.
  - watermelon0 3y ago
    Dependency hell and polluting the system IS the problem. Ideally, we would have statically built self-contained executables, and OS would offer sandboxing (process, network, filesystem) out of the box. Containers at the moment are just lightweight VMs, and a better workaround to the problem (better especially in regard to UX; VMs isolation is still superior to cgroups/namespaces on Linux).
    - nurple 3y ago
      The Linux OS literally provides sandboxing, we call the set of technologies that provide this "containers". "Containers" are not lightweight VMs; VMs are a virtualized computer, containers are a virtualized kernel. Statically linked everything is ridiculous and will never be the future of software deployment.
  - jmbwell 3y ago
    In some cases, running docker containers using the vendor-provided docker compose file, inside a VM that you yourself provision according to your own needs using your own tooling (ansible etc), is the best approach, which at this point is ridiculous, but here we are.
goodpoint 3y ago
> get things up and running incredibly quickly Optimizing for the wrong metric.
- geraldhh 3y ago
  username checks out "move fast and break things" was always a short-sighted fad in the context of infrastructure
- nurple 3y ago
  Underrated comment. So many orgs seem to spend a lot of time and effort on DX that makes onboarding, building, and deploying new software packages fast. But in most cases getting these pipelines set up was never a bottleneck, and automating their creation is a nearly NP-complete problem. I think the reasoning behind these efforts is twofold: first, devops empire builders that mistake this for a good metric, and leadership that thinks it might let them get rid of ops ppl.
- code_biologist 3y ago
  Accessibility is the metric in software adoption. Raspberry Pi and Arduino have made those computing form factors wildly more approachable for a general audience. Are they optimizing for the wrong metric?
  - goodpoint 3y ago
    Raspberry Pi and Arduino are focusing on learning which is the opposite of "getting things up and running incredibly quickly"
- jrm4 3y ago
  for YOU. I teach IT. I'm trying to get people interested in empowering themselves, not necessarily create more cogs.
  - goodpoint 3y ago
    Then you should optimize for learning, not for "quick deploy and forget" which is precisely the pattern of "cogs".

by jrm4 3y ago

watermelon0 3y ago

TBH, containers are the wrong way of doing things, but they are the least bad solution of shipping software that we currently have.

ycombinatrix 3y ago
scratch containers aren't so bad
zer00eyz 3y ago
This is the truth. Containers as a bag that you put shitty software in to isolate it from the rest of your system and its peers... The whole downstream, vs upstream, who should package what and where do you get software is showing us what the real problem is. Software, should be easy to instal. Containers are a terrible way to do that.
- stavros 3y ago
  What's easier than containers? It sounds to me like you let your hate of the problem carry over to hating the solution. I have a Python web app, what's a better way to distribute it than containers?
  - apitman 3y ago
    I basically agree with you, but it would be nice if containers were a bit simpler. Apptainer does some really nice things for example.
  - watermelon0 3y ago
    As much as I like scripting languages, the fact that you cannot build a single statically-built executable is the main problem when it comes to distribution. Go/Rust are miles ahead in that regard, and the only reason to use containers with them is the sandbox aspect. (There are ways to create a self-contained executable including Python interpreter, code, and all dependencies, but it's far from ideal, and just going with Docker is a lot less problematic.)
    - stavros 3y ago
      Sure, but I have a Python web app.
  - deleted 3y ago
    [deleted]
  - zer00eyz 3y ago
    I like python, I write python. I think python is the high fructose corn surup of programing, its in everything, embedded, web, ML, data science .... >> What's easier than containers? Easy is the wrong metric. It is easy to not scoop your dogs poop when you take him on a walk. It is easy to drop your trash on the ground and not take it to a can... Easy is a BAD METRIC. Python is one of the problems. your code + Runtime + random libs + venv. thats a lot of nonsense that could be a binary blob. Part of this is the fault of python (or js, or ruby or...) a lot of it is on us as software devs. And micro services had a hand in this... Your N services dont run on N*X pieces of hardware. They run on far less and end up on virtual networks taking to each other over https when they could be using direct communication. It's even more laughable if they go out to a load balancer first. Software packaging and delivery is a problem. We should figure out a few good ways to fix that.
    - 3y ago
KronisLV 3y ago
> TBH, containers are the wrong way of doing things And yet, people still use VMs because the majority of software isn't perfect and pollutes whatever system it's running on to some degree. Just earlier today I saw a friend look at an install script for some software, which was set on freely installing apt packages, replacing the installed Node version, purging the apt repositories on the system (literally "rm -rf /etc/apt/sources.list.d/*", wtf) and a lot of things that no decently written piece of software should do on its own, at least not without explicit confirmation, but you still sometimes see out in the wild. The friend was reviewing the script after running it and wondering why their system was trashed. You often need some separation between what is your host system that needs to be pretty stable and the flaming mess that is whatever software that you'll install on it for productivity/entertainment/profit reasons, especially with easily configurable resource limits, custom port mappings, custom storage directories without access to the host system by default and eventually even horizontal scaling. Containers just happen to have really good DX around all of that and feel like the right way of doing things, in a flawed world.
- watermelon0 3y ago
  Dependency hell and polluting the system IS the problem. Ideally, we would have statically built self-contained executables, and OS would offer sandboxing (process, network, filesystem) out of the box. Containers at the moment are just lightweight VMs, and a better workaround to the problem (better especially in regard to UX; VMs isolation is still superior to cgroups/namespaces on Linux).
  - nurple 3y ago
    The Linux OS literally provides sandboxing, we call the set of technologies that provide this "containers". "Containers" are not lightweight VMs; VMs are a virtualized computer, containers are a virtualized kernel. Statically linked everything is ridiculous and will never be the future of software deployment.
- jmbwell 3y ago
  In some cases, running docker containers using the vendor-provided docker compose file, inside a VM that you yourself provision according to your own needs using your own tooling (ansible etc), is the best approach, which at this point is ridiculous, but here we are.

goodpoint 3y ago

> get things up and running incredibly quickly Optimizing for the wrong metric.

geraldhh 3y ago
username checks out "move fast and break things" was always a short-sighted fad in the context of infrastructure
nurple 3y ago
Underrated comment. So many orgs seem to spend a lot of time and effort on DX that makes onboarding, building, and deploying new software packages fast. But in most cases getting these pipelines set up was never a bottleneck, and automating their creation is a nearly NP-complete problem. I think the reasoning behind these efforts is twofold: first, devops empire builders that mistake this for a good metric, and leadership that thinks it might let them get rid of ops ppl.
code_biologist 3y ago
Accessibility is the metric in software adoption. Raspberry Pi and Arduino have made those computing form factors wildly more approachable for a general audience. Are they optimizing for the wrong metric?
- goodpoint 3y ago
  Raspberry Pi and Arduino are focusing on learning which is the opposite of "getting things up and running incredibly quickly"
jrm4 3y ago
for YOU. I teach IT. I'm trying to get people interested in empowering themselves, not necessarily create more cogs.
- goodpoint 3y ago
  Then you should optimize for learning, not for "quick deploy and forget" which is precisely the pattern of "cogs".