Live data from Hacker News

Hyper Is Docker Done the Right Way

thenewstack.io

21–30 of 37 posts

Re: Hyper Is Docker Done the Right Way

#21

Earlier quoted context omitted.

The difference between Hyper and ECS is that ECS (and Docker Cloud, and GCE) all require that you provision and manage your own Docker server cluster. With Hyper this is abstracted away which has a few benefits. Hyper also runs on HyperContainers ( https://docs.hypercontainer.io/ ) which provides secure (VM like) multi-tenancy with container agility.

But at some point doesn't one need to think at the granularity level of clusters? In other words, there are natural limits to how big the hosting environment can grow, at which point performance and efficiency with respect to network topology and other host-system factors (in the broadest senses, e.g. at the level of data centers and the tech-pieces from which they're built) must be considered. For reasons of conveni…

Broadly yes.

You could apply a similar argument to Digital Ocean or other providers. It is feasible that you could outgrow any provider, but in practice they would be able to scale before you hit that problem.

Is that what you meant or did I misunderstand?

Re: Hyper Is Docker Done the Right Way

#22
post #18

Earlier quoted context omitted.

In terms of a public cloud service, you (customer) don't care. You pay for the amount of memory you used, whether there is one kernel, or many of them, is irrelevant.

It is absolutely relevant: If your container is running its own kernel, then it is consuming memory for that kernel, not to mention the CPU overhead of the hosted kernel. Additionally, every container must also boot a complete OS. More overhead. This is why traditional containers use a shared kernel with process group isolation. You pay for what you use. A traditional container only uses what it needs for the app its…

But you don't own the server, thus you don't pay for the overhead (if any).

Re: Hyper Is Docker Done the Right Way

#23

Earlier quoted context omitted.

But at some point doesn't one need to think at the granularity level of clusters? In other words, there are natural limits to how big the hosting environment can grow, at which point performance and efficiency with respect to network topology and other host-system factors (in the broadest senses, e.g. at the level of data centers and the tech-pieces from which they're built) must be considered. For reasons of conveni…

In that sense, shall we care whether the EC2 instances in the ECS cluster are located at the same server, or the same rack?

It would depend on "how things are wired together". Now, it's great if they are "wired together" in such a way that one need not give it any thought. But whether we're talking EC2 instances or containers, at some point one has to think about it, e.g. two instances talking to each other, one being on the East Coast USA and the other in the Midwest, or West Coast, vs. their both being in the same datacenter. That's at the extremes, for sure, but maybe even intra-dc clustering has to be considered explicitly for certain applications? Maybe not?

Re: Hyper Is Docker Done the Right Way

#24
post #18

Earlier quoted context omitted.

It is absolutely relevant: If your container is running its own kernel, then it is consuming memory for that kernel, not to mention the CPU overhead of the hosted kernel. Additionally, every container must also boot a complete OS. More overhead. This is why traditional containers use a shared kernel with process group isolation. You pay for what you use. A traditional container only uses what it needs for the app its…

But you don't own the server, thus you don't pay for the overhead (if any).

I'm sorry, but you don't know what you are talking about. You pay for what you use. I don't own Amazon's servers either, but I pay for every bit of memory and CPU time that my EC2 instances use, and that includes the memory and CPU time consumed by my instance's kernel.

Re: Hyper Is Docker Done the Right Way

#25
post #6

> "CoreOS, DigitalOcean, and Docker are sponsors of The New Stack." Interesting and somewhat funny

Another funny thing is that Docker just got slapped in the face "Docker in Production: A History of Failure" ( https://news.ycombinator.com/item?id=12872304 ).

I wouldn't consider that a slap in the face. It's a rant, it's not the first about Docker and it won't be the last. Docker seems to be doing just fine despite that and many posts like it. Though the author has some good points it's riddled with statements that range from dubious to factually false.

Re: Hyper Is Docker Done the Right Way

#26
post #24

Earlier quoted context omitted.

But you don't own the server, thus you don't pay for the overhead (if any).

I'm sorry, but you don't know what you are talking about. You pay for what you use. I don't own Amazon's servers either, but I pay for every bit of memory and CPU time that my EC2 instances use, and that includes the memory and CPU time consumed by my instance's kernel.

Ok, I'm a bit lost too. So, your question is the memory consumed by the VM kernel? The tradeoff is the ops overhead to manage the VM instance.

Re: Hyper Is Docker Done the Right Way

#27

Earlier quoted context omitted.

In that sense, shall we care whether the EC2 instances in the ECS cluster are located at the same server, or the same rack?

It would depend on "how things are wired together". Now, it's great if they are "wired together" in such a way that one need not give it any thought. But whether we're talking EC2 instances or containers, at some point one has to think about it, e.g. two instances talking to each other, one being on the East Coast USA and the other in the Midwest, or West Coast, vs. their both being in the same datacenter. That's at…

The point is that you should stop thinking about VM cluster, but container (application) cluster, aka microservices.

Re: Hyper Is Docker Done the Right Way

#28
I like the initial idea very much. As I can see this is a wrapper over QEMU and controlled by QMP [1][2], so they are providing a kernel, initrd and a image. It is also configuring a machine profile (memory, vcpu, bus, devices, etc.). There are also interfaces for libvirt, xen and others virtualization technologies.

This also looks similar of what Docker is doing now in Windows with HyperV.

My question here is: from where comes the speed improvement in relation with a classical VM approach?

[1] https://github.com/hyperhq/runv/blob/master/hypervisor/qemu/...

[2] https://github.com/hyperhq/runv/blob/master/hypervisor/qemu/...

Re: Hyper Is Docker Done the Right Way

#29
post #28

I like the initial idea very much. As I can see this is a wrapper over QEMU and controlled by QMP [1][2], so they are providing a kernel, initrd and a image. It is also configuring a machine profile (memory, vcpu, bus, devices, etc.). There are also interfaces for libvirt, xen and others virtualization technologies. This also looks similar of what Docker is doing now in Windows with HyperV. My question here is: from…

The most significant improvement comes from the BootFromTemplate, which improves speed and saves memory. And the boot sequence and guest kernel have been optimized.

Re: Hyper Is Docker Done the Right Way

#30
post #10
post #5

Other than using the Docker format / API, how is this not just a variant VM deployment strategy? If every container is running its own kernel on a hypervisor, doesn't this eliminate one of the key benefits of a true Container system, the kernel/memory overhead?

With HyperContainer, we make the performance/overhead of virtualized container similar to linux container --- 130ms launch time, and sharing the read-only part of memory (kernel and init). As a result, we can use it as a more secure container.

Can you summarize how you're doing this, e.g. the similarities and differences from Linux containers?
Post reply on HN