6 ms·

That's pretty much what people do with containers.

by zbuttram 10y ago

thaumasiotes 10y ago
Right, the question is "how is that different from a statically-linked application?"
- stonogo 10y ago
  It allows developers to operate like they have a statically-linked application without having to undergo the cognitive dissonance of questioning the received "wisdom" that they are bad.
- ferbivore 10y ago
  Security?
  - thaumasiotes 10y ago
    Some details would be a little more helpful.
  - SwellJoe 10y ago
    In some regards that's currently a myth perpetrated by the folks making money on container-based deployments. Containers don't actually contain very well on Linux (yet, though some nice things are happening on that front, and you can already build very solid things with SELinux, but I haven't seen anybody actually doing so; except probably the Project Atomic folks). But, yes, in theory, a container-based deployment is hella tight on the security front. One service being compromised is no big deal: Kill it and instantly spin up a new one on a new IP (hopefully with a fix for the security issue). If your visibility into the system is high enough, you may even be able to architect detection of compromises; e.g. if your container for database service starts sending email or opens an IRC port, you know it's fucked, and you kill it with prejudice. In a system built to think of containers as black boxes with APIs, you don't need to keep any particular one around if you have reason to tear it down. Note that I haven't actually seen people doing any of this with containers. But, it's a thing that one could do that cannot be done when all of your services are applications running on a single big machine. The narrower the purpose of your container, the more secure it can become. You still have lots of moving parts in your total infrastructure (more, actually, since the container management has a cost, too), but each moving part has very well-defined boundaries, and misbehavior is easier to spot and easier to shut down quickly and via automated means.
- kstenerud 10y ago
  Interference from other running apps (memory, network, filesystem, etc). Operating system upgrades. Configuration management. Startup/teardown of multiple instances. Symbiotic or dependent processes/programs. Programs not specifically built with isolation in mind. Inter-application security.
- solidsnack9000 10y ago
  It is different because it is assembled from manageable pieces and still enjoys the benefits of memory separation. For example, running a tiny jobs server: * Scheduler in one process which spawns * Application code running in many subprocesses The scheduler might be in Ruby and the jobs might be in Ruby; or the scheduler might be Cron and the jobs in shell. In either case, if a job crashes the other jobs and the scheduler are very likely to carry on their work. It is also nice that you can bring together tools from different communities into a single application. A "Rails" container might utilize Nginx (C), Rails/Unicorn (Ruby) and Node (JS/C++) together. A single statically linked application would, barring some really amazing innovations in something like Clang modules, have to be in one language therefore from one community.
  - infradig 10y ago
    Well that sounds like Erlang.
    - SwellJoe 10y ago
      You're not wrong. Erlang solved a lot of problems of scale in very effective ways. These new architectures are solving the same problems in ways that look similar from a distance. This new(ish) approach just means we can use existing software mostly unchanged, while still getting a lot of the resiliency benefits of something like Erlang; doing it with Erlang means everything has to be written in Erlang. That wouldn't be a crazy idea for some deployments. But, for others, it's not tenable.
      - solidsnack9000 10y ago
        Erlang's support for C modules was always good, though. PyPy, Swift and Rust do all seem to have a fairly good export-to-C story. With Clang modules something like Erlang could become the "cloud shell".
  - yellowapple 10y ago
    > A single statically linked application would, barring some really amazing innovations in something like Clang modules, have to be in one language therefore from one community. Not necessarily. If they all can compile to native machine code with the same C-like semantics, they can (in theory) be combined in that sort of manner. This is true of both Rust and Go, last I checked, as it is with pretty much any compiled language that has a "convert to C" step (Chicken Scheme is an example that I'm particularly familiar with) or perhaps even a "convert to LLVM IR" step. Not that this is especially feasible for the majority of languages being used in web development (at least by those with a lick of sanity; Go and Scheme are the only exceptions that I'm aware of off the top of my head), but it's still worth considering.

That's pretty much what people do with containers.

thaumasiotes 10y ago

Right, the question is "how is that different from a statically-linked application?"

stonogo 10y ago
It allows developers to operate like they have a statically-linked application without having to undergo the cognitive dissonance of questioning the received "wisdom" that they are bad.
ferbivore 10y ago
Security?
- thaumasiotes 10y ago
  Some details would be a little more helpful.
- SwellJoe 10y ago
  In some regards that's currently a myth perpetrated by the folks making money on container-based deployments. Containers don't actually contain very well on Linux (yet, though some nice things are happening on that front, and you can already build very solid things with SELinux, but I haven't seen anybody actually doing so; except probably the Project Atomic folks). But, yes, in theory, a container-based deployment is hella tight on the security front. One service being compromised is no big deal: Kill it and instantly spin up a new one on a new IP (hopefully with a fix for the security issue). If your visibility into the system is high enough, you may even be able to architect detection of compromises; e.g. if your container for database service starts sending email or opens an IRC port, you know it's fucked, and you kill it with prejudice. In a system built to think of containers as black boxes with APIs, you don't need to keep any particular one around if you have reason to tear it down. Note that I haven't actually seen people doing any of this with containers. But, it's a thing that one could do that cannot be done when all of your services are applications running on a single big machine. The narrower the purpose of your container, the more secure it can become. You still have lots of moving parts in your total infrastructure (more, actually, since the container management has a cost, too), but each moving part has very well-defined boundaries, and misbehavior is easier to spot and easier to shut down quickly and via automated means.
kstenerud 10y ago
Interference from other running apps (memory, network, filesystem, etc). Operating system upgrades. Configuration management. Startup/teardown of multiple instances. Symbiotic or dependent processes/programs. Programs not specifically built with isolation in mind. Inter-application security.
solidsnack9000 10y ago
It is different because it is assembled from manageable pieces and still enjoys the benefits of memory separation. For example, running a tiny jobs server: * Scheduler in one process which spawns * Application code running in many subprocesses The scheduler might be in Ruby and the jobs might be in Ruby; or the scheduler might be Cron and the jobs in shell. In either case, if a job crashes the other jobs and the scheduler are very likely to carry on their work. It is also nice that you can bring together tools from different communities into a single application. A "Rails" container might utilize Nginx (C), Rails/Unicorn (Ruby) and Node (JS/C++) together. A single statically linked application would, barring some really amazing innovations in something like Clang modules, have to be in one language therefore from one community.
- infradig 10y ago
  Well that sounds like Erlang.
  - SwellJoe 10y ago
    You're not wrong. Erlang solved a lot of problems of scale in very effective ways. These new architectures are solving the same problems in ways that look similar from a distance. This new(ish) approach just means we can use existing software mostly unchanged, while still getting a lot of the resiliency benefits of something like Erlang; doing it with Erlang means everything has to be written in Erlang. That wouldn't be a crazy idea for some deployments. But, for others, it's not tenable.
    - solidsnack9000 10y ago
      Erlang's support for C modules was always good, though. PyPy, Swift and Rust do all seem to have a fairly good export-to-C story. With Clang modules something like Erlang could become the "cloud shell".
- yellowapple 10y ago
  > A single statically linked application would, barring some really amazing innovations in something like Clang modules, have to be in one language therefore from one community. Not necessarily. If they all can compile to native machine code with the same C-like semantics, they can (in theory) be combined in that sort of manner. This is true of both Rust and Go, last I checked, as it is with pretty much any compiled language that has a "convert to C" step (Chicken Scheme is an example that I'm particularly familiar with) or perhaps even a "convert to LLVM IR" step. Not that this is especially feasible for the majority of languages being used in web development (at least by those with a lick of sanity; Go and Scheme are the only exceptions that I'm aware of off the top of my head), but it's still worth considering.