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

Firecracker – Lightweight Virtualization for Serverless Computing

aws.amazon.com

Post reply on HN
Print view View original

31–40 of 114 posts

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#31

Post by sudhirj »

Tehnix wrote: post #30
sudhirj wrote: post #28

Earlier quoted context omitted.

That's odd. Are you running the interpreter runtimes (NodeJS/PHP), compiled binaries (Go) or VMs like Java?

We are using Node.js. From what I’ve seen online, Python should be the fastest though. Edit: wanted to add, that from what I’ve gathered from people testing online, bundle size didn’t really matter, but perhaps someone else has some information that points to the contrary?

Bundle size is rarely equivalent to size of initial executable code. i.e. I can have a giant photo of my dog in the bundle but it won't necessarily affect the start up time of the node index.js. I think there is some kind of effect in that the bundle must be downloaded to the Lambda container server from S3, but that seems pretty fast, and it's likely cached there for a while.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#33

Post by sudhirj »

sudhirj wrote: post #32

@zackbloom, @kentonv hint hint. Isn't this roughly the same memory footprint as a Worker? CONTAINERS ON ALL THE CLOUDFLARE THINGS!

If you can implement it by tomorrow afternoon before the Andy Jassy keynote you might be able to steal some thunder.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#34

Post by solatic »

ec109685 wrote: post #26
solatic wrote: post #22

"Process Jail – The Firecracker process is jailed using cgroups and seccomp BPF, and has access to a small, tightly controlled list of system calls." So basically, a gVisor alternative?

gVisor doesn't use KVM: "Machine-level virtualization, such as KVM and Xen, exposes virtualized hardware to a guest kernel via a Virtual Machine Monitor (VMM). This virtualized hardware is generally enlightened (paravirtualized) and additional mechanisms can be used to improve the visibility between the guest and host (e.g. balloon drivers, paravirtualized spinlocks). Running containers in distinct virtual machines c…

Yeah but one of the main ways in which gVisor provides security is by intercepting system calls and strictly limiting which calls can be made. Firecracker may use KVM instead of running entirely in usermode, but as far as most of us are concerned, that's an implementation detail. The pertinent question is whether the price of security is limiting the possible system calls, which means that Firecracker won't be able to run arbitrary containers, just as gVisor doesn't guarantee that it can run arbitrary code (which may require filtered system calls).

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#35

Post by ec109685 »

solatic wrote: post #34
ec109685 wrote: post #26

Earlier quoted context omitted.

gVisor doesn't use KVM: "Machine-level virtualization, such as KVM and Xen, exposes virtualized hardware to a guest kernel via a Virtual Machine Monitor (VMM). This virtualized hardware is generally enlightened (paravirtualized) and additional mechanisms can be used to improve the visibility between the guest and host (e.g. balloon drivers, paravirtualized spinlocks). Running containers in distinct virtual machines c…

Yeah but one of the main ways in which gVisor provides security is by intercepting system calls and strictly limiting which calls can be made. Firecracker may use KVM instead of running entirely in usermode, but as far as most of us are concerned, that's an implementation detail. The pertinent question is whether the price of security is limiting the possible system calls, which means that Firecracker won't be able t…

That’s not true. Your guest application has access to all Linux system calls in the guest VM.

You can see here the security model: https://github.com/firecracker-microvm/firecracker/blob/mast...

The firecracker process itself is limited in the system calls it can make, but kvm allows the guest Linux process the ability to expose a full set of system calls to end user applications.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#36

Post by dm3 »

tlrobinson wrote: post #18

This looks great, I’m just wondering what Amazon’s motivation for open sourcing it is. It seems like some pretty critical secret sauce for making services like Lambda and Fargate both secure and efficient.

Pushing the adoption of "serverless" - benefits Amazon ultimately as it's the largest provider.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#37

Post by ec109685 »

sudhirj wrote: post #32

@zackbloom, @kentonv hint hint. Isn't this roughly the same memory footprint as a Worker? CONTAINERS ON ALL THE CLOUDFLARE THINGS!

You still have a full Linux kernel running inside the vm though?l with Firecracker versus essentially a fiber with cloudflare.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#40

Post by cddotdotslash »

Tehnix wrote: post #23
sudhirj wrote: post #17

Earlier quoted context omitted.

Most code start time problems on Lambda I've seen are VPC related - public network Lambdas start in milliseconds, with the main lag being the userspace code startup time. Starting a Lambda inside a VPC involves attaching a high security network adapter individually to each running process, which is likely what takes so long. I assume AWS is working on that, though, they've claimed some speedups unofficially. If your…

The VPC startup times are insane, so we quickly move our lambdas out of that, accepting the trade off. Our normal cold starts are in the 1-2 second range, and the app initialization comes after. Too high for an API facing users :/

We got around this with a bit of a hack - use a CloudWatch event to trigger a dummy invocation of your function every five minutes. This keeps the container "hot" and reduces the start time (and is negligible cost-wise). This won't fix the cold starts when the function scales up, but it does reduce latency for 99% of our API requests.
Post reply on HN