Show HN: Hyper_ – Simple and Secure Container Cloud
blog.hyper.sh
blog.hyper.sh
Assigning userId client-side even before you hit the actual user database enables data to be sync'd anonymously across services with userId rather than email address. If you block this from running, yes, you block it from working.
In short, your ad-blocker is being overzealous.
More on this: https://github.com/superstrong-labs/pre-db-segment
That's a stripped-down, guest OS on virtualized platform. Basically same sort of thing that's common but with some differentiator.
The marketing copy appears, on this basis, to be somewhat misleading. It says on the site that this is a cloud where "multi-tenant containers can inherently be run safely side by side on bare metal, instead of being nested in VMs".
I think that, as an industry, we've established that "bare metal" execution of workloads means _without_ the multi-layered approach of a hypervisor (itself an OS) running a separate guest OS kernel.
I wouldn't use the word VM, as it reminds us of the heavy full-blown images. It is probably more misleading to say that HyperContainer launches your Docker image in VMs. But you are right, it is still new and requires efforts to get people understand.
[Edit: Removed rest of comment to limit negativity. Thank you for responding to clarify.]
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.
What parts of a machine do traditional data center VMs emulate that Hyper avoids?
What system functions normally supported by a guest OS will Hyper not need to support? (E.g., memory management, network stack?)
- inefficient use of resources resulting from functionality duplicated in both the hypervisor and the guest (e.g., two TCP stacks, two filesystem implementations, two schedulers, and so on). (That's why I asked about this in a separate comment.)
- inefficient use of resources resulting from the inability to dynamically share resources between VMs (e.g., memory and disk typically have to be statically allocated to VMs, instead of sharing a common pool the way processes within a single Unix-like system typically do).
- poor visibility from the hypervisor into the application (i.e., observability tools cannot typically cross the hardware-virtualization boundary).
That's just a partial list.
I think that's why you're seeing pushback from people insisting that these be called VMs rather than containers: they have all of the above downsides of VMs, even if the operating system surface area isn't that large.
[edited for formatting]
It sounds like this is part of the guest kernel.
[edited to flesh out what I meant]
I don't understand this. Isn't using a hypervisor the same as using a VM? How is this different from using VMware, Xen, etc. to run a stripped down VM with a tiny kernel inside to handle Docker?
I understand boot up completes in under a second but if one needs to setup an environment to do something useful, it can take several seconds. I guess what I'm getting at is why would the fast boot matter when one still needs to setup a basic environment to complete a task?
This is analogous to achieving an artificially low TTFB but actual rendering doesn't start until several seconds later.
Am I missing something?
Thanks
But, the thumb-rule is that if the startup time is a free lunch, why not faster?
1) Are there any competitors? 2) Can we be confident in building our business on this platform? What is the funding and stability situation of Hyper?
1) AFAIK, this is the first secure container cloud. 2) You can play with it, but better wait till out of beta 3) We are funded :)
We appreciate your vigilance in watching out for a fellow user. It's better to send these to hn@ycombinator.com though. That way we're sure to see them, and the threads don't go as off topic.