3 ms·

Do you have experience using containers? Here's my answer for "why": DRY. Once you've deployed hundreds of servers using the same exact Ubuntu 12.04 LTS kernel

by mbesto 11y ago

Do you have experience using containers? Here's my answer for "why": DRY. Once you've deployed hundreds of servers using the same exact Ubuntu 12.04 LTS kernel base, why not just completely abstract the OS away and focus the attention on scaling the OS services that matter? Why is that when I decide that I need to scale out, I need to copy every library of the OS and every line of code for the kernel and redeploy it every time I add a node? > At this rate we'll end up shipping containers as 'apps' to the clients machines with a suitable emulator at some point. That's exactly the point. Care to elaborate on the downside of such a promise?

jacquesm 11y ago
> why not just completely abstract the OS away and focus the attention on scaling the OS services that matter? Because it adds a layer that makes no sense unless you have very specific use cases. Though I see the point regarding people efficiency, that one makes good sense (see other comment in this sub-thread) > Why is that when I decide that I need to scale out, I need to copy every library of the OS and every line of code for the kernel and redeploy it every time I add a node? If you're doing it that way then you are simply doing it wrong. See: chef, configuration management and various deployment services (of which you could argue containers are one off-shoot, but they focus (imo) on the wrong level for all but the largest companies). Containers are like sandboxes with significant overhead for applications that focus on ease of deployment (but that's strange to me because I see that as a one-time cost for most of my own use cases, though I can see how that equation would change if you deploy lots of things configured by lots of different people to a single set of servers, especially if there are conflicting requirements between those deployments). > Care to elaborate on the downside of such a promise? That's my personal view of hell, if you don't see any downside there please ignore my vision and continue as if nothing was said. From open, text based standards to shipping arbitrary binaries in a couple of decades. And I thought GKS was about as bad as it got ;)
- alextgordon 11y ago
  Containers are simply a generalisation of python virtualenvs or ruby rbenvs, to encapsulate the entire environment. If you asked a Python programmer "well, why don't you just buy a new laptop for each project?" you might get strange looks.
- mbesto 11y ago
  > See: chef, configuration management and various deployment services A chef script is basically the automation of "I need to copy every library of the OS and every line of code for the kernel and redeploy it every time I add a node?" I'm sorry if you didn't pick up on my implied remark. Two problems are then introduced when automating those actions: (1) it doesn't negate the fact that I need to store and deploy a 700M sized OS layer every time I want to add a node (which takes minutes, not seconds with non-containerized configs) and (2) maintaining config scripts can (not always) be painful (version control, rollbacks, etc) > unless you have very specific use cases. > Containers are like sandboxes with significant overhead for applications Again, do you have experience using containers? You seem awfully dismissive ("you're doing it wrong!") in a way that suggests that you might not entirely understand how they actually work...
  - jacquesm 11y ago
    I'm not dismissive enough to have already committed elsewhere in this thread to re-do a bit of experimentation I did about a year ago on using containers and at the time the performance overhead was such that I failed to see the use case, but since this is a fast moving field it won't hurt me one bit to update my knowledge. In a nutshell: running a 'standard' combo of apache and a DB server as well as some auxiliary bits and pieces inside 'containers' a year ago gave significant overhead compared to running those without the containers. I'll re-do this and I'll probably do a write-up because the subject is interesting. This comment and follow up (https://news.ycombinator.com/item?id=9567623 https://news.ycombinator.com/item?id=9567623) are by people using this tech in production right now and their experience echos mine (but they're very far down the line compared to where I stopped). Besides that particular use case (where performance and isolation are the key components to be looked at) some interesting points have been made in this thread which has shifted my stance on container use depending on what the situation is. So I don't think it is valid to classify me as 'awfully dismissive'. FWIW I have not used containers in production (yet) but I'll be more than happy to if I can figure out where and how they can bring me an advantage, which is pretty much how I approach all tools.
  - 15thandwhatever 11y ago
    What I do on our app servers is create a new user for each app (via configuration management). That gives me both environment separation (A needs Ruby 1.9, B needs Ruby 2.0), resource accounting on a per-app basis, and a repeatable foundation in case I need to re-deploy the server or spin up new instances.
gaadd33 11y ago
Why do you bother with an OS or a container if you want to abstract the OS away? Just PXE boot all the machines and have the application set to run as init. No need to worry about copying every library for the OS to every machine and you only require the minimal kernel that you tell it to boot with.

by mbesto 11y ago

jacquesm 11y ago

> why not just completely abstract the OS away and focus the attention on scaling the OS services that matter? Because it adds a layer that makes no sense unless you have very specific use cases. Though I see the point regarding people efficiency, that one makes good sense (see other comment in this sub-thread) > Why is that when I decide that I need to scale out, I need to copy every library of the OS and every line of code for the kernel and redeploy it every time I add a node? If you're doing it that way then you are simply doing it wrong. See: chef, configuration management and various deployment services (of which you could argue containers are one off-shoot, but they focus (imo) on the wrong level for all but the largest companies). Containers are like sandboxes with significant overhead for applications that focus on ease of deployment (but that's strange to me because I see that as a one-time cost for most of my own use cases, though I can see how that equation would change if you deploy lots of things configured by lots of different people to a single set of servers, especially if there are conflicting requirements between those deployments). > Care to elaborate on the downside of such a promise? That's my personal view of hell, if you don't see any downside there please ignore my vision and continue as if nothing was said. From open, text based standards to shipping arbitrary binaries in a couple of decades. And I thought GKS was about as bad as it got ;)

alextgordon 11y ago
Containers are simply a generalisation of python virtualenvs or ruby rbenvs, to encapsulate the entire environment. If you asked a Python programmer "well, why don't you just buy a new laptop for each project?" you might get strange looks.
mbesto 11y ago
> See: chef, configuration management and various deployment services A chef script is basically the automation of "I need to copy every library of the OS and every line of code for the kernel and redeploy it every time I add a node?" I'm sorry if you didn't pick up on my implied remark. Two problems are then introduced when automating those actions: (1) it doesn't negate the fact that I need to store and deploy a 700M sized OS layer every time I want to add a node (which takes minutes, not seconds with non-containerized configs) and (2) maintaining config scripts can (not always) be painful (version control, rollbacks, etc) > unless you have very specific use cases. > Containers are like sandboxes with significant overhead for applications Again, do you have experience using containers? You seem awfully dismissive ("you're doing it wrong!") in a way that suggests that you might not entirely understand how they actually work...
- jacquesm 11y ago
  I'm not dismissive enough to have already committed elsewhere in this thread to re-do a bit of experimentation I did about a year ago on using containers and at the time the performance overhead was such that I failed to see the use case, but since this is a fast moving field it won't hurt me one bit to update my knowledge. In a nutshell: running a 'standard' combo of apache and a DB server as well as some auxiliary bits and pieces inside 'containers' a year ago gave significant overhead compared to running those without the containers. I'll re-do this and I'll probably do a write-up because the subject is interesting. This comment and follow up (https://news.ycombinator.com/item?id=9567623 https://news.ycombinator.com/item?id=9567623) are by people using this tech in production right now and their experience echos mine (but they're very far down the line compared to where I stopped). Besides that particular use case (where performance and isolation are the key components to be looked at) some interesting points have been made in this thread which has shifted my stance on container use depending on what the situation is. So I don't think it is valid to classify me as 'awfully dismissive'. FWIW I have not used containers in production (yet) but I'll be more than happy to if I can figure out where and how they can bring me an advantage, which is pretty much how I approach all tools.
- 15thandwhatever 11y ago
  What I do on our app servers is create a new user for each app (via configuration management). That gives me both environment separation (A needs Ruby 1.9, B needs Ruby 2.0), resource accounting on a per-app basis, and a repeatable foundation in case I need to re-deploy the server or spin up new instances.

gaadd33 11y ago

Why do you bother with an OS or a container if you want to abstract the OS away? Just PXE boot all the machines and have the application set to run as init. No need to worry about copying every library for the OS to every machine and you only require the minimal kernel that you tell it to boot with.