Live data from Hacker News

Firecracker: Secure and fast microVMs for serverless computing

firecracker-microvm.github.io

41–50 of 107 posts

Re: Firecracker: Secure and fast microVMs for serverless computing

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

See https://github.com/firecracker-microvm/firecracker-container...

Re: Firecracker: Secure and fast microVMs for serverless computing

#44
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

I am not sure if this is true. Well, you are not really making a statement that could be easily interpreted. Virtio is specifically created to address performance issues with virtualization. Are you unhappy about the implementation quality or you generally believe that para-virtualization is not the way to go about improving virtualization overhead?

One prime example when with virtio it was possible to get native performance _after_ minimum configuration tuning:

https://serverfault.com/questions/407842/incredibly-low-kvm-...

More details on virtio:

https://vmsplice.net/~stefan/virtio-devconf-2014.pdf

Re: Firecracker: Secure and fast microVMs for serverless computing

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

I dabbled with an idea similar to Fly.io's Heroku supercharging functionality (Turboku?).

One issue I encountered is that the app in question does not benefit from full-page caching. Even if we deployed our app through Fly.io, we'd still have our databases hosted somewhere else. How does Fly.io solve this, or how could we solve this?

When I dabbled with this idea, I thought about deploying DB read-only replicas around the world. There would be some replication lag, but for the app in question, that would not be problematic. Writes would still be affected by the added latency, but this would not be that problematic as the fast majority of the queries are reads.

Re: Firecracker: Secure and fast microVMs for serverless computing

#46
post #39
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…

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

Re: Firecracker: Secure and fast microVMs for serverless computing

#47
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 need a better logging infrastructure.

Then again, if you are referring to how to initially install software, wouldn’t you usually just create an image for it to run?

Re: Firecracker: Secure and fast microVMs for serverless computing

#48

Earlier quoted context omitted.

Why does FaaS (that's what Lambda is, right?) need more full blown virtualization? I thought you could maybe get away with even lighter separation than Docker?

Docker isn’t really designed to be a security boundary, so if you’re colocating containers from different customers (e.g. in Fargate), you need to separate them with a real security boundary like a VM. The same thing is true for lambdas: a lambda is just an archive and the code in the archive needs to run somewhere where one customer cannot intercept another customer’s data.

To add on, AWS has never run Lambdas for different accounts on the same VM. Before Firecracker, they would run multiple Lambdas for the same account on the same VM. Now with Firecracker, they can run each lambda in its own VM.
Post reply on HN