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

201–210 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#201

Post by dbmikus »

kodama-lens wrote: post #198
dbmikus wrote: post #49

Earlier quoted context omitted.

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

Is the talk going to be shared online anywhere? Would be interested in checking it out later!

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#202

Post by tptacek »

tough wrote: post #173
tptacek wrote: post #165

Earlier quoted context omitted.

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

You’re optimizing for one class of customer by denying another class a choice they explicitly want.

That's true, in the sense that it is true of every coherent business. What would not be a true statement is that we somehow profit from the discomfort of the "disfavored" cohort of customers here. If we could serve them reasonably without making terrible compromises for everybody else, we would do so, and we would profit from that.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#203

Post by tptacek »

ilaksh wrote: post #189
tptacek wrote: post #165

Earlier quoted context omitted.

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."

A learning from the past 6 years: warnings do absolutely nothing. If your answer to a problem is a warning label, you have no answer for the problem.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#204

Post by coppsilgold »

rendaw wrote: post #194
coppsilgold wrote: post #77

Earlier quoted context omitted.

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?

Properly configured (including strict seccomp) bwrap on its own will be sufficient 99% of the time. But ultimately you are at the mercy of the enormous kernel attack surface and the 0days that result from it.

If you do anything valuable and are compromised it may get brought to the attention of whoever organized the automated attack (ex. AI agent doing interesting proprietary work that installed something it shouldn't have, chat logs got uploaded and analyzed) and they will then sell you to someone with the 0days to extract more value from you. Assuming you didn't screw up and leave a back door open somewhere of course.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#207

Post by tough »

tptacek wrote: post #202
tough wrote: post #173

Earlier quoted context omitted.

You’re optimizing for one class of customer by denying another class a choice they explicitly want.

That's true, in the sense that it is true of every coherent business. What would not be a true statement is that we somehow profit from the discomfort of the "disfavored" cohort of customers here. If we could serve them reasonably without making terrible compromises for everybody else, we would do so, and we would profit from that.

I guess business is all about making the right compromises

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#208

Post by ilaksh »

tptacek wrote: post #202
tough wrote: post #173

Earlier quoted context omitted.

You’re optimizing for one class of customer by denying another class a choice they explicitly want.

That's true, in the sense that it is true of every coherent business. What would not be a true statement is that we somehow profit from the discomfort of the "disfavored" cohort of customers here. If we could serve them reasonably without making terrible compromises for everybody else, we would do so, and we would profit from that.

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.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#209

Post by ranger_danger »

I wish docker and friends could integrate microvm support (and not just for AI agents), to the point where I can "docker pull ubuntu" (or whatever other distro) to run them just as easily as we're used to.

The biggest issue preventing me from using microvm more is the lack of easy access to kernel/rootfs combinations of different distros.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#210

Post by tptacek »

ilaksh wrote: post #208
tptacek wrote: post #202

Earlier quoted context omitted.

That's true, in the sense that it is true of every coherent business. What would not be a true statement is that we somehow profit from the discomfort of the "disfavored" cohort of customers here. If we could serve them reasonably without making terrible compromises for everybody else, we would do so, and we would profit from that.

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.
Post reply on HN