Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firecracker: Secure and fast microVMs for serverless computing

firecracker-microvm.github.io

Post reply on HN
Print view View original

71–80 of 107 posts

Re: Firecracker: Secure and fast microVMs for serverless computing

#71

Post by scarface74 »

xorcist wrote: post #70
scarface74 wrote: post #47

Earlier quoted context omitted.

I’ve personally never needed to ssh into my “cattle” even when I could (EC2 instances in an autoscaling group, Docker containers run with Fargate) and I haven’t missed it when I couldn’t (lambda). For Fargate/Lambda all console output goes to CloudWatch, for EC2 tasks (legacy Windows), we use Serilog with a CloudWatch sink. But more generically, if you have to log into your cattle for troubleshooting, you probably ne…

It's nice to have ptrace once in a while.

The only time I can think of where copious logging wasn’t good enough for “remote debugging” is when I was writing C code trying to figure out why I was killing the call stack or overwriting memory.

Re: Firecracker: Secure and fast microVMs for serverless computing

#73

Post by ec109685 »

scarface74 wrote: post #55
mrkurt wrote: post #53

Earlier quoted context omitted.

Snapshot / suspend isn't doable yet, but it sure would be nice. We've booted some apps in Firecracker in <20ms, so if you build the app properly you can absolutely do a new VM per request or TCP connection even.

Yeah, this is what AWS does....

No it doesn't. It pre-inits the Firecracker VM's before the first request: https://www.usenix.org/system/files/nsdi20-paper-agache.pdf

Re: Firecracker: Secure and fast microVMs for serverless computing

#74

Post by scarface74 »

ec109685 wrote: post #73
scarface74 wrote: post #55

Earlier quoted context omitted.

Yeah, this is what AWS does....

No it doesn't. It pre-inits the Firecracker VM's before the first request: https://www.usenix.org/system/files/nsdi20-paper-agache.pdf

I meant the part about one request per VM.

Re: Firecracker: Secure and fast microVMs for serverless computing

#75

Post by hinkley »

detaro wrote: post #51

I'm curious about restarts and snapshotting: would it be feasible to reset a microVM for each incoming request?

Wasn't fastcgi essentially about starting new processes ahead of time and then doling them out as new requests came in? Worked quite well for bursty traffic, and for sustained traffic was about the same. Feels like a similar strategy could be apropos here.

And if I'd read farther down the chain, someone said that Amazon already does this.

Re: Firecracker: Secure and fast microVMs for serverless computing

#77

Post by mrkurt »

nicklarsennz wrote: post #76

Does anyone know if any integration with Kubernetes is on the cards? Something like an operator with CRDs? Or is this intended to be separate, a competitor?

There are a few ways to use k8s + firecracker, weave has one: https://www.weave.works/oss/firekube/

Re: Firecracker: Secure and fast microVMs for serverless computing

#78

Post by ffk »

nicklarsennz wrote: post #76

Does anyone know if any integration with Kubernetes is on the cards? Something like an operator with CRDs? Or is this intended to be separate, a competitor?

This is more comparable to runc.

Firecracker can be used in kubernetes through containerd+kata containers integration. (Containerd from docker is a key tech behind both docker and K8s, kata containers from Intel enables containerd to run vms)

I don't think the experience is great yet, but it's on the way.

Re: Firecracker: Secure and fast microVMs for serverless computing

#79

Post by eatmyshorts »

nicklarsennz wrote: post #76

Does anyone know if any integration with Kubernetes is on the cards? Something like an operator with CRDs? Or is this intended to be separate, a competitor?

https://www.weave.works/blog/firekube-fast-and-secure-kubern...

Re: Firecracker: Secure and fast microVMs for serverless computing

#80

Post by ffk »

darren0 wrote: post #38

"Firecracker provides a rate limiter built into every microVM. This enables optimized sharing of network and storage resources, even across thousands of microVMs." Probably the most interesting feature.

This is enabled by disabling anything that depends on pinned kernel memory.

You get a VM with user space networking and a one button keyboard. This allows the kernel too aggressively swap out unused resources and ultimately increase the total concurrency supported.

Post reply on HN