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

61–70 of 114 posts

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#61

Post by Aissen »

justincormack wrote: post #57
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 ?

From memory the original version of Intel Clear Containers had its own kvm based vmm but they moved back to qemu (or a more minimal patched version they maintain). They are working on containerd support so should be similar to Kata soon.

That's what I thought, too, but re-reading the articles, they were using a patched kvmtool: https://lwn.net/Articles/644675/

So this is exactly what runv's lkvm backend is doing (except kvmtool isn't patched anymore). And Intel Clear Containers do not exist anymore(many broken links on clear linux's website subsist, though), since they moved to Kata as well:

https://01.org/blogs/2017/kata-containers-next-evolution-of-...

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#62

Post by zackbloom »

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.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#63

Post by sciurus »

sudhirj wrote: post #16
discodave wrote: post #8

Earlier quoted context omitted.

> containers as Lambdas. How similar is AWS Fargate to what you're describing?

I need to run 1+ Fargate containers 24/7, which is useless and wasteful. With Fargate-Lambda crossover I wouldn't be running anything 24/7, and it would be a lot less resource intensive than one Lambda-Container per request as well. Google's App Engine gets / got this right when they first launched, but to make it work they had to demand apps be written for their sandbox (like AWS Lambda), because of which the model…

I think with the App Engine Standard generation 2 runtimes you don't have to write to their sandbox anymore. It still has to be one of their supported languages though, instead of any arbitrary server.

https://cloud.google.com/blog/products/gcp/introducing-app-e...

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#64

Post by sciurus »

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.

Google recently open-sourced Gvisor, which although implemented differently solves a similar problem. Possibly Amazon wants to encourage other vendors to build integrations with Firecracker rather than Gvisor.

https://cloud.google.com/blog/products/gcp/open-sourcing-gvi...

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#65

Post by kraemate »

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 containers approach.]

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#66

Post by Twirrim »

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.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#67

Post by steveklabnik »

polskibus wrote: post #38

Does it support Windows?

https://firecracker-microvm.github.io/ says

> What operating systems are supported by Firecracker?

>

> Firecracker supports Linux host and guest operating systems with kernel versions 4.14 and above. The long-term support plan is still under discussion. A leading option is to support Firecracker for the last two Linux stable branch releases.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#68

Post by cleansy »

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…

After Amazon released its implementation the whole eco system profits, as it creates diversity and buzz around that topic. I think it's great to have (open source) alternatives, especially with the marketing weight of amazons solution entering "playing field". Also: is it clear that kata was first? Three years doesn't sound like they've been miles ahead.

[Not affiliated with either side]

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#69

Post by talawahtech »

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…

The FAQs on the Firecracker website[1] specifically address the difference between Firecracker and Kata Containers. The main thrust being that they have decided not to use QEMU and have instead chosen a much more minimal "cloud-native" oriented approach that deliberately abandons certain features in order to gain greater security, efficiency and agility going forward. They also decided to implement it in Rust.

Based on the the responses I have seen from non-Amazon employees with experience in this space[2][3][4], it looks like their approach is solid.

It should also be noted that one of the main architects of Firecracker was formerly the project lead for QEMU[5][6]

1.https://firecracker-microvm.github.io/#faq

2.https://twitter.com/bcantrill/status/1067326416121868288

3.https://twitter.com/jessfraz/status/1067286831287418881

4.https://twitter.com/kelseyhightower/status/10672947809488322...

5.https://twitter.com/jessfraz/status/1067282499938721792

6.https://twitter.com/anliguori/status/1067293131366785024

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#70

Post by nine_k »

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.

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.

Post reply on HN