4 ms·

The point of containerization is to take services that conflict and run them anyway on one kernel. If you already know your services are well enough designed an

The point of containerization is to take services that conflict and run them anyway on one kernel. If you already know your services are well enough designed and packaged that they can coexist with just process boundaries, why add overhead?

toomuchtodo 11y ago
> The point of containerization is to take services that conflict and run them anyway on one kernel. If you already know your services are well enough designed and packaged that they can coexist with just process boundaries, why add overhead? Multiple container overhead is insignificant when using lxc/docker containerization (compared to more traditional virtualization). Containerization exists to compartmentalize services for ease of management and service segregation; to not segregate services defeats the purpose.
- zwischenzug 11y ago
  Whose purpose? My point is that technology's purpose is the use to which it is effectively put, not authorial intention.
  - toomuchtodo 11y ago
    Pick the "correct" (most efficient) tool for the job.
    - zwischenzug 11y ago
      Yes, exactly: it depends on the problem you're trying to solve. They're not always striaghtforwardly technical.
- prodigal_erik 11y ago
  Virtualization solves a very different problem, namely that some of your software depends on the wrong kernel entirely, so you want to pretend you have several machines without actually racking them. Process boundaries also exist to compartmentalize services for ease of management and service segregation. Containerization just makes those boundaries slightly thicker, and only sloppy software that was trespassing over those boundaries gets any benefit, while all software becomes more hassle to manage with multiple copies of their dependencies.
- cdcarter 11y ago
  Multiple container mental overhead is significant in lxc/docker containerization. Grokking a system is a lot simpler if you can just exist in it.
rodgerd 11y ago
From a security point of view, segregation is A Thing these days. From a sysadmin point of view deploying a "work unit" makes a lot of sense, with the "work units" deployed many places.
- emmelaich 11y ago
  Yes, isolation is the goal, and sadly it's for reasons of deployability, not security. This implies that the configuration tools (puppet, ansible, chef, whatever) are simply not good enough.
  - vidarh 11y ago
    Most of the configuration tools we deal with try to bring the world from an unknown state to a sort-of known state with imperfect information. They're full of absolutely awful workarounds for not having well contained state.
    - zwischenzug 11y ago
      Indeed, which is why I invented this: http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/ Phoenix deployment makes far more sense to me.
- emmelaich 11y ago
  And speaking of isolation/segregation .. We already run apps in a vm (a jvm), on a vm (vmware). If we wanted to add security, we'd turn on the jvm's security manager. Adding docker to the layers for security isolation seems a bit silly when you could turn on the security manager instead. I love docker, but adding security is not the reason.

toomuchtodo 11y ago

> The point of containerization is to take services that conflict and run them anyway on one kernel. If you already know your services are well enough designed and packaged that they can coexist with just process boundaries, why add overhead? Multiple container overhead is insignificant when using lxc/docker containerization (compared to more traditional virtualization). Containerization exists to compartmentalize services for ease of management and service segregation; to not segregate services defeats the purpose.

zwischenzug 11y ago
Whose purpose? My point is that technology's purpose is the use to which it is effectively put, not authorial intention.
- toomuchtodo 11y ago
  Pick the "correct" (most efficient) tool for the job.
  - zwischenzug 11y ago
    Yes, exactly: it depends on the problem you're trying to solve. They're not always striaghtforwardly technical.
prodigal_erik 11y ago
Virtualization solves a very different problem, namely that some of your software depends on the wrong kernel entirely, so you want to pretend you have several machines without actually racking them. Process boundaries also exist to compartmentalize services for ease of management and service segregation. Containerization just makes those boundaries slightly thicker, and only sloppy software that was trespassing over those boundaries gets any benefit, while all software becomes more hassle to manage with multiple copies of their dependencies.
cdcarter 11y ago
Multiple container mental overhead is significant in lxc/docker containerization. Grokking a system is a lot simpler if you can just exist in it.

rodgerd 11y ago

From a security point of view, segregation is A Thing these days. From a sysadmin point of view deploying a "work unit" makes a lot of sense, with the "work units" deployed many places.

emmelaich 11y ago
Yes, isolation is the goal, and sadly it's for reasons of deployability, not security. This implies that the configuration tools (puppet, ansible, chef, whatever) are simply not good enough.
- vidarh 11y ago
  Most of the configuration tools we deal with try to bring the world from an unknown state to a sort-of known state with imperfect information. They're full of absolutely awful workarounds for not having well contained state.
  - zwischenzug 11y ago
    Indeed, which is why I invented this: http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/ Phoenix deployment makes far more sense to me.
emmelaich 11y ago
And speaking of isolation/segregation .. We already run apps in a vm (a jvm), on a vm (vmware). If we wanted to add security, we'd turn on the jvm's security manager. Adding docker to the layers for security isolation seems a bit silly when you could turn on the security manager instead. I love docker, but adding security is not the reason.