Hyper launches as open-source distributed Firecracker microVM orchestrator in Elixir

Hyper - distributed Firecracker microVM orchestrator written in Elixir

Hey everyone! One of the problems I ran into is that a large part of the VM-provider ecosystem is currently paid closed-source SAAS products with varying degrees of reliability. I wanted an OSS distributed microVM orchestrator and I couldn't find one. Hyper is a distributed FirecrackerVM orchestrator written in Elixir (BEAM), with gRPC support for non-BEAM clients. Hyper is: Distributed -- it's designed to run across a cluster of bare metal machines, and will automatically connect to other Hyper nodes. Fast -- it builds COW layers to enable fast, localized COW forking. Cold boots happen within 1s. Filesystem forks take ~50ms. Forked VMs are colocated to take the fast path as much as possible. Interactive -- like all Elixir applications, if you can connect to the cluster, you can spawn, manage, monitor and interact with VMs live in an iex REPL. Or, you can use the gRPC interface if your system isn't on the BEAM. Yours -- although I developed this primarily for Harmont (which is paid), Hyper is an MIT-licensed project and will remain such. Self-contained -- all we need is a side-car Postgres instance. Configurable -- colocation, vmlinux options, etc. can all be customized. Secure -- everything runs on the BEAM; a single setuid Rust helper performs the few operations that need root, keeping the privileged surface small. Fair warning: the software is still in active testing and I expect a couple more features to be added soon: Automatic cloud provisioning -- when you run out of headroom in your cluster, you should be able to fall back to Latitude/GCP/AWS to provision more compute. More testing -- I am currently integrating Hyper into harmont.dev and will likely run into some issues. Fuzzing is part of the roadmap. Better docs -- I spent some time working on the docs, but they're definitely not total nor ideal. Very open to feedback, critique, and/or contributions. Please open any issues on Github, or feel free to DM/email me. It's available at https://github.com/harmont-dev/hyper PS. A couple people asked how this differs from firecracker-containerd and Kata containers. Both of those projects are runtimes for managing VMs on a single node. A fair mental model for Hyper is an amalgam of firecracker-containerd and k8s.

1 hour ago

Show HN: Hyper – distributed Firecracker microVM orchestrator written in Elixir

Hey everyone! One of the problems I ran into is that a large part of the VM-provider ecosystem is currently paid closed-source SAAS products with varying degrees of reliability. I wanted an OSS distributed microVM orchestrator and I couldn't find one.Hyper is a distributed FirecrackerVM orchestrator written in Elixir (BEAM), with gRPC support for non-BEAM clients. Hyper is:- Distributed -- it's designed to run across a cluster of bare metal machines, and will automatically connect to other Hyper nodes. - Fast -- it builds COW layers to enable fast, localized COW forking. Cold boots happen within 1s. Filesystem forks take ~50ms. Forked VMs are colocated to take the fast path as much as possible. - Interactive -- like all Elixir applications, if you can connect to the cluster, you can spawn, manage, monitor and interact with VMs live in an `iex` REPL. Or, you can use the gRPC interface if your system isn't on the BEAM. - Yours -- although I developed this primarily for Harmont (which is paid), Hyper is an MIT-licensed project and will remain such. - Self-contained -- all we need is a side-car Postgres instance. - Configurable -- colocation, vmlinux options, etc. can all be customized. - Secure -- everything runs on the BEAM; a single setuid Rust helper performs the few operations that need root, keeping the privileged surface small.Fair warning: the software is still in active testing and I expect a couple more features to be added soon:- Automatic cloud provisioning -- when you run out of headroom in your cluster, you should be able to fall back to Latitude/GCP/AWS to provision more compute. - More testing -- I am currently integrating Hyper into harmont.dev and will likely run into some issues. Fuzzing is part of the roadmap. - Better docs -- I spent _some_ time working on the docs, but they're definitely not total nor ideal.Very open to feedback, critique, and/or contributions. Please open any issues on Github, or feel free to DM/email me.PS. A couple people asked how this differs from firecracker-containerd and Kata containers. Both of those projects are runtimes for managing VMs on a single node. A fair mental model for Hyper is an amalgam of firecracker-containerd and k8s. Comments URL: https://news.ycombinator.com/item?id=48849161 Points: 1 # Comments: 0

2 hours ago