4 ms·

I like Docker and I use it in dev/sandpit quite a bit lately... but I must admit, I don't quite follow the metaphor being pushed here. Standard workloads don't

I like Docker and I use it in dev/sandpit quite a bit lately... but I must admit, I don't quite follow the metaphor being pushed here. Standard workloads don't require containers. You can have standard workloads on your physical or virtualised hardware. The choice between these is going to depend on a bunch of factors. I don't see why they need to be bound together, as appears to be the case with Docker? Plus I don't see how that provides any special leverage (as opposed to having the choice).

mateuszf 13y ago
It has great advantages by doing it this way. 1. For developer: - your application works exactly the same way on your development, test and production environment because of using exactly the same os/libs/configuration - very fast snapshot/restore simplifies automatic tests and makes them practical 2. For system admin: - configure your system once in order to make docker work, run any docker image (program) with one, the same command - run many applications which do not influence each other in a quite safe way - download and run application without worrying about its dependencies - very low footprint in terms of disk/memory/cpu usage in comparison with standard virtualization
- jwilliams 13y ago
  1. Agree that's handy in dev. For development a container is probably a good choice - in other environments virtualization or physical hardware may make sense. "More consistent" dev/test/prod is great, but I don't need nor want identical. My needs in dev are different from production - e.g. Everything from basic settings, URLs, networking, reloading behaviour to performance tuning. My needs for my dev DB are quite different from those in production. 2. Agree, but this isn't unique to containers (which is probably what I was aiming at). Low footprint is somewhat irrelevant to "configure once". You can manage this on physical hardware if needs be. Low footprint is great when you're resource constrained, somewhat irrelevant at scale. Plus a VM gives you other features/tradeoffs in return for that cost. Different circumstances will tend to favour one over the other. I find Docker useful. Containers and Standardised Workloads are great. I see the utility in both, my argument is I see them as orthogonal. Particularly referring to the "alternatives" at the end of the deck, which seemed unnecessary distinctions for me.
  - vidarh 13y ago
    > My needs in dev are different from production - e.g. Everything from basic settings, URLs, networking, reloading behaviour to performance tuning. My needs for my dev DB are quite different from those in production. But you'll need a lot of things to be configured identically, and you'll need it to be reproducible (say for when a server fails). That's the point - nobody forces you to have just one identical script. The containers vs. vm's distinction otherwise makes a difference for one reason only: Because containers allow higher density, it is acceptable to employ them in situations where the cost of vm's would be too high. This is how it hangs together with standardised workloads: They're lightweight enough that standardised workloads becomes viable for many more use cases. (In fact, on Linux, LXC is built on top of cgroups/namespaces which are far more flexible than that: Instead of building full containers, you can run individual applications in their own containers, or you can have servers with built in cgroups support that could e.g. do stuff like take an incoming connection, authenticate the user, look that user up and see "ok, this users connection is allowed to use 5% CPU and 10% of disk IO and 100MB memory", fork() and assign the forked process to cgroups accordingly, while at the same time isolating him so the process in question can only see a certain directory, can't see other processes etc.. Heck, you could even give the process its own network, and firewall it so it can only connect to certain specific network resources. )
vidarh 13y ago
Virtualized hardware and containers are roughly equivalent here - the reason for containers is lower resource usage, not some other fundamental difference vs. vm's. But physical servers will not have "standard workloads" unless you wipe them everytime you reinstall, or run a system that can guarantee the server is put in identical state. It's not practical for most people to do. The reason for binding containers or vm's together with "standard workloads" is thus because the key to standard workloads for most people is down to functionality for rapid, reproducible deployment coupled with isolation. That Docker has so far been tied to LXC is a separate matter, but I frankly don't see that as a bad thing - too many virtualization / cloud solutions are hopelessly over-engineered.

mateuszf 13y ago

It has great advantages by doing it this way. 1. For developer: - your application works exactly the same way on your development, test and production environment because of using exactly the same os/libs/configuration - very fast snapshot/restore simplifies automatic tests and makes them practical 2. For system admin: - configure your system once in order to make docker work, run any docker image (program) with one, the same command - run many applications which do not influence each other in a quite safe way - download and run application without worrying about its dependencies - very low footprint in terms of disk/memory/cpu usage in comparison with standard virtualization

jwilliams 13y ago
1. Agree that's handy in dev. For development a container is probably a good choice - in other environments virtualization or physical hardware may make sense. "More consistent" dev/test/prod is great, but I don't need nor want identical. My needs in dev are different from production - e.g. Everything from basic settings, URLs, networking, reloading behaviour to performance tuning. My needs for my dev DB are quite different from those in production. 2. Agree, but this isn't unique to containers (which is probably what I was aiming at). Low footprint is somewhat irrelevant to "configure once". You can manage this on physical hardware if needs be. Low footprint is great when you're resource constrained, somewhat irrelevant at scale. Plus a VM gives you other features/tradeoffs in return for that cost. Different circumstances will tend to favour one over the other. I find Docker useful. Containers and Standardised Workloads are great. I see the utility in both, my argument is I see them as orthogonal. Particularly referring to the "alternatives" at the end of the deck, which seemed unnecessary distinctions for me.
- vidarh 13y ago
  > My needs in dev are different from production - e.g. Everything from basic settings, URLs, networking, reloading behaviour to performance tuning. My needs for my dev DB are quite different from those in production. But you'll need a lot of things to be configured identically, and you'll need it to be reproducible (say for when a server fails). That's the point - nobody forces you to have just one identical script. The containers vs. vm's distinction otherwise makes a difference for one reason only: Because containers allow higher density, it is acceptable to employ them in situations where the cost of vm's would be too high. This is how it hangs together with standardised workloads: They're lightweight enough that standardised workloads becomes viable for many more use cases. (In fact, on Linux, LXC is built on top of cgroups/namespaces which are far more flexible than that: Instead of building full containers, you can run individual applications in their own containers, or you can have servers with built in cgroups support that could e.g. do stuff like take an incoming connection, authenticate the user, look that user up and see "ok, this users connection is allowed to use 5% CPU and 10% of disk IO and 100MB memory", fork() and assign the forked process to cgroups accordingly, while at the same time isolating him so the process in question can only see a certain directory, can't see other processes etc.. Heck, you could even give the process its own network, and firewall it so it can only connect to certain specific network resources. )

vidarh 13y ago

Virtualized hardware and containers are roughly equivalent here - the reason for containers is lower resource usage, not some other fundamental difference vs. vm's. But physical servers will not have "standard workloads" unless you wipe them everytime you reinstall, or run a system that can guarantee the server is put in identical state. It's not practical for most people to do. The reason for binding containers or vm's together with "standard workloads" is thus because the key to standard workloads for most people is down to functionality for rapid, reproducible deployment coupled with isolation. That Docker has so far been tied to LXC is a separate matter, but I frankly don't see that as a bad thing - too many virtualization / cloud solutions are hopelessly over-engineered.