Live data from Hacker News

MicroVMs: Run isolated sandboxes with full lifecycle control

aws.amazon.com

71–80 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#71
For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand.

This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#72

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…

I imagine you can have a situation where you let an agent run in a shared env but to access certain tools you spin up a VM just for the tool call duration and then shut it down again. Let’s say you wanna allow the agent to write and run code then you need it to run it somewhere safe

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#73

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…

Microvms are better for the VM provider. They use less memory and have a smaller attack surface. Also starting in 100ms means you don't need to add a bunch of async machinery when launching the vms.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#74

It's about time AWS got into the agent sandbox game. The startups in this space right now don't provide much value on top of the cloud providers they're wrapping. They don't tend to be run by experienced infra people either so they seem very vibecoded, insecure, janky, etc. They're also significantly overpriced because they're marking up already expensive providers. Something surprising from my own experience is that…

Major Sandbox providers (e.g. Modal) run on non-hyperscaler bare metal not AWS and so don't need to markup on AWS's markup. Thus, prices are comparable or better than AWS.

In that case it's still overpriced because they're charging hyperscaler prices without offering a hyperscaler level service in terms of scalability, reliability, security, trust, etc.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#75
post #50

Earlier quoted context omitted.

Setting up your own is not that hard and if you bought some compute before the Altman squeeze, very cheap.

Def! My personal belief is that the future of an "app" is a combo: 1. micro VM 2. agent on the VM 3. software bundled into the VM So, it should be stupid simple to run these local sandboxed apps/agents. Right now, not too hard for technical users (esp. with things like https://smolmachines.com/ and https://microsandbox.dev/ ), but not as easy as clicking an app icon or typing `/path/to/binary` in the CLI

Microsandbox claims to start faster than docker, and it is isolated from the host, and to work with OCI. Why would I still want to use docker? The only reason I can imagine is that I actually want to be able to dynamically share resources between containers instead of dividing up VMs a priori.

Ah, the significant compute overhead: https://josecastillolema.github.io/podman-wasm-libkrun/. Much more cpu and ram usage at worse performance.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#76

> 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…

Pretty sure they invented Firecracker for Lambda. Iirc they were previously using a hot pool of EC2 instances behind the scenes with each customer getting their own instances and lambdas sharing capacity on an instance. Firecracker made it possible to spin up VMs in realtime instead of having spare capacity laying around.

That said, Fargate does kind of seem like a superior option

Edit: I guess this supports suspend and fast resume so invocation time should be somewhat better than Fargate.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#77
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 uses) though I wouldn't use it myself yet.

People often look down on gvisor because they think it's some kind of syscall filter, it is not. It can use one of ptrace, seccomp or even KVM to intercept ALL syscalls and service them with it's own logic (which is in Go). Basically it's a VMM and kernel in one.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#78
post #59

It's about time AWS got into the agent sandbox game. The startups in this space right now don't provide much value on top of the cloud providers they're wrapping. They don't tend to be run by experienced infra people either so they seem very vibecoded, insecure, janky, etc. They're also significantly overpriced because they're marking up already expensive providers. Something surprising from my own experience is that…

AWS AgentCore runtime has been around for about a year: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguid... (spoiler, it's the same underlying technology as the Lambda MicroVMs).

To be fair to jacobgold, at this point there is more or less an AWS services announcement singularity: if you didn't see the announcement when it happened you may never catch up or even find it in the wretched console website.

Though I did know about this one! (Because I saw the announcement.)

Post reply on HN