Live data from Hacker News

MicroVMs: Run isolated sandboxes with full lifecycle control

aws.amazon.com

211–220 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#211

Earlier quoted context omitted.

I was going to add a comment praising smolmachines' smolvms. Simple, fast (sub-200ms cold start), OCI-compat, and has trivial packing to standalone 0-dep executables. No need for Docker Desktop / colima / orbstack. For those who prioritize security, kernel isolation is a meaningful benefit.

No programmable network stack though, so can't pass fake credentials to things inside vm and exchange them on the boundary

Hmm. I wonder if use of env vars might help solve for related use cases.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#212
post #208

Earlier quoted context omitted.

Which implies that you cannot reasonably serve the "disfavored" cohort (self-funded startup or small business). In other words, you have admitted that I was correct in that the business model is deliberately aimed at businesses that likely can absorb surprise expenses, and it's not appropriate for others.

We probably have different definitions of "small business". At any rate: my only point here is, it's not our business model to earn a premium off surprise bills. Railway does hard billing limits! Railway's great. Use them! I'm not here to sell you on Fly.io.

Sorry, I was just curious, i think i'd consider fly more after this exchange than less tho, thanks for all the info.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#213
post #212

Earlier quoted context omitted.

We probably have different definitions of "small business". At any rate: my only point here is, it's not our business model to earn a premium off surprise bills. Railway does hard billing limits! Railway's great. Use them! I'm not here to sell you on Fly.io.

Sorry, I was just curious, i think i'd consider fly more after this exchange than less tho, thanks for all the info.

I'm just a message board nerd message board nerding about something I believe to be true. :)

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

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

> dynamically share resources This has been a big pain point me with various VM solutions I’ve tried. Having to allocate say 8GB to a sandbox, and a) having that RAM eaten up when I’m not using it and b) only having 8GB when I am using kinda sucks. Yes, I could stop the sandboxes when I’m not using them, but that also kinda sucks.

[deleted]

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

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

> dynamically share resources This has been a big pain point me with various VM solutions I’ve tried. Having to allocate say 8GB to a sandbox, and a) having that RAM eaten up when I’m not using it and b) only having 8GB when I am using kinda sucks. Yes, I could stop the sandboxes when I’m not using them, but that also kinda sucks.

[dead]

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#217
post #190

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…

FYI, a microVM isn't a small VM, nor necessarily one that has been allocated little RAM.

The term comes from the fact that a microVM is launched with Firecracker (a Virtual Machine Monitor), and Firecracker itself, as far as Virtual Machine Monitors go, doesn't consume many resources per VM and can start them relatively fast.

Given this, an 8GB agent VM started with Firecracker would still be a microVM. Firecracker doesn't place restrictions on how much memory you can assign it.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#218
post #142

Earlier quoted context omitted.

That's the approach I initially took, but experienced some combination of noticeable stuttering and latency regardless of which buffering strategy I tried... Had to switch to a shared memory ring buffer, along with some adaptive playback speed shenanigans (sometimes imperceptibly speeding up playback when falling behind production of audio samples, sometimes imperceptibly slowing down when there's less than a few mil…

There is something wrong with your setup. I just tried: bwrap ... --ro-bind /run/user/1000/pipewire-0 /run/user/1000/pipewire-0 ... -- runsc ... do ... -- mpv podcast.mp3 Flawless playback. I think it's a default pipewire configuration.

Ah, I see the distinction. In my case, I was using the PulseAudio client+server with a network sink running in-sandbox, producing a set of audio samples that are then replayed by a PulseAudio client in the out-of-sandbox Rust application receiving these samples. Exposing the socket directly to the sandbox is dangerous, e.g. it would let the sandbox record the host's microphone directly.

My goal was for the sandbox to only have access to a single dumb playback sink and no other access by default, and to gate any further access (e.g. microphone access) in something the out-of-sandbox software can catch and ask the user about before it is granted to the sandbox.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#219
post #23

Earlier quoted context omitted.

Fly.io doesn't set a maximum of 8 hours of alive time on your instance. Also, MicroVMs can't be exposed directly to the web. Your code running in them can only be executed via API calls with attached auth tokens - so if you wanted to host a public facing API or website with them you'd need to implement your own additional layer in front. Something I appreciate about Fly (disclaimer: they support my work) is that the…

I'm pretty proud of this: https://fly.io/blog/accident-forgiveness/ A way we simply suck at business: we didn't keep beating the drum about this after we wrote the policy up. We just sort of figured everyone read the blog post and moved on. We probably should have been continuously making noise about it. What you get from having a company made almost entirely of engineers.

Reminding of my most cited academic paper… one of the co-authors was a tenured professor about to go on sabbatical and so he was happy to have a fresh paper to present at all his sabbatical tour stops. That paper picked up so many cites from him doing that! (He wrote around two paragraphs of the 30 page paper but we were still all very happy to have him basically running the paper’s marketing campaign all by himself!)
Post reply on HN