[kilburn]

The scaling part is generally about running and managing multiple containers on multiple machines. In that sense, the advantage of going from virtualization to containerization is the same as going from bare-metal to virtualization: better computation density and more agile deployments.

On the one hand, containers are more efficient than virtual machines. Hence, you get more efficient usage of your hardware. Also, you can pack more containers in a given host than if you use virtualization. Net result: less hardware to run the same services. In turn, this also readuces the network load because the more services in the same machine, the less traffic on your network and better latencies between colocated services.

On the other hand, containers (as envisioned by docker) are much faster to deploy. You build images which are compositions of layers. You have a base layer containing the base OS, and then a "stack" layer containing your application stack, and finally your app on another layer. An image is a consolidated view of all these layers, but the layers can be fetched and managed independently. Hence, you can deploy containers much faster (no need to re-download every layer each time you want to deploy a new service). Additionally, they build faster and they launch faster (nearly as fast as a non-containerized application). This allows you to do even cooler things such as socket-activated containers, which would be painful with the startup times of virtual machines.

Obviously, this blends very well with the idea of building applications in terms of distributed services (or components or whatever). As a result, there are multiple projects pushing for "cluster-aware" (replicated, varying levels of consistency) services. People from the virtualization camp was already pushing for that, but now it is even more important because containers are leaner and cheaper to deploy.

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