3 ms·

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.

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

> 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. )