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

81–90 of 107 posts

Re: Firecracker: Secure and fast microVMs for serverless computing

#81

Post by ffk »

hinkley wrote: post #69
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.

One of the things you learn about multitasking is that in theory cooperative multitasking is the most efficient, but the least reliable. It’s cheaper (for the human) to use hard and fast rules that trade nasty surprises for vague disappointment. This sounds like a hybrid system. The intermediary is cooperative, the client code is oblivious. I’m curioue to see how this plays out over the long haul.

This runs Amazon lambda, so presumably well enough?

Re: Firecracker: Secure and fast microVMs for serverless computing

#82

Post by wmf »

CameronNemo wrote: post #46
imhoguy wrote: post #39

Earlier quoted context omitted.

Containers are provided by host kernel cgroups and namespaces, therefore the kernel implements attach (exec) operation which is practically running a new proces (e.g. bash) in a cgroup (container). Virtual Machines are provided by software or hardware emulation which run separate guest OS with own kernel. There is no standard way for a host to let you run any process and interact with its stdio inside guest OS becaus…

Are there any real alternatives to SSH and/or sftp? E.g. a mutual TLS authenticated HTTP server...

virtio-vsock

Re: Firecracker: Secure and fast microVMs for serverless computing

#83

Post by manigandham »

photonios wrote: post #58
mrkurt wrote: post #52

Earlier quoted context omitted.

You've pretty much nailed the problem. The ?good? news though is that Heroku is really slow, so just running Firecracker VMs on real hardware, doing edge TLS, and adding http2 + brotli is a huge win. When people use https://fly.io/heroku , we launch VMs in the same region their Heroku app is in so there's no latency hit to the DB. Weirdly, latency between a Fly app a DB on AWS in the same region is sometimes even bet…

> The ?good? news though is that Heroku is really slow Did you do any measurements and if so, on which dyno types? We found that using Performance-M dynos' gives us a rather large performance boost. Performance-m dyno's are also more stable because they run on dedicatd hardware. They're expensive, but we don't run any apps in production without it. One thing that worked really well for us is to just put Cloudflare or…

Cloudflare and Fly are both reverse-proxy CDN services that handle caching and TLS at the edge. They also both support running arbitrary logic at the edge. Cloudflare has Workers (javascript web workers API) with their custom KV key/value persistent data layer. Fly started similar but now supports containers running anything and has a Redis non-persistent cache layer.

If all you're doing is caching some endpoints and TLS termination then either will work. Cloudflare has a bigger network with robust security capabilities, Fly has more flexibility in application logic you can run.

Data has gravity and having a globally distributed database layer is something companies have spent millions on. Usually the solution is to cache as much as possible in each region first, then look at doing database replicas, and eventually multi-regional active/active database scale-outs.

Re: Firecracker: Secure and fast microVMs for serverless computing

#84

Post by sudhirj »

mrkurt wrote: post #62
sudhirj wrote: post #60

Earlier quoted context omitted.

I tried adding Cloudfront in front of an app hosted on Heroku with page caching off (Vary by Cookie) and it increased latency to 3X, never could figure out why. Would like to do it but seems like way too much of a trade off.

Shameless plug, https://fly.io/heroku gives you a lot of the benefit of Cloudfront without adding a layer. It's like running Heroku with a modern router. --edit-- I confused Cloudfront and CloudFlare yet again. :)

Yeah, I’m gonna try this out. I’m writing a book authoring platform and I want to let people give access to their books on their own domains. Is there an API to add custom domains with LE certs to my app? And is there a limit on how many domains I can add?

Re: Firecracker: Secure and fast microVMs for serverless computing

#85

Post by mrkurt »

sudhirj wrote: post #84
mrkurt wrote: post #62

Earlier quoted context omitted.

Shameless plug, https://fly.io/heroku gives you a lot of the benefit of Cloudfront without adding a layer. It's like running Heroku with a modern router. --edit-- I confused Cloudfront and CloudFlare yet again. :)

Yeah, I’m gonna try this out. I’m writing a book authoring platform and I want to let people give access to their books on their own domains. Is there an API to add custom domains with LE certs to my app? And is there a limit on how many domains I can add?

There is indeed a certificate API! We’re putting up a guide for it this week, I can send you the draft if you’d like. The CLI commands for managing certs are here: https://fly.io/docs/flyctl/certs/

There’s no limit to domains.

Re: Firecracker: Secure and fast microVMs for serverless computing

#86

Post by gavinray »

mrkurt wrote: post #61
ignoramous wrote: post #54

Earlier quoted context omitted.

Hi Kurt, What are usual cold-start times you see with firecracker? What other VMMs or Unikernels did you consider before settling on firecracker? Was the firecracker documentation good enough or did you have to go digging through emails or code to figure out certain things? What was the hardest part of using firecracker in production? Thanks.

Hello again! Cold starts depend a lot on what people actually deploy. They're really fast for an optimized Go binary, really slow for most Node apps. We were playing with Deno + OSv just today and got an app to boot and accept an HTTP request in about 20ms. That assumes you have the root fs all built and ready to go, though, pulling down images and prepping everything is a bit of a bottleneck for that. We looked at g…

Your tech stack is really fantastic and cutting-edge.

Core product in Rust, Firecracker Micro-VMs, Nomad instead of k8s (never used it myself but see the strong value in it and think it makes sense + deserves more attention), and experimentation with Deno (huge fan).

I wish I could clone myself and do some work for you guys just to soak up that knowledge.

Re: Firecracker: Secure and fast microVMs for serverless computing

#88

Post by haberman »

bennyz wrote: post #13
ausjke wrote: post #10

docker is used for microservices, is firecraker designed for serverless applications? what's the key difference between firecracker and docker? are these two overlapped?

Amazon uses it mainly for Fargate and Lambda (from what I've read). Docker is a container technology (shared kernel), while Firecracker is an actual VM manager so it provides better isolation. It is more comparable with QEMU.

I would love to see a high level overview and compare/contrast between different container and virtualization technologies out there. For those if us who have a good understanding of operating systems and hardware, but haven't been keeping up with the plethora of new technologies that are out there.

From what I understand, even QEMU can work in different modes, either emulating hardware or a system call interface. So I'm not sure which of those modes you are referring to.

Re: Firecracker: Secure and fast microVMs for serverless computing

#89

Post by Demiurge »

imhoguy wrote: post #39
tofflos wrote: post #12

I played with Weave Ignite the other day which is a Docker-like CLI for Firecracker. Sure there were some rough edges but the overall experience was pretty good. If you are familiar with the Docker CLI you will be able to get some virtual machines up and running very quickly. Two questions in case someone from Weave tunes into the discussion: I got the impression that VMs needed an SSH server to be accessible. Is thi…

Containers are provided by host kernel cgroups and namespaces, therefore the kernel implements attach (exec) operation which is practically running a new proces (e.g. bash) in a cgroup (container). Virtual Machines are provided by software or hardware emulation which run separate guest OS with own kernel. There is no standard way for a host to let you run any process and interact with its stdio inside guest OS becaus…

Why not use a virtual terminal? That seems like a pretty standard machine interface to use if the machine is virtualized.
Post reply on HN