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

61–70 of 107 posts

Re: Firecracker: Secure and fast microVMs for serverless computing

#61

Post by mrkurt »

ignoramous wrote: post #54
mrkurt wrote: post #3

Firecracker is great We use it to run fleets of fast booting vms at https://fly.io . It’s really the best OSS to come out of Amazon.

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 gvisor pretty hard but preferred more traditional virtualization. We didn't look much at other virtualization options, Firecracker was really good from day one.

The docs were pretty good. We ended up having to build a bunch, though, probably just because of the nature of our product. We built a custom init (in Rust), a Docker image to root fs builder, and a nomad task driver (both in Go). The init includes and rpc mechanism so we can communicate with the VM.

Firecracker was pretty easy, building the scaffolding to use it was a little harder, but the vast majority of our time is spent on the dev UX and proxy/routing layer.

Re: Firecracker: Secure and fast microVMs for serverless computing

#62

Post by mrkurt »

sudhirj wrote: post #60
photonios wrote: post #58

Earlier quoted context omitted.

> 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…

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. :)

Re: Firecracker: Secure and fast microVMs for serverless computing

#64

Post by bonzini »

detaro wrote: post #37
m00dy wrote: post #32

I believe it is still using virtio. Therefore, disk read/writes are not good enough compared to other virtualization tech such as qemu

qemu setups often use virtio, afaik virtio was defined by qemu devs, so your statement doesn't really make sense without more details. Also, "not good enough" kind of needs a definition of a workload and what's "good enough" for it.

It's using virtio-mmio which is less efficient than virtio-pci. But I/O was not a focus of Firecracker, for example it doesn't scale very well because it doesn't do concurrent I/O operations.

Re: Firecracker: Secure and fast microVMs for serverless computing

#65

Post by tofflos »

scarface74 wrote: post #47
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…

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 for initial installation.

I use it to figure out what the image and orchestration settings should be. Packaging an application for containers and container orchestration takes me many, many, attempts to get right. Personally I'm unable to divine the correct combination of settings by reading documentation alone so I try something, enter the container, and look at the outcome.

Re: Firecracker: Secure and fast microVMs for serverless computing

#66

Post by mrkurt »

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…

> 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.

We did some measurements, but mostly focusing on the network bits (which you largely solved with CloudFlare): https://fly.io/blog/turboku/

I was surprised at how much faster things seemed on our VMs vs Heroku's Dynos, to be honest. We only compared Standard dynos, but we should be even better price vs performance compared to the performance dynos since we run our own physical servers. A performance-m dyno on Heroku costs about the same as 8 cpus on fly.

It's totally self serving, but if you feel like playing around with the Fly stuff I'd love to know how it compares.

> This is going to be tricky. We weren't able to set up replication from Heroku Postgres databases to hosts outside of Heroku. Another thing to keep in mind that is it might be better to let the app decide what is a read query and what is a write query. We have some parts of the app that we need reading directly from the master, so we let the app handle it. The app receives two database URI's, both pointing to pgbouncer.

This is why I think the in memory caching is such a good option. Usually if I'm building an app, I'll add a caching layer before a DB replica. Write through caching seems to fit my mental processes better. :D

Re: Firecracker: Secure and fast microVMs for serverless computing

#68

Post by nezirus »

mercora wrote: post #59
yebyen wrote: post #40

Earlier quoted context omitted.

> I got the impression that VMs needed an SSH server to be accessible. Is this correct and if so will it be possible to implement something similar to docker exec so that I won't need an SSH server on every VM? If you want the capability to exec processes from the host into the VM, I think either Docker API or Kube API is the thing for that, as I understand it. If you could kernel exec processes directly into a VM, t…

i think using an emulated serial connection or similar driver interface could be part of a solution to this.

You can replace SSH requirement with virtio-vsock (also supported by Qemu)

https://github.com/firecracker-microvm/firecracker/blob/mast...

Re: Firecracker: Secure and fast microVMs for serverless computing

#69

Post by hinkley »

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.

Re: Firecracker: Secure and fast microVMs for serverless computing

#70

Post by xorcist »

scarface74 wrote: post #47
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…

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.
Post reply on HN