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: Run isolated sandboxes with full lifecycle control
191–200 of 222 posts
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#192Re: 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…
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
#194What'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…
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#195Earlier 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.
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
#196Earlier 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.
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#197Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#198Earlier 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.
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#199Earlier 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
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…
Still, it does feel overly complicated. Google's "Cloud Run" is way simpler.
(Lambda also has its own DX issues.)