Live data from Hacker News

Firecracker: Secure and fast microVMs for serverless computing

firecracker-microvm.github.io

31–40 of 107 posts

Re: Firecracker: Secure and fast microVMs for serverless computing

#31
post #30
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?

even questions like this got downvoted, time to leave HN for reddit for good, more and more pathetic here these days indeed.

It wasn't a terrible question, but your question is answered in the first couple sentences of the main article. I do notice a trend where comments that suggest that the commenter didn't read the article get downvoted. I think in general I'm fine with that, except it's sometimes hard to notice when someone has read it, but just didn't understand.

Re: Firecracker: Secure and fast microVMs for serverless computing

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

> disk read/writes are not good enough

This is an odd thing to say; surely that depends on the application? I doubt most FaaS users are disk IO-bound?

Re: Firecracker: Secure and fast microVMs for serverless computing

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

Re: Firecracker: Secure and fast microVMs for serverless computing

#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 because the host simply is not aware what you exactly run inside.

The solution is to have an agreed connectivity standard both on the guest and the host. The guest can provide SSH server, telnet server serial terminal, irc bot or some other kind of control capability. Then of course host needs a tooling too, e.g. SSH client.

Re: Firecracker: Secure and fast microVMs for serverless computing

#40
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 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, then it would not be isolated from the host, this seems almost tautological.

You can arrange for process execution another way than SSH, Docker, or Kube API but regardless of what shape it takes, it will still be an entry point in similar fashion to any of these, as the MicroVM or VM runs its own kernel on KVM and does not talk to the host in this way. Perhaps someone knows more about KVM and can clue me in further if there is more here than meets the eye and maybe what you said is possible.

If you don't need the isolation of a proper VM and were only looking for a roughly VM-shaped system that you CAN "kernel exec" or use nsenter to get processes into, you should look at Footloose[1].

I'm suggesting what you are looking for is actually a container that looks more like a VM or bare-metal machine from the perspective of inits and with the vantage point of the processes running inside.

By default, Footloose nodes are running SSH and SystemD, may appear to work similarly to Ignite VMs, but they are Docker containers that may or may not run privileged mode.

So, if it suits you, then you could start up Footloose "VMs" as I still call them, strip SSH from them, then nsenter or Docker exec into them as you desire, or run Kubernetes on them and use the Kube API including exec.

That is actually a lead in to the next project, known as Firekube[2], kind of a mashup of all these technologies plus one more (wksctl[3]). Firekube integrates both Ignite and Firecracker as well, so you can use it similarly on Linux, (where KVM support is available for Ignite), or MacOS, where Footloose runs container-VMs instead, both behave alike; this suite of projects all put together is a very slick and well integrated package IMHO. It is probably comparable in functionality to Minikube, but with GitOps baked right in.

Disclosure: I am not working for Weaveworks, but we are good friends.

[1]: https://github.com/weaveworks/footloose

[2]: https://github.com/weaveworks/wks-quickstart-firekube/

[3]: https://github.com/weaveworks/wksctl

Post reply on HN