Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MicroVMs: Run isolated sandboxes with full lifecycle control

aws.amazon.com

Post reply on HN
Print view View original

181–190 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#181

Post by fulafel »

0xbadcafebee wrote: post #47

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

Also you've been able to run container images in Lambda for some years now.

https://docs.aws.amazon.com/lambda/latest/dg/images-create.h...

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#182

Post by spockz »

NamlchakKhandro wrote: post #156
spockz wrote: post #75

Earlier quoted context omitted.

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

Starting faster than a container will need evidence since starting a container on Linux is basically instant.

It is instant for me when using podman but by no means instant when using docker. Docker on Linux native is stay way faster than on macOS and Windows. But so far running with podman has the lowest overhead I have seen.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#183

Post by binsquare »

easton wrote: post #104
eyjafjallajokul wrote: post #60

Earlier quoted context omitted.

Source? https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir... says > Battle-Tested – Firecracker has been battled-tested and is already powering multiple high-volume AWS services including AWS Lambda and AWS Fargate.

Counterpoint: https://justingarrison.com/blog/2024-02-08-fargate-is-not-fi... And also, you’ll notice that Fargate takes minutes to launch while Lambda takes a second or less. You’re waiting on AWS to launch a EC2 with your config and pull your containers into it. (that article matches things I heard from Amazon when I asked why my stuff is slow)

Confirming, I worked directly on fargate.

Fargate does not use firecracker. It was used for some internal workloads but was being migrated off at the end of 2025.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#184

Post by happens »

spockz wrote: post #75
dbmikus wrote: post #50

Earlier quoted context omitted.

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

The performance difference in that post is due to wasm, not the container runtime, which is also stated at the end of the post.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#185

Post by znpy »

dbmikus wrote: post #32

There are sooooo many sandbox providers out there. They do spike on different features like: - snapshotting and forking - good SSH and VPN access for end-users - agent-friendly features, like obscuring secrets at network layer Then there's also the option to use libkrun to run local sandboxes on your own computer. That doesn't scratch the itch for hosted services, but works if your goal is to run agents inside isolat…

We’re adopting agent-sandbox (https://agent-sandbox.sigs.k8s.io/) as we already run most if our stuff in kubernetes and it’s been working very well, the only downside being it’s a moving target as it’s still essentially in development.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#186

Post by mkagenius »

rsyring wrote: post #148
messh wrote: post #131

An interesting alternative: https://shellbox.dev - manage linux vms via ssh, pay only for what you use. It is much cheaper, no subscription is needed, supports nested virt, docker, custom images, duplication of boxes, gives an ipv6, auto-stop on optional auto stop on disconnect, wakeup on web endpoint hit, email endpoint, exposed ipv6, and more. Parked boxes are just $0.5/month. Create small or large boxes up to 16vc…

Only EU currently

Have you tried https://instavm.io in US

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#188

Post by binsquare »

tough wrote: post #172
dbmikus wrote: post #50

Earlier quoted context omitted.

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

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

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#189

Post by ilaksh »

tptacek wrote: post #165
ilaksh wrote: post #154

Earlier quoted context omitted.

Why is it that you claim limits are unworkable? If you can track or enforce it (others have been for years) then couldn't you make it an optional field or checkbox?

Every limit is a commanded outage. We can refund an unexpectedly high bill. We can't refund downtime.

So write "WARNING: your service will go down if you exceed this limit. We cannot provide refunds for this. To avoid outages in the event of unanticipated traffic, do not enter a spend limit."

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#190

Post by sonink »

TacticalCoder wrote: post #48

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 dont get it either - I was going to ask the same question but found this.

We have been doing the exact opposite - instead of micro VM's we are giving agents larger VMs.

Previously we were giving them 1GB RAM VM's - now we have upped to 4 GB RAM VM's. When the agent is working - the real cost is in the inference. There is no reason to keep the agent waiting because your VM is too damn slow. So we moved to larger and faster VMs.

The agent might install a package, or run a script - and now it moves along just faster. Not to mention that if the agent is installing a 'fat' SDK, like maybe android sdk, a thicker RAM just moves along everything smoothly without breakages. The incremental amount we pay for the bigger VM is more than justified by the increase in agent performance.

And all the tooling that has already been built up for standard human operated VM's just works pretty well out of the box. We are able to spin up VM's pretty much on demand and purge them clean once the work is done.

We are moving to 8 GB RAMs/4CPUs sometime this year, and GPU's hopefully sometime next.

Post reply on HN