[octix]

Thanks for trying to explain.

In my mind scale means use more resources, but in this case I fail to see benefits, except quicker env setup for the app, but for that there are automation services.

Yes, cluster-aware apps, if I want to scale 1 app, I'll create dedicated nodes/vm instances for it, how are containers helping? Why woudl I need multiple containers on the same host, for each app instance?

Thanks again.

[kilburn]

You are missing part of the story. If scaling is just "using more resources" then I can scale infinitely. I can run "while true" on as many hosts as you want. What I'm trying to point out here is that scaling is about doing more useful work, not just using more resources.

Why would you need more containers on a single host? Because apps are usually not uniform. If you dedicate one host per service, then you need hosts to serve the maximum computation power at the peak consumption required at any point in the app's lifetime. Also, VMs are heavyweight, which means that it is painful to break your app into small, independent services that you can spin up and down quickly. Containers are much better at enabling you to modularize (and thus be able to scale on a finer grain) your application.

Now you may argue that you can spin more AWS instances when under load. But spinning up VMs takes time, much more time than spinning up containers (we're talking on the order of minutes vs milliseconds here). This may seem a small difference, but pair it with socket activation for instance and suddenly you go from having to carefully manage your scaling to getting it quasi-automated for free.

Finally, there's the ecosystem. You can create dedicate nodes/vm instances, sure. But watch a demo of CoreOS's fleet automatically and nearly-instantly spinning up and maintaining coordinated containers [1] and you may get a feeling of why people is so excited about this whole thing.

[1] http://coreos.com/blog/cluster-level-container-orchestration...