Hacker News Reader

Comment by doublerabbit | Hacker News Reader

I'm not wanting to sound snoody. What use-cases do firecracker instances and the likes chime?

I use FreeBSD for everything from my colocated servers, to my own PC. By no means am I developer; seasoned Unix Admin at best. Bare-metal forever but welcome to the future. Especially anything that contributes to the OS.

However I hear buzz words like Lambda and Firecracker and really have no idea where the usage is. I get docker, containers, barely understand k8s but why do you need to spin up a VM only to tear it down compared to where you could just spin up a VM and use it when you really need to. Always there, always when.

Is it purely a cloud experience, cost saving exercise?

View on HN

Instances of an application are created as part of the request/response lifecycle.

Allows you to build a compute plane where any node in the plane can service the traffic for any application.

Any one application can dynamically grow to consume the available free compute of the plane as needed in response to changes in traffic patterns.

Applications use no resources when they aren't handling traffic.

Growing the capacity of the compute plane means bringing more nodes online.

Can't come up with a use case for this beyond managing many large-scale deployments. If you aren't working "at scale" this is something that would sit below a vendor boundary for you.

... "snooty"?

https://www.merriam-webster.com/dictionary/snooty

snotty

The main use case if for seldom used APIs. If I run a service where the API isn't used often, but I need it quick when it is, Lambdas or something like it are perfect.

As it turns out, a lot of APIs for phone apps fit this category. You don't want a machine sitting around idle 99% of the time to answer those API calls.

This sounds like a hack around a programming problem that needs to be fixed.

I don't even understand what that means. What programming problem?

If you rarely need an API but set something up like this just to rarely use it, it seems one needs to write their own code for this functionality and not go through hoops to run someone else's. That just sounds so bizarre.

Not someone else's API, your own. You make an app. It needs an API that you create (perhaps to sync up scores or something). You don't want to run a machine full time just to accept one score update a day.

Same issue. If one needs to spin this up just for a one-off usage, there's something wrong that needs to be fixed.

I’m not sure how to explain this so you’ll understand. It’s basically how all phone apps are written. It’s a common pattern.

If you made a iPhone game and wanted the high scores to sync to a global scoreboard when the game is over, how would you build that?

What if you only expected 10 players a day?

Dumb question, then why not stick that API on a machine/service that does need to be used 99% of time.

Because the API also needs some separation. The same reason you would want your services isolated in VMs instead of all running in one bare metal.

> just spin up a VM and use it when you really need to. Always there, always when

and always charging you :)

Just about every single company can benefit from scaling as traffic is never consistent 24/7. Most don't bother as the effort outweighs the savings, but the potential is there. Things like lambda and firecracker make it much easier.

It's partly a cost saving exercise, but also: running "chroot /var/empty /some/shitty/code" or putting "chroot /var/empty /some/shitty/code" in inetd.conf is useful. (On today's super-fast machines,) Firecracker starts fast enough to support such interactive uses, while giving you the extra security of a VM (i.e. greatly restricts what parts of the kernel and/or localhost the shitty code can talk to).

> why do you need to spin up a VM only to tear it down compared to where you could just spin up a VM and use it when you really need to. Always there, always when

Firecracker has a much amaller overhead compared to regular VMs - which makes the (time and compute) costs of spinning up new VMs really low. This can be an advantage, depending on how chunky your workloads are - the less chunky they are - the more they can take advantage of finer-grained scaling.

IoT devices can execute short lived actions by calling remote Functions. The provider wants complete isolation and wipes these micro VMs after every few seconds and let's the user pay for use. The response from these can be anything, voice, data or API responses.

FaaS, function as a service. Depending on how software is packaged and the expectations the richness a VM, like Firecraker, provides may be useful. Many of these tradeoffs are for velocity, I can run X easily on Y.

> However I hear buzz words like Lambda and Firecracker and and really have no idea where the usage is.

Sometimes you just want to slap some lines pf code together and run them from time to time, and don’t need a whole server (physical or virtual) for that.

Sometimes you have no idea if you’ll have to run a piece of code 100 times a day or 10’000’000 times a day.

Sometimes you don’t feel like paying a whole month for and maintaining a whole instance for a cronjob that lasts 20 seconds, and maybe it runs once a week.

Instead of (or alongside) a CDN, you can deploy mini services around the world at the "edge"

Reply on news.ycombinator.com