Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How does Docker affect energy consumption?

arxiv.org

Post reply on HN
Print view View original

41–50 of 88 posts

Re: How does Docker affect energy consumption?

#41

Post by AnsemWise »

AnsemWise wrote: post #39
CrLf wrote: post #37

Earlier quoted context omitted.

> Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). I'm starting to believe that the increased density provided by containerization is a myth, in practice. Both because orchestration tools bring their own overhead (compare all the proxies and…

Containers are an abstraction that exist using cgroups and namespaces for isolation. They use the hosts' kernel, it's not virtualized. Containers are only limited by the capabilities of namespaces and cgroups, unlike vms. You might be dismissing microservices too quickly. They do have overhead but so does any level of abstract; the benefit of them though is clear separation of responsibilities between services and re…

Resiliency

Re: How does Docker affect energy consumption?

#42

Post by raulk »

CrLf wrote: post #37
raulk wrote: post #34

Doesn't this article fail to consider the bigger, practical picture, i.e. overall resource efficiency/footprint in multi-component architectures? Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). Example: consider you need to deploy not just a…

> Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). I'm starting to believe that the increased density provided by containerization is a myth, in practice. Both because orchestration tools bring their own overhead (compare all the proxies and…

> If you're running 20-30 containers on a beefy VM, you're not really condensing anything. You're just moving from running hundreds of small VMs on a single server to running much less larger VMs.

Of course you are condensing. Those small VMs would have been running a full OS runtime each.

Assuming you relocate those workloads onto a single machine (1 process = 1 container), you no longer run 20-30 copies of an OS, just a single one.

And the container engine takes the place of the hypervisor.

Re: How does Docker affect energy consumption?

#43

Post by raulk »

AnsemWise wrote: post #39
CrLf wrote: post #37

Earlier quoted context omitted.

> Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). I'm starting to believe that the increased density provided by containerization is a myth, in practice. Both because orchestration tools bring their own overhead (compare all the proxies and…

Containers are an abstraction that exist using cgroups and namespaces for isolation. They use the hosts' kernel, it's not virtualized. Containers are only limited by the capabilities of namespaces and cgroups, unlike vms. You might be dismissing microservices too quickly. They do have overhead but so does any level of abstract; the benefit of them though is clear separation of responsibilities between services and re…

Using VMs to isolate single processes is like owning multiple toasters, and buying a different house to plug each toaster in.

Re: How does Docker affect energy consumption?

#45

Post by naasking »

raulk wrote: post #34

Doesn't this article fail to consider the bigger, practical picture, i.e. overall resource efficiency/footprint in multi-component architectures? Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). Example: consider you need to deploy not just a…

> Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources).

Ultimately there's no reason why containerization can't be pushed right down to the language level. Consider .NET's AppDomains, or even further, a capability-secure programming language which isolates at the object level with zero overhead over ordinary languages.

Re: How does Docker affect energy consumption?

#46

Post by acdha »

raulk wrote: post #42
CrLf wrote: post #37

Earlier quoted context omitted.

> Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). I'm starting to believe that the increased density provided by containerization is a myth, in practice. Both because orchestration tools bring their own overhead (compare all the proxies and…

> If you're running 20-30 containers on a beefy VM, you're not really condensing anything. You're just moving from running hundreds of small VMs on a single server to running much less larger VMs. Of course you are condensing. Those small VMs would have been running a full OS runtime each . Assuming you relocate those workloads onto a single machine (1 process = 1 container), you no longer run 20-30 copies of an OS,…

> Of course you are condensing. Those small VMs would have been running a full OS runtime each.

That's something but probably not as much as you think since hypervisors can share identical pages (e.g. the Linux kernel) across guests and the base footprint for a server Linux install is not that high as a percentage of the private data most applications use. Unless you're running a ton of unnecessary services on those guests or have an application which uses almost no RAM you're talking about a fairly modest percentage savings even before you factor in all of the things you might be running for container management and other overhead on that side.

The other thing to remember is that this works both ways: containers are great for being able to upgrade one component independently but that means that e.g. you might have a dozen different versions of a common shared library because not all of your containers are using the same base image & version and with Docker your storage driver might actually force shared libraries to be duplicated across all processes anyway.

Re: How does Docker affect energy consumption?

#47

Post by pbh101 »

raulk wrote: post #34

Doesn't this article fail to consider the bigger, practical picture, i.e. overall resource efficiency/footprint in multi-component architectures? Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). Example: consider you need to deploy not just a…

d) Deploy them directly to the same bare-metal non-virtual machine, without a VM or container.

Yes, you can get cross-app deployment conflicts (packaging, etc), and limits your cloud deployment options, but it is definitely another option and has lower overhead than any of the first three.

Re: How does Docker affect energy consumption?

#48

Post by raulk »

pbh101 wrote: post #47
raulk wrote: post #34

Doesn't this article fail to consider the bigger, practical picture, i.e. overall resource efficiency/footprint in multi-component architectures? Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). Example: consider you need to deploy not just a…

d) Deploy them directly to the same bare-metal non-virtual machine, without a VM or container. Yes, you can get cross-app deployment conflicts (packaging, etc), and limits your cloud deployment options, but it is definitely another option and has lower overhead than any of the first three.

That would defeat a major goal of isolation: security.

It also creates fragility. What happens if a process is buggy and rallies up to 100% CPU? It affects all others.

Although to solve these issues you could use cgroups and namespaces... Aaaand we're back to containers again.

Re: How does Docker affect energy consumption?

#49

Post by angry_octet »

raulk wrote: post #43
AnsemWise wrote: post #39

Earlier quoted context omitted.

Containers are an abstraction that exist using cgroups and namespaces for isolation. They use the hosts' kernel, it's not virtualized. Containers are only limited by the capabilities of namespaces and cgroups, unlike vms. You might be dismissing microservices too quickly. They do have overhead but so does any level of abstract; the benefit of them though is clear separation of responsibilities between services and re…

Using VMs to isolate single processes is like owning multiple toasters, and buying a different house to plug each toaster in.

Nah, that is separate physical machines. For VMs it's more like a multitenant toaster colo, with every toaster in its own asbestos cage, but sharing power and network^Wbread. For containers, it's like putting them all in one house but putting a fuse and RCD on every toaster. A traditional server is building a custom house each time and the toasters are all plugged into the same socket.

I'm not sure the toaster analogy will gain mass acceptance.

Re: How does Docker affect energy consumption?

#50

Post by pbh101 »

raulk wrote: post #48
pbh101 wrote: post #47

Earlier quoted context omitted.

d) Deploy them directly to the same bare-metal non-virtual machine, without a VM or container. Yes, you can get cross-app deployment conflicts (packaging, etc), and limits your cloud deployment options, but it is definitely another option and has lower overhead than any of the first three.

That would defeat a major goal of isolation: security. It also creates fragility. What happens if a process is buggy and rallies up to 100% CPU? It affects all others. Although to solve these issues you could use cgroups and namespaces... Aaaand we're back to containers again.

Agreed on both points. Either I missed your note about isolation on the first read or you edited.
Post reply on HN