gnepzhao

Hyperd has been merged into Kata (katacontainers.io).

Simply put, it allows you to run multiple-tenants' code (image) over shared infrastructure.

Think about why all public clouds are built with virtualization technology. Multi-tenants require strong isolation, which virtualization promises. Therefore, if we could get strong isolation in container, we can build public cloud with container.

Kata is the merge of ClearContainer and Hyper's runV.

Disclosure: I work at Hyper.sh

We have an open source project for this: github.com/hyperhq/hypernetes. Basically use k8s to schedule hypervisor-based secure containers.

Thanks for the detailed input. They are tremendously valuable.

Part of the reason we chose to open source is that we want the community to innovate. We are continuing to build the feature set, however I need to say that the workflow varies from app to app. Therefore, by providing the base building block and allowing others to create different solutions, we could enable more options to the market.

We don't want to compete with the big providers, instead we open source the tech to enable more container-native clouds, where the world will become a seamless (portable) network for containers (different clouds are different ports with the same image spec and API).

github.com/hyperhq/runv

Hi,

I'm one of cofounders of Hyper. Thanks for mentioning us!

I think both ECS and GKE are valid options their segment. Things like ACI and Hyper.sh is more of a container-native IaaS. The on-demand event-driven compute infra is a perfect use case, but it also works for long-running workload (k8s pool), where the difference is that developers only need to consume the k8s api, not the software itself.

Founder kicks in.

The vision is to merge PaaS into IaaS, e.g. a microservice-native cloud. I want to ask more details of the upper-layer features you imagine. Thanks!

Yes, we are looking to expand to Europe, probably Frankfurt or Amsterdam.

I'd like to keep in touch. Could you drop a message to peng at hyper.sh? Thanks.

Check https://docs.hyper.sh/Feature/container/service.html.

Kind of similar to LB+ReplicationSet in K8S, not automated scaling yet. But will do.

Sure, join our slack channel https://slack.hyper.sh/, and DM me there @gnepzhao. See you around!

Price reduction is on the way :)

I would say Unikernel is more close to that.

Think a Docker-based, language-agnostic, unlimited version of "AWS Lambda". That's it!

We are going to release it very soon. Stay tuned :)

Hi, sorry about the confusion. We do this just to prevent abuse, e.g. per-second billing for IP.

PS: I work at Hyper.sh

Hey all, founder is here. I'd like to thank you for your votes here. Really appreciate!

Also, I just want to share our public roadmap: https://trello.com/b/7fEwaPRd/roadmap. Feel free to comment. It actually helps a lot for us to prioritize. Thanks!

1. Yes, though there is quite some engineering efforts needed (running a cloud is TOUGH)

2. In a few months

3. TBD

4. Yes, we are looking to expand the DC and add more options.

BTW, our public roadmap: https://trello.com/b/7fEwaPRd/roadmap

Hi, there are plugins for Buildbot and Jenkins github.com/jenkinsci/hyper-slaves-plugin, which are more like a "Serverless" CI/CD solution.

PS: I'm the founder :)

Hey, founder kicks in.

Yes, NYC and Europe are our next step. Probably Frankfurt or Amsterdam.

Hi, founder is here.

1. Yes, our SW is open sourced: github.com/hyperhq 2. Not really, Hypercontainer runs on bare-metal, as it uses hypervisors (KVM, Xen) underneath.

If you have the docker image ready, hyper.sh is a no-brainer place to host your app.

Hi,

Founder is here.

I'd that they are both trying to solve the container hosting issues, but with very different approaches.

Docker Cloud = VM cluster + Swarm, meaning that it is essentially a managed VM service. For developers, Docker Cloud creates the cluster on other cloud providers, and manage the cluster to deploy containers for you. In other words, you can focus on containers, the infrastructure is managed by Docker Cloud for you (of course you need to pay for that).

On the other hand, Hyper.sh is container native. You simply run containers, with worrying the cluster, not because it is managed, but that there is no cluster at all. How? Hyper.sh is built on secure Docker runtime, which is as fast as linux container, but as secure as VM. Therefore, the secure container becomes the new build block, rather than being nested in VM for isolation.

Given this, the whole cluster, capacity planning, scheduling and management thing is gone in Hyper.sh. And yes, you no longer need to pay for the cluster management.

Same with Docker, you can just "hyper login", then pull the images.

Yes, currently no shared volume.

I think the website states it well:"Say goodbye to VMs Unlike traditional IaaS where containers run in VMs, you will only work with containers in HYPER_. However, containers are protected by hardware-enforced isolation, meaning that they are as secure as a VM."

Founder is here.

Yes, "hyper pull" work seamlessly with any Docker registry, public or private.

For persistent workload, Hyper_ provides the EBS-like volume, e.g. "hyper run -v vol:/path", but the volume is not local, instead it is distributed and replicated. And similar to EBS, you can create snapshots and restore to new volumes.

Well, I think you made an excellent point which is hard to argue with.

But, the thumb-rule is that if the startup time is a free lunch, why not faster?

Let me be more clear. The problem of VM is not virtualization (or hypervisor), the problem is "Machine". For a long time, we try to emulate a complete machine with a complete "OS" running atop. What Docker really changed is to make us realize that all we need is the app, not a full OS. Therefore Docker image is an app-centric package, nothing specific to Linux container. Yes, it runs with Linux container, but you can also launch it with a hypervisor in 100ms.

Shall we call hypervisor+kernel+Docker image VM? I don't think so. It never tries to give you a complete machine, neither a full OS. Personally I like "virtualized container". But the combination of these two words might be more confusing, given that whenever you see the word "container", you think of Linux container.

TCP yes, but the filesystem is provided by the Docker image.