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

71–80 of 114 posts

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#71

Post by sudhirj »

zackbloom wrote: post #62
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!

Heh. Truthfully, what I'm most excited about right now is being able to start a worker in less time than it takes to make an internet request. When you can do that you get magical autoscaling and it becomes just as cheap to run it in hundreds of places as one. As long has you have to invest ~100ms of CPU to get one of these VMs running I'm not sure it will have quite the same economics.

Yeah, jokes aside I simply don’t think it makes sense to run full processes on the edge. Not yet, anyway.

Script isolates makes a lot of sense with current hardware limitations, but full processes at the edge are coming sooner or later.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#72

Post by coder543 »

Aissen wrote: post #41
talawahtech wrote: post #12

This is huge! It basically removes the VM as the security boundary for something like Fargate [1]. This should lead to a significant reduction in pricing since Fargate will no longer need to over provision in the background because VMs were being used even for tiny Fargate launch types. It should hopefully eliminate the cost disparity between using Fargate vs running your own instances. Should also mean much faster s…

Indeed, this seems very similar to kata+runv+kvmtool(lkvm). I'm curious why they don't provide a comparison. Here's what I gathered: - it seems to boot faster (how ?) - it does not provide a pluggable container runtime (yet) - a single tool/binary does both the VMM and the API server, in a single language. Can anyone else chime in ?

> I'm curious why they don't provide a comparison

They do, if you read the FAQs: https://firecracker-microvm.github.io/#faq

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#73

Post by sudhirj »

Twirrim wrote: post #66
sudhirj wrote: post #3

What this is allows, and I'm hoping a full fledged service will be announced on Thursday or Friday, is running containers as Lambdas. i.e. if you application starts fast enough, you can just set a container to start and run as a request comes in. It can also shut down when it's done running. This allows things like per second billing for container runs, serverless containers (there's no container running 24/7, only w…

Why run a container? What value does that abstraction provide here? To my mind this completely negates any value proposition of the container. The only thing missing, at face value, is something as straightforward as the Dockerfile for building base images. I imagine that shouldn't be hard using things like guestfish etc in guestfstools.

Want to run Ruby on Rails on Lambda, with no changes from the servers I run on my laptop. Or maybe I want to run Crystal. Or maybe I’m writing my own language. Doesn’t really matter.

Lambda works great as a deployment and execution model. This allows anything to run on Lambda, not just specially prepared runtimes.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#74

Post by carimura »

kraemate wrote: post #65

Clear containers (now called kata containers) did this more than three years ago, with similar performance numbers (sub 200 ms boot times). It is frustrating, but not surprising, to see the same regurgitated solution receive this much excitement. The firecracker documentation also does not mention the similarity with prior work, oh well. [Not affiliated with Intel in any way---just a long-time proponent of the clear…

yep. happens all the time. people flock to brand association because it "must be good". halo effect or some other cognitive bias in action.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#75

Post by Aissen »

coder543 wrote: post #72
Aissen wrote: post #41

Earlier quoted context omitted.

Indeed, this seems very similar to kata+runv+kvmtool(lkvm). I'm curious why they don't provide a comparison. Here's what I gathered: - it seems to boot faster (how ?) - it does not provide a pluggable container runtime (yet) - a single tool/binary does both the VMM and the API server, in a single language. Can anyone else chime in ?

> I'm curious why they don't provide a comparison They do, if you read the FAQs: https://firecracker-microvm.github.io/#faq

I did, and it does not answer my question, because they only address the runv+qemu usecase, not the runv+kvmtool one:

Kata Containers is an OCI-compliant container runtime that executes containers within QEMU based virtual machines

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#76

Post by Twirrim »

nine_k wrote: post #70
Twirrim wrote: post #66

Earlier quoted context omitted.

Why run a container? What value does that abstraction provide here? To my mind this completely negates any value proposition of the container. The only thing missing, at face value, is something as straightforward as the Dockerfile for building base images. I imagine that shouldn't be hard using things like guestfish etc in guestfstools.

Your container = your environment. When your container is not running (say, 99% of time), other customers' containers are running. No need to ever boot the kernel, etc. One might say that an unikernel has advantages over it. But it also has a higher barrier to entry.

It's a KVM microinstance. Your image = your environment. Same as with a container.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#77

Post by Twirrim »

sudhirj wrote: post #73
Twirrim wrote: post #66

Earlier quoted context omitted.

Why run a container? What value does that abstraction provide here? To my mind this completely negates any value proposition of the container. The only thing missing, at face value, is something as straightforward as the Dockerfile for building base images. I imagine that shouldn't be hard using things like guestfish etc in guestfstools.

Want to run Ruby on Rails on Lambda, with no changes from the servers I run on my laptop. Or maybe I want to run Crystal. Or maybe I’m writing my own language. Doesn’t really matter. Lambda works great as a deployment and execution model. This allows anything to run on Lambda, not just specially prepared runtimes.

It's a VM, right? So whatever you put in the base image will be available, just like with a container. It's just fast to provision and small.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#78

Post by mark212 »

still seems much slower than the model used by Cloudflare for what they call "workers."[1] A recent blog post a few weeks back was the subject of considerable discussion here[2], and it seems to me to be doing much the same thing as Firecracker, but still faster because there's less overhead. But maybe I'm missing something.

[1] https://blog.cloudflare.com/cloud-computing-without-containe...

[2] https://news.ycombinator.com/item?id=18415708

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#80

Post by tlrobinson »

mark212 wrote: post #78

still seems much slower than the model used by Cloudflare for what they call "workers."[1] A recent blog post a few weeks back was the subject of considerable discussion here[2], and it seems to me to be doing much the same thing as Firecracker, but still faster because there's less overhead. But maybe I'm missing something. [1] https://blog.cloudflare.com/cloud-computing-without-containe... [2] https://news.ycombina…

> But maybe I'm missing something.

From the "Disadvantages" section of your first link:

"No technology is magical, every transition comes with disadvantages. An Isolate-based system can’t run arbitrary compiled code. Process-level isolation allows your Lambda to spin up any binary it might need. In an Isolate universe you have to either write your code in Javascript (we use a lot of TypeScript), or a language which targets WebAssembly like Go or Rust."

"If you can’t recompile your processes, you can’t run them in an Isolate. This might mean Isolate-based Serverless is only for newer, more modern, applications in the immediate future. It also might mean legacy applications get only their most latency-sensitive components moved into an Isolate initially. The community may also find new and better ways to transpile existing applications into WebAssembly, rendering the issue moot."

Post reply on HN