Live data from Hacker News

Hyper Is Docker Done the Right Way

thenewstack.io

11–20 of 37 posts

Re: Hyper Is Docker Done the Right Way

#11

Earlier quoted context omitted.

What overhead?

The benefit of a container over a full VM is meant to be that the container scheme has just one kernel running. This scheme would effectively be just one container per VM, thus negating the benefit. (Edit: So.. it would appear that the benefit is that they're read-only-sharing the kernel between VMs)

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.

Re: Hyper Is Docker Done the Right Way

#12

Earlier quoted context omitted.

What overhead?

The benefit of a container over a full VM is meant to be that the container scheme has just one kernel running. This scheme would effectively be just one container per VM, thus negating the benefit. (Edit: So.. it would appear that the benefit is that they're read-only-sharing the kernel between VMs)

That is the traditional thinking indeed, but not all VMs are born equal. Check out the underlying tech here: https://docs.hypercontainer.io/

Re: Hyper Is Docker Done the Right Way

#15
post #13

His final comments on K8s & GKE were the same conclusion I came to while migrating my personal website to k8s: http://www.eggie5.com/82-rails-docker-app-deployment-kuberne...

The value proposition (difference) of Hyper is that while other CaaS try to manage your VM cluster, Hyper makes the cluster just go away.

Re: Hyper Is Docker Done the Right Way

#16
post #2

Is this not what ECS aims to do?

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 convenience, in the case of some (many?) applications, perhaps those considerations can be ignored and the "container fabric" can simply be thought of as perfectly homogeneous, is that the idea? And if one grows beyond the point where that simplifying assumption doesn't hold, then it's time to switch to an architecture where clustering is explicitly addressed?

Re: Hyper Is Docker Done the Right Way

#18

Earlier quoted context omitted.

The benefit of a container over a full VM is meant to be that the container scheme has just one kernel running. This scheme would effectively be just one container per VM, thus negating the benefit. (Edit: So.. it would appear that the benefit is that they're read-only-sharing the kernel between VMs)

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 itself, and it starts in a fraction of the time because it doesn't have to boot anything. Performance and cost may be acceptable regardless, but that's not the point. Containers are more efficient.

Based upon responses from Hyper, they appear to address these concerns in a manner I have never heard before. I will certainly be looking into their core technology.

Re: Hyper Is Docker Done the Right Way

#19
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.

Interesting. I'll look into this further. Thank you for the insight.

Re: Hyper Is Docker Done the Right Way

#20

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…

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