[beaker52]

Most services are developed to make maximum use of a host machine's hardware, so scaling multiple containers of the same image on a single physical host has very limited value.

Services are typically clustered across multiple hosts to alleviate pain associated with the availability constraints of a single host (e.g. physical resources, redundancy). "Scaling" containers across just a single host is:

1) an misunderstanding on the part of the operator, or

2) a very inefficient way of maximising the availability of a service on a single host.

In the case of 2), if you need to run multiple instances of your web service because one container doesn't maximise the resources of your host, then you're solving the problem in the wrong way. You should be making your service, in a single container, capable of maximising the resources of that host. Otherwise you're going to be wasting your physical resources taken up by the running of unnecessary containers.

Running multiple containers of the same image on the same host should be limited to testing of clustered services on a local host, admittedly with a few exceptions. I'd welcome any arguments to the contrary.

[rossf7]

Yes the tool we've released today is for playing with and not production use. It's single host to keep things simple. Definitely agree for production use a multiple host cluster is essential for redundancy.

We think the faster launch times of containers makes auto scaling easier compared to using VMs. So our tool will prioritise the mix of running containers based on current demand.

To do this we'll need to support multiple metrics. Some of those will be within the cluster like CPU and RAM. But some may be external like the length of a message queue or requests per second on a load balancer.

[beaker52]

How will the feature set differ from Docker Swarm?

https://docs.docker.com/swarm/