3 ms·

I haven't seen anybody speak to one of his points and I'm curious about what HN thinks: if you're already using a cloud provider that provision's instances of t

I haven't seen anybody speak to one of his points and I'm curious about what HN thinks: if you're already using a cloud provider that provision's instances of the exact size you need, what benefit do containers bring? I'm excited by containers and all, but this point has always stopped me from going forward. If I were a huge company running bare metal, then yes I'd want to squeeze every last ounce out of my hardware. But if I'm running inside a hypervisor and somebody else is paying the cost, what are the benefits? As for the article: it comes across as a blend of frustration and real technical challenges. Some good points, though the hostile tone weakens the argument. I don't think Docker should worry too much about backwards compatibility right now, just power forward until it's got a solid formula. In the meantime, caveat emptor!

buzer 10y ago
If you are running 1-2 of copies or applications that very large amount of memory while being pretty small themselves, not much (and that's admittedly pretty common). However, if you, for example, need to run 20x copies of 50MB application that uses 100MB memory at runtime in somewhat isolated environment, you would only provision machine with 20x100MB+50MB=2050MB + whatever OS needs (~100MB?) to keep everything in memory. If you made VMs for each of them, you would need 20x100MB+20x50MB+20xOS overhead=5000MB'ish, 150% increase in this case. Also, starting up a container is a lot faster than starting a VM. If image is in the local cache, your application likely starts loading within 500ms. VM startup times are usually measured in minutes.
jacques_chester 10y ago
I can type cf scale -i 100 And have 100 copies of my app running in a few seconds, depending on cache warmth. Or a thousand. VMs booted up from images are much slower. And cloning checkpointed VMs is not apparently something AWS or GCP can do. Disclosure: I work for Pivotal, we're one of the companies who make `cf scale` possible.

buzer 10y ago

If you are running 1-2 of copies or applications that very large amount of memory while being pretty small themselves, not much (and that's admittedly pretty common). However, if you, for example, need to run 20x copies of 50MB application that uses 100MB memory at runtime in somewhat isolated environment, you would only provision machine with 20x100MB+50MB=2050MB + whatever OS needs (~100MB?) to keep everything in memory. If you made VMs for each of them, you would need 20x100MB+20x50MB+20xOS overhead=5000MB'ish, 150% increase in this case. Also, starting up a container is a lot faster than starting a VM. If image is in the local cache, your application likely starts loading within 500ms. VM startup times are usually measured in minutes.

jacques_chester 10y ago

I can type cf scale -i 100 And have 100 copies of my app running in a few seconds, depending on cache warmth. Or a thousand. VMs booted up from images are much slower. And cloning checkpointed VMs is not apparently something AWS or GCP can do. Disclosure: I work for Pivotal, we're one of the companies who make `cf scale` possible.