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

141–150 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#141

Post by tptacek »

anamexis wrote: post #137
tptacek wrote: post #118

Earlier quoted context omitted.

To a first approximation everything in this space has dynamic pricing. If it's not priced dynamically, you're presumably paying a premium either on a commit or in gym pricing.

I don't know what the right term is, but maybe "deterministic" pricing (this is not the right term, but maybe closer). That is, I'm not going to know how much a sprite cost until I see the bill (or look up the live usage report), whereas if I spin up a Fly Machine, I know exactly how much I'm going to pay per unit of time. (Both make sense for their respective use cases.)

Ah, that makes sense. Yeah, that's a technical limitation! I'm sure we'll work through it at some point this year, but it's a consequence of the fact that for most people, most of their Sprites are dormant most of the time; it's how you comfortably get to having 20-30 Sprites (making a new one any time you do something new) for every user.

It's a good callout, a genuine difference between Sprites and Fly Machines. Believe it or not, it's intended to make Sprites cheaper than Machines.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#142

Post by eperot »

coppsilgold wrote: post #135
eperot wrote: post #134

Earlier quoted context omitted.

Thanks. We're working on rootless network setup to make `runsc do --rootless` work with networking enabled when `passt` is installed right now. See issue #13337 (yes that's a cool issue number) which should unblock this. The tty issue is known, should be fixed soon too, though contributions welcome as it sounds like it should be simple fix and we love more contributions :) FWIW, X11 apps work well, I have a personal…

That's good to hear! Hopefully the passt approach you are pursuing will include the ability to use an existing passt socket and not just launch one for you. Wayland is tricky because there are memory buffers being shared between the compositor and the client. crosvm (also by google) adopted 2 custom solutions to it of which one got merged into mainline. Achieving audio passthrough is trivial as it's just a unix socke…

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 milliseconds' worth of samples left in the ringbuffer), in order to achieve actually-gapless playback.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#144

Post by ilaksh »

tptacek wrote: post #116
ilaksh wrote: post #95

Earlier quoted context omitted.

I specifically complained to a fly.io staff on here about their "gotcha, b*tch" usage based pricing which they basically copied from AWS, and they stood by it and other people here backed them up. No one is giving me a pile of free money, so I can't risk that kind of thing.

Exactly what did we copy from AWS here? You could get a long way in our decisionmaking process generally by just consciously avoiding what AWS does.

The short version is it seems like a big "gotcha" that there is no way to limit bandwidth or spending on that or other resources ahead of time, and that might be a deliberate business model that is more aimed at well-funded startups or large companies that are monitoring costs much less closely than an individual or small business.

It's not necessarily too hard to just not dynamically spawn a bunch of machines, but the bandwidth one is going to sneak up on people.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#145

Post by coppsilgold »

eperot wrote: post #142
coppsilgold wrote: post #135

Earlier quoted context omitted.

That's good to hear! Hopefully the passt approach you are pursuing will include the ability to use an existing passt socket and not just launch one for you. Wayland is tricky because there are memory buffers being shared between the compositor and the client. crosvm (also by google) adopted 2 custom solutions to it of which one got merged into mainline. Achieving audio passthrough is trivial as it's just a unix socke…

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.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#146

Post by tptacek »

ilaksh wrote: post #144
tptacek wrote: post #116

Earlier quoted context omitted.

Exactly what did we copy from AWS here? You could get a long way in our decisionmaking process generally by just consciously avoiding what AWS does.

The short version is it seems like a big "gotcha" that there is no way to limit bandwidth or spending on that or other resources ahead of time, and that might be a deliberate business model that is more aimed at well-funded startups or large companies that are monitoring costs much less closely than an individual or small business. It's not necessarily too hard to just not dynamically spawn a bunch of machines, but t…

Lots of people want limits. They might make sense for something like Sprites, where the end-users are often (but not always) individual developers. They're terrible for hosting fixed-function applications. The real gotcha is having limits, because that's the host effectively taking your app down for you.

I know talk is cheap, but I've been in the room for every one of these discussions over the last 6 years at Fly.io, and if we could have come up with a system to make limits workable, we would have done it. Charging for stuff you don't want is bad business, and we make our money from happy, growing customers (the open secret of hosting is that a huge chunk of usage is basically a loss leader search for a much smaller number of ultra-profitable customers).

These pricing models --- at least outside of AWS (I'm not cynical about them but their incentives are different from indies) --- are not meant to fuck you.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#148

Post by rsyring »

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

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#150

Post by indigodaddy »

messh wrote: post #133
crawshaw wrote: post #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.

Checkout https://shellbox.dev for exactly thisnusecase: boxes can be stopped, they are snapshotted to disk then cost just $0.5/month. They wakeup with the same state (memory and processes too) on ssh connections, or web endpoint activity, or just just a cron schedule. When you dont need the box... Just delete it and stop paying. No subscription, managed via ssh

Yeah crawshaw, you should check that out... ;)
Post reply on HN