Live data from Hacker News

MicroVMs: Run isolated sandboxes with full lifecycle control

aws.amazon.com

191–200 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#191

What's the point of microVMs for running agents? Are you guys literally spinning up agents where a 100 ms boot time vs a 3 seconds boot time makes a difference? I'm asking because I understand the appeal of micro VMs but every time the subject comes up people talk about "isolating agents": what's wrong about isolating agents in a regular VM (or in a container which, itself, is in a VM)? FWIW I've got my stuff nicely…

[flagged]

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#193

> Containers launch in seconds, yet their shared-kernel architecture requires significant custom hardening to safely contain untrusted code That's literally why they made Fargate. It's managed firecracker VMs with containers. They invented firecracker for this purpose. This new product is competing with Fargate, but they don't mention Fargate at all in the announcement. > you create a MicroVM Image by supplying a Doc…

Fargate (with Firecracker/Docker) is hellishly complex and forces you into all sorts of AWS BS, first of which is it can't run without some sort of orchestration layer like EKS or ECS.

To deploy on ECS, the simplest option, means that you have to create a private Docker registry, sync base images from docker.io you use, set up IaC, set up a deployer and user identity, create a multiple subnets to allow redundancy, set up health checks, and I didn't even write down the half of it.

If you want a simple enterprise CRUD interal tool, its crazy. And the WORST thing, is that it doesn't have persistent disk, so you either are forced to use slow and expensive EFS or buy into AWS's expensive managed database systems.

And every update to your app goes through a k8s style 'sync image-drain old servers-create new ones-switch over once healthy cycle'. Which has a tendency to fail for mysterious reasons, oh and its undebuggable, and should you notice that an env var is set up incorrectly, you can't just fix it, it means a whole deploy cycle.

I wouldn't wish that stuff on my worst enemy.

In contrast, if you want okay DX, you either go with Lambda, and manage your own EC2s.

Half of AWS's offerings exist to work around the arbitrary limitations they put on their services, as even this thing (as others have correctly noted), comes with this weird 8 hour limit, but even that's far easier to work around (for stuff like running a simple server), than having to deal with the other stuff.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#194
post #18

What's the best provider to self-host Firecracker? I feel that AWS is not a safe or cost-effective option for a self-funded startup or small business. Although is anything cost effective anymore? Hetzner just had a massive price hike. Part of it might just be that I am old and inflation is catching up with my understanding of prices. But as far as AWS I still have to say no thanks. Imagine some group actually started…

The simplest worthwhile DIY sandbox you can have is to layer two tools: bwrap and gvisor. bwrap args -- gvisor args do args -- /path/sandboxee args bwrap will set up the environment and then gvisor elevates it into a true sandbox. Standalone gvisor (not the 'do' subcommand) used to be a mess with the OCI json requirement, but recently they began work on presenting their own bwrap interface (likely to pursue AI agent…

Why do you need gvisor and not just bwrap? Is this a "more is better" thing?

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#195

Earlier quoted context omitted.

Why isn't libkrun good enough for hosted stuff? I use it as a podman backend in a microservice architecture.

That's super interesting - have you written up anything on this? I'd love to read it.

No, but I can give a small introduction. I installed krun from the arch package repositories: https://man.archlinux.org/man/extra/krun/krun.1.en

Then one can just pass `--runtime krun` to most podman subcommands. Alternatively, set the runtime key in the config file to make it the default.

Podman itself has "hardening" techniques, e.g. turning off the network or volumes that can be combined with this.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#196
post #177

Earlier quoted context omitted.

Why isn't libkrun good enough for hosted stuff? I use it as a podman backend in a microservice architecture.

libkrun is not production ready compared to Firecracker which the latter is used in 99.9% of many companies.

For what exact reason is it not production ready? Or is that the stance of its maintainers?

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#198
post #49

Earlier quoted context omitted.

Why isn't libkrun good enough for hosted stuff? I use it as a podman backend in a microservice architecture.

Firecracker has more tooling for the orchestration layer that manages many sandboxes at once. Stuff like K8S integration, an external REST API control plane, more first-class support for snapshotting, etc. You'd have to build more of that with libkrun The core tech of both are great though.

Firecracker has more tooling, but setting ist up and managing it is also more complicated, at least for k8s workloads. Libkrun is so easy for k8s! Compile crun with Libkrun support, crate a symlink of crun with the name krun, done. Works like any normal pod. Firecracker with kata-containers is a lot more brittle and complicated. I've invested quite some time getting this running for a talk I'm working on

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#199
post #172

Earlier quoted context omitted.

heh I vibe-coded a little local app to have smolmachines and tart, for smolmachines i had to vibe-fork 2 deps deep to get GUI support working, but now i have linux desktop computers on smol machines! also have support for lima/colima/podman

Would like to see this! Wonder how you got GUI support working because with vulkan support - you effectively enable running games cross platform

VNC/RFB as the transport, but not just a guest-side x11vnc. I forked the local SmolVM path to start libkrun with display enabled, expose the framebuffer + keyboard/pointer input, then serve that over a loopback passworded RFB endpoint. Local Machines waits for display_ready and embeds it. It has to be selected at VM start; no hot attach yet.

The interesting bit is the libkrun GPU/framebuffer/input plumbing; VNC is just how I got the pixels into the macOS app. The guest still needs a real graphical workload/compositor, e.g. Weston.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#200

> Containers launch in seconds, yet their shared-kernel architecture requires significant custom hardening to safely contain untrusted code That's literally why they made Fargate. It's managed firecracker VMs with containers. They invented firecracker for this purpose. This new product is competing with Fargate, but they don't mention Fargate at all in the announcement. > you create a MicroVM Image by supplying a Doc…

Fargate (with Firecracker/Docker) is hellishly complex and forces you into all sorts of AWS BS, first of which is it can't run without some sort of orchestration layer like EKS or ECS. To deploy on ECS, the simplest option, means that you have to create a private Docker registry, sync base images from docker.io you use, set up IaC, set up a deployer and user identity, create a multiple subnets to allow redundancy, se…

ECS/Fargate is annoyingly complex but you can have Claude or whatever you prefer crap out some terraform to set most of it up in a few minutes. We did that for a recent project and it worked well enough that nobody complained... much. Still, the redeploy / app update scenario required some fiddling.

Still, it does feel overly complicated. Google's "Cloud Run" is way simpler.

(Lambda also has its own DX issues.)

Post reply on HN