scprodigy

Hyper.sh is faster, launching your Docker image in 5 seconds.

What control do you have?

How long does it take launch it on triton?

Did you try the test with a FIP?

In my experience, it takes 1min to launch a container in Triton, but 5-10s in Hyper.

Check out: https://trello.com/c/zAc1ia2E/53-hyper-func

No, they are in different games basically.

Let's say you have two images: web and db. Web containers ask for high cpu, but small disk. DB requires big mem and disk.

With GKE, you either have different instance types for different container sizes; or you launch the BIG&TALL VMs for all.

The same story applies to public/private network as well. Point is that in GKE, there are two layers to manage: VM and Containers. In Hyper, the container is the infra.

Don't think so. Though their stack are open source.

They don't use Linux container, they use hypervisor-based container (see: github.com/hyperhq/hyperd). Therefore it is VM-level isolation.

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.

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

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

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.

What overhead?

website: https://hyper.sh

check https://hyper.sh container-based cloud

A patch is available: https://issues.apache.org/jira/browse/MESOS-3435

Actually, scaleup is pretty easy for both VM and Linux container. But scale-down is very troublesome for both.

And the scheduler will need the mem size (not right now, but inevitable)

LXD = VM-like Linux container HyperContaineer = (Docker) Container-like ultra-light VM

Make sense?

So we end up with:

HW -> EC2 scheduler -> VM -> You -> Container scheduler -> Container -> App

There should not be two schedulers if container is secure for multi-tenancy.

Totally not!

No, it is HyperContainer.

https://github.com/hyperhq/hyperd

check github.com/hyperhq/hyperd

No, the problem of VM is not virtualization, but the notion of "machine". What Docker really does is to get rid of the full-blown machine/guest os, and focus on app. As such, you can run Docker image with Linux container for sure, you can also run it with hypervisor, which is surprisingly fast to boot too (<100ms).

In my own VM, or share a VM with others?

What about execution isolation? Any info?

Then how different containers get isolated from each other?

Yes, the point is that decentralization consensus doesn't help.

Guess the question is why you want a network of nodes, all of which may append a fake record, if you only want no one to change the data.