o problema
Serverless só fecha a conta com densidade. Um servidor moderno tem até 1TB de RAM e uma função Lambda pode pedir 128MB, o que significa até 8.000 funções por máquina — mais ainda com soft allocation. Cada MB gasto em isolamento é MB que não se vende. A AWS mirava overhead de 10% sobre o tamanho da função: 102MB para uma função de 1024MB.
A escolha disponível era ruim dos dois lados. Container no Linux é barato, mas a fronteira de segurança é a superfície de syscalls do kernel compartilhado: seccomp-bpf, cgroups, namespaces. Apertar a lista aumenta a segurança e quebra código — um Ubuntu 15.04 típico precisa de 224 syscalls e 52 ioctls, e Lambda aceita binário Linux arbitrário. Virtualização resolve a compatibilidade, porque o kernel convidado pode ser inteiro e tratado como não confiável, mas o VMM padrão custa caro: QEMU tem mais de 1,4 milhão de linhas, pede até 270 syscalls do host e boota em segundos. O desenho original do Lambda vivia dessa mistura — containers entre funções do mesmo cliente, VMs entre clientes — e sofria com o encaixe de cargas em VMs de tamanho fixo.
a ideia
Manter o KVM e jogar o QEMU fora. O hardware já faz a parte difícil do isolamento; o que sobra é um VMM, e um VMM que só precisa rodar Linux de serverless não precisa de quase nada. Firecracker tem cerca de 50 mil linhas de Rust, 96% menos que o QEMU, e começou como uma poda do crosvm do Chrome OS.
A segunda decisão é igualmente disciplinada: não reimplementar o que o Linux já faz bem. Escalonamento, gerência de memória, IO de bloco e rede vão para o host. Isso custa portabilidade e engorda a TCB, mas compra duas coisas — décadas de tuning que ninguém refaz, e operabilidade. ps num host Firecracker lista os MicroVMs; top, vmstat e kill funcionam como o operador espera.
como funciona
Um processo por MicroVM, o que já dá o modelo de isolamento. A configuração vem por uma API REST sobre socket Unix, e não por argumentos de linha de comando: dá para subir o processo, pré-configurar e só depois disparar o boot, cortando latência no caminho crítico.
O device model é curto. virtio para rede e bloco, porta serial e suporte parcial ao i8042. O driver do i8042 tem menos de 50 linhas de Rust, o serial cerca de 250, o virtio block inteiro cerca de 1.400. Bloco em vez de filesystem passthrough é decisão de segurança: filesystem é código grande e complexo, e expor só IO de bloco protege boa fatia do kernel do host. Rate limiters em token bucket, por dispositivo, limitam IOPS, pacotes e banda — existem porque não se confia no convidado para se autolimitar. cpuid é mascarável, para uma frota heterogênea parecer homogênea.
Por fora, o jailer envolve o processo antes do boot: chroot com quase nada dentro, namespaces de pid e rede, privilégios derrubados e um perfil seccomp-bpf com 24 syscalls liberadas, cada uma com filtro de argumento, e 30 ioctls — 22 delas exigidas pela própria API do KVM.
No Lambda, cada MicroVM é um slot: uma função, uma invocação concorrente, muitas invocações seriais reusando o mesmo processo. Um MicroManager por worker fala com um shim dentro do VM por TCP/IP — menos eficiente que um dispositivo dedicado, e escolhido justamente por não inventar dispositivo novo. Ele mantém um pool de MicroVMs pré-bootados, porque 125ms ainda é lento demais para o caminho de scale-up.
o que isso custou
Compatibilidade. Sem BIOS, sem kernel arbitrário, sem PCI, USB, vídeo ou som, sem migração de VM. Não é substituto de Docker ou Kubernetes: substitui o QEMU e nada mais.
Desempenho de IO. O convidado fica em torno de 13.000 IOPS de leitura 4kB onde o disco entrega mais de 340.000, porque as requisições são tratadas em série. Escrita parece boa em parte porque não há flush em disco — velocidade paga com durabilidade. Em rede, cerca de 15,6 Gb/s contra 44,1 do host, abaixo do QEMU e do Cloud Hypervisor. Os autores dizem que virtio nunca chegará ao passthrough de PCI usado nas instâncias EC2 normais.
Controle. Os rate limiters são bem mais pobres que cgroups: sem crédito de CPU, afinidade de core ou priorização de tráfego.
E side channel não se resolve numa camada só. O papel exige do operador SMT desligado, KPTI, mitigação de L1TF e de Speculative Store Bypass, swap e KSM desativados, arquivos não compartilhados. Ataques por energia e temperatura ficam explicitamente fora do escopo do Firecracker.
onde isso aparece hoje
Firecracker é open source sob Apache 2 desde dezembro de 2018 e roda em produção no Lambda e no Fargate, servindo trilhões de eventos por mês. A migração dos clientes do stack antigo aconteceu trocando a lógica de reciclagem de slot, que já expira em no máximo 12 horas — sem janela de manutenção.
O código virou base comum: o projeto rust-vmm mantém as crates compartilhadas entre Firecracker e crosvm, e o Cloud Hypervisor da Intel nasceu do mesmo tronco, mirando outro público. A ideia de MicroVM como unidade de isolamento de container foi adotada fora da AWS, com runtimes de container passando a oferecer o Firecracker como alternativa ao QEMU.
O que ele não resolve é o nível de cima. Empacotar milhares dessas caixas numa frota, decidir onde cada uma cai e sobrevender CPU com segurança continua sendo problema de escalonador, o território de Borg. Firecracker move a fronteira de segurança; quem coloca carga em cima dela é outro sistema.