6 ms·

Can you elaborate on what the bin packing problem is?

by srdev 9y ago

andrewstuart2 9y ago
It's multi-machine scheduling, basically. Given N resources and M consumers, how can I fit all M consumers most efficiently, while using the minimum N? The bin metaphor is that you imagine one or several bins on the floor, and a bunch of things to place in bins. Binpacking is just playing tetris to make sure all your things are packed into as few bins as possible, because bins cost money. https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem
barrkel 9y ago
https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem If you have a bunch of jobs and you need to run them efficiently on a bunch of compute, you need to be careful not to oversubscribe the hardware, especially wrt memory. There's an isomorphism between running differently sized jobs concurrently on a compute resources, and the bin packing problem. It's a scheduling problem.
deleted 9y ago
[deleted]
eropple 9y ago
Kubernetes requires machines big enough to run all your containers. Those machines are the bins. Your containers are the packages. Fitting your containers in such that there is no criticality overlap (in AWS, that all instances of service X are spread across machines in different AZs) and that there is room for immediate scaling/emergency fault recovery (headroom on the machines running your containers) gets expensive. You're buying big and running little, and that comes with costs. Meanwhile, in AWS, you already have pre-sized blobs of RAM and compute. They're called EC2 instances. And then AWS pays the cost of the extra inventory, not you. (To forestall the usual, "overhead" of a Linux OS is like fifty megs these days, it's not something I'd worry about--most of the folks I know who have gone down the container-fleet road have bins that are consistently around 20% empty, and that does add up.) You may be the one percent of companies for whom immediate rollout, rather than 200-second rollout, is important, and for those companies a solution like Kubernetes or Mesos can make a lot of sense. Most aren't, and I think that they would be better served, in most cases, with a CloudFormation template, an autoscaling group with a cloud-init script to launch one container (if not chef-zero or whatever, that's my go-to but I'm also a devops guy by trade), and a Route 53 record. You're basically paying overhead for the privilege of `kubectl` that, personally, I don't think is really that useful in a cloud environment. (I think it makes a lot of sense on-prem, where you've already bought the hardware and the alternatives are something like vSphere or the ongoing tire fire that is OpenStack.)
- andrewstuart2 9y ago
  I know you're answering the question of bin-packing, but after two years of experience with it, I can say that for me, bin-packing is one of the smallest benefits (though it sells very well with management), though perhaps a baseline requirement these days. The real benefits, in my experience, stem from the declarative nature of cluster management, and the automation of doing the sensible thing to enact changes to that declarative desired state.
  - eropple 9y ago
    Sure. CloudFormation exists for that, though, and both its difficulty and its complexity are way overstated while also letting you manage AWS resources on top of that. And it doesn't cost anything to use.
    - andrewstuart2 9y ago
      Eh, there are a lot of terrible things I'd rather put myself through than writing another CloudFormation template for any sort of complex infrastructure. It could have been made easier and more readable if my company had allowed the use of something like Monsanto's generator [1], but creating ASTs in JSON is not my idea of a good user experience. [1] https://github.com/MonsantoCo/cloudformation-template-generator https://github.com/MonsantoCo/cloudformation-template-genera...
      - eropple 9y ago
        I maintain auster[1] and am a contributor to cfer[2] for exactly that purpose. ;) CloudFormation really isn't a rough time anymore, IMO. [1] - https://github.com/eropple/auster https://github.com/eropple/auster [2] - https://github.com/seanedwards/cfer https://github.com/seanedwards/cfer
        deleted 9y ago
        [deleted]
        9y ago
manigandham 9y ago
Running load efficiently on a given resource. Most VMs running a single app are under-utilized so it's more efficient to pack apps into containers and run them across a smaller pool of servers so that they all get the necessary resources without waste. Kubernetes does really well with this, although ease of deployment using config files and the abstraction from underlying vms/servers is probably more useful for most companies.
- eropple 9y ago
  Kubernetes emphatically does not do better at resource utilization than not using Kubernetes. You should figure on between ten and twenty percent of wastage per k8s node, plus the costs of your management servers, in a safely provisioned environment. You can argue about the configuration-based deployment being worth it--I disagree, because, frankly, Chef Zero is just not that complicated--but it's more expensive in every use case I have seem in the wild (barring ones where instances were unwisely provisioned in the first place).
  - manigandham 9y ago
    Based on what evidence? We can put hundreds of customer apps into a few servers and have them deployed and updated easily. We could try to manage this ourselves but it's much less efficient while costing much more effort. GKE also costs nothing for a master and there is no overhead. K8S/docker also makes it easy to avoid all the systemd/init issues and just use a standard interface with declarative configs and fast deployments that are automatically and dynamically managed while nodes come and go. We have preemptible instances with fast local storage and cheap pricing that maintain 100s of apps. K8S also easily manages any clustered software, regardless of native capabilities, along with easy networking. Why would I use chef for that - if it can even do all that in the first place?
    - bonesss 9y ago
      > GKE also costs nothing for a master and there is no overhead. Just a historical perspective: GCE used to charge a flat fee for K8s masters after 6 nodes. After the announcement of the Azure K8s service, with no master-fee, GCE has dropped the fee as well :)

Can you elaborate on what the bin packing problem is?

by srdev 9y ago

Can you elaborate on what the bin packing problem is?

It's multi-machine scheduling, basically. Given N resources and M consumers, how can I fit all M consumers most efficiently, while using the minimum N? The bin metaphor is that you imagine one or several bins on the floor, and a bunch of things to place in bins. Binpacking is just playing tetris to make sure all your things are packed into as few bins as possible, because bins cost money. https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem

barrkel 9y ago

https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem If you have a bunch of jobs and you need to run them efficiently on a bunch of compute, you need to be careful not to oversubscribe the hardware, especially wrt memory. There's an isomorphism between running differently sized jobs concurrently on a compute resources, and the bin packing problem. It's a scheduling problem.

deleted 9y ago

[deleted]

eropple 9y ago

Kubernetes requires machines big enough to run all your containers. Those machines are the bins. Your containers are the packages. Fitting your containers in such that there is no criticality overlap (in AWS, that all instances of service X are spread across machines in different AZs) and that there is room for immediate scaling/emergency fault recovery (headroom on the machines running your containers) gets expensive. You're buying big and running little, and that comes with costs. Meanwhile, in AWS, you already have pre-sized blobs of RAM and compute. They're called EC2 instances. And then AWS pays the cost of the extra inventory, not you. (To forestall the usual, "overhead" of a Linux OS is like fifty megs these days, it's not something I'd worry about--most of the folks I know who have gone down the container-fleet road have bins that are consistently around 20% empty, and that does add up.) You may be the one percent of companies for whom immediate rollout, rather than 200-second rollout, is important, and for those companies a solution like Kubernetes or Mesos can make a lot of sense. Most aren't, and I think that they would be better served, in most cases, with a CloudFormation template, an autoscaling group with a cloud-init script to launch one container (if not chef-zero or whatever, that's my go-to but I'm also a devops guy by trade), and a Route 53 record. You're basically paying overhead for the privilege of `kubectl` that, personally, I don't think is really that useful in a cloud environment. (I think it makes a lot of sense on-prem, where you've already bought the hardware and the alternatives are something like vSphere or the ongoing tire fire that is OpenStack.)

andrewstuart2 9y ago
I know you're answering the question of bin-packing, but after two years of experience with it, I can say that for me, bin-packing is one of the smallest benefits (though it sells very well with management), though perhaps a baseline requirement these days. The real benefits, in my experience, stem from the declarative nature of cluster management, and the automation of doing the sensible thing to enact changes to that declarative desired state.
- eropple 9y ago
  Sure. CloudFormation exists for that, though, and both its difficulty and its complexity are way overstated while also letting you manage AWS resources on top of that. And it doesn't cost anything to use.
  - andrewstuart2 9y ago
    Eh, there are a lot of terrible things I'd rather put myself through than writing another CloudFormation template for any sort of complex infrastructure. It could have been made easier and more readable if my company had allowed the use of something like Monsanto's generator [1], but creating ASTs in JSON is not my idea of a good user experience. [1] https://github.com/MonsantoCo/cloudformation-template-generator https://github.com/MonsantoCo/cloudformation-template-genera...
    - eropple 9y ago
      I maintain auster[1] and am a contributor to cfer[2] for exactly that purpose. ;) CloudFormation really isn't a rough time anymore, IMO. [1] - https://github.com/eropple/auster https://github.com/eropple/auster [2] - https://github.com/seanedwards/cfer https://github.com/seanedwards/cfer
      - deleted 9y ago
        [deleted]
      - 9y ago

manigandham 9y ago

Running load efficiently on a given resource. Most VMs running a single app are under-utilized so it's more efficient to pack apps into containers and run them across a smaller pool of servers so that they all get the necessary resources without waste. Kubernetes does really well with this, although ease of deployment using config files and the abstraction from underlying vms/servers is probably more useful for most companies.

eropple 9y ago
Kubernetes emphatically does not do better at resource utilization than not using Kubernetes. You should figure on between ten and twenty percent of wastage per k8s node, plus the costs of your management servers, in a safely provisioned environment. You can argue about the configuration-based deployment being worth it--I disagree, because, frankly, Chef Zero is just not that complicated--but it's more expensive in every use case I have seem in the wild (barring ones where instances were unwisely provisioned in the first place).
- manigandham 9y ago
  Based on what evidence? We can put hundreds of customer apps into a few servers and have them deployed and updated easily. We could try to manage this ourselves but it's much less efficient while costing much more effort. GKE also costs nothing for a master and there is no overhead. K8S/docker also makes it easy to avoid all the systemd/init issues and just use a standard interface with declarative configs and fast deployments that are automatically and dynamically managed while nodes come and go. We have preemptible instances with fast local storage and cheap pricing that maintain 100s of apps. K8S also easily manages any clustered software, regardless of native capabilities, along with easy networking. Why would I use chef for that - if it can even do all that in the first place?
  - bonesss 9y ago
    > GKE also costs nothing for a master and there is no overhead. Just a historical perspective: GCE used to charge a flat fee for K8s masters after 6 nodes. After the announcement of the Azure K8s service, with no master-fee, GCE has dropped the fee as well :)