O que é o Firecracker e por que todas as empresas de infraestrutura de agentes se importam com ele?

Todos os dias, o AWS Lambda executa trilhões de invocações de funções. O AWS Fargate agenda milhões de contêineres. Cada um deles é uma máquina virtual completa, com seu próprio kernel, inicializada em uma fração de segundo.

Como? Cerca de 50.000 linhas de Rust chamadas Firecracker, que existe porque a indústria finalmente admitiu que um contêiner Linux container que controla o uso de recursos nunca foi projetado para ser um limite de segurança.

O problema do isolamento

Cada contêiner Docker no seu laptop são três recursos do kernel do Linux em um sobretudo:

• Namespaces são vendas. Um processo dentro de um namespace tem uma visão privada do sistema: sua própria lista de PIDs, pilha de rede, tabela de montagem, hostname e IDs de usuário. O PID 1 dentro do contêiner é algum PID aleatório no host;atório no host; o contêiner nem consegue ver os outros processos.
• cgroups são orçamentos. Control groups são a camada de contabilidade e limitação de taxa do kernel. Eles limitam quanto de CPU, memória, IO de disco e largura de banda de rede uma árvore de processos pode consumir.
• seccomp + capabilities são listas de permissão. capabilities dividem os poderes do root em ~40 privilégios separados (vincular portas baixas, carregar módulos do kernel, montar sistemas de arquivos, etc.) para que você possa conceder apenas os que você precisa. seccomp é um filtro por processo que decide quais syscalls (a única API do userspace para o kernel) o processo tem permissão para fazer.

Você pode provar isso sozinho sem o Docker instalado:

<code-segment id="0" lang="text">

$ unshare --fork --pid --mount-proc bash

Agora você está em um novo namespace de PID e montagem.

O bash acha que é o PID 1.

</code-segment>

Todo o resto que o Docker faz (camadas de imagem, registros, DNS) é orquestração em cima disso.

Toda essa proteção passa por um único kernel Linux, com cerca de 30 milhões de linhas de código expondo 400+ syscalls. Cada contêiner no host chama esse mesmo kernel. Um bug em qualquer uma dessas syscalls e é game over para todos os inquilinos daquela máquina.

Máquinas virtuais completas resolvem o isolamento na força bruta: cada VM tem seu próprio kernel.

CPUs modernas têm um "modo convidado" que executa instruções do convidado no silício real. O host só é acionado quando o convidado faz algo privilegiado (toca em hardware real, causa uma falha, é interrompido). Um hypervisor é a camada fina que arbitra esses momentos.

O Linux fornece seu hypervisor como um módulo do kernel chamado KVM, exposto em /dev/kvm. Ele usa extensões de virtualização de hardware (vmx na Intel, svm na AMD):

<code-segment id="1" lang="text">

$ ls -l /dev/kvm

crw-rw---- 1 root kvm 10, 232 jan 1 00:00 /dev/kvm

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apicid movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp fsgsbase bmi1 avx2 smep bmi2 erms invpcid avx512 rdseed adx smap clflushopt clwb intel_pt xsaveopt xsavec xgetbv1 xsaves arat umip pku ospke avx512_vnni md_clear arch_capabilities</code-segment>

O problema das VMs completas é que elas são lentas e pesadas. Uma VM QEMU clássica emula um PC imaginário inteiro (BIOS, barramento PCI, controlador IDE, placa VGA, teclado, teclado PS/2) porque é contra isso que um SO de 1998 esperava inicializar. A imagem tem centenas de megabytes. A inicialização leva segundos. O footprint de memória é de centenas de MiB antes mesmo de sua carga de trabalho começar. Para uma requisição web que dura 40ms, você gastaria 40× isso inicializando a máquina.

Então você fica entre:

• Contêineres: 50ms de inicialização, 5 MiB de overhead, superfície de ataque do kernel compartilhado.
• VMs: 5+ segundos de inicialização, 300+ MiB de overhead, isolamento por hardware.

Todo mundo que executa código multi-inquilino não confiável (AWS e basicamente todos os fornecedores de sandbox de IA existentes) precisa dos dois lados dessa troca ao mesmo tempo.

Entram as microVMs

Um VMM (Virtual Machine Monitor) é o processo em userspace que dirige o hypervisor: ele configura a memória do convidado, conecta dispositivos virtuais e diz ao KVM para começar a executar o código convidado.

Uma microVM é um VMM com o PC de 1998 deletado: sem BIOS, sem barramento PCI, sem VGA, sem USB, sem ACPI (nenhum do hardware legado pelo qual um desktop real inicializa, e nada disso relevante para uma chamada de função de 40ms). O que sobra: KVM, um console serial e um console serial e um punhado de dispositivos virtio (net, block, vsock).

virtio é a interface padrão "Eu sei que estou rodando em uma VM". O convidado coopera com o hypervisor através de NICs e discos virtuais leves (virtio-net, virtio-block) em vez de fingir que está dirigindo uma placa Intel e1000 real ou um controlador IDE. Essa cooperação, mais todo o hardware legado ausente acima, é o maior motivo pelo qual as microVMs inicializam rápido.

O resultado:

• ~125ms de inicialização desde o lançamento do VMM até o userspace convidado executando init.
• <5 MiB de overhead de memória do VMM por VM (a memória de bookkeeping que o host paga por VM, antes da carga de trabalho convidado alocar qualquer coisa para si).
• 150 VMs/segundo de taxa de criação em um único host.
• ~2–8% de impacto no desempenho em tempo de execução em comparação com bare metal.

Mesmo isolamento em nível de hardware que uma VM completa, com a mesma ordem de grandeza de densidade que um contêiner.

O Firecracker é o VMM, o processo que realmente fala com /dev/kvm e inicializa a microVM. O resto deste post é essa pilha de ponta a ponta.

Firecracker

Em novembro de 2018, a AWS abriu o código do Firecracker no re:Invent. Ele já estava rodando o Lambda em produção, a coisa que faz seu import pandas inicializar a frio rápido o suficiente para ser cobrado por milissegundo. Em 2020, a equipe publicou a arquitetura no NSDI '20.

A arquitetura

Forkado do crosvm do Google, reescrito em Rust, com mais da metade do código removido. Cada processo Firecracker é uma microVM, com exatamente três tipos de thread (documentados em docs/design.md):

• md)):

• Thread da API é a mesa de pedidos. Um servidor REST vinculado a um socket Unix (um socket local que vive como um arquivo no disco, não uma porta TCP). Aceita configuração antes da inicialização e ações limitadas depois.
• Thread VMM é o chão de fábrica do hardware. Ela finge ser todos os dispositivos que o convidado pode ver. Quando o convidado toca no que pensa ser um registrador de NIC, a CPU pausa o convidado, o VMM lida com o toque ("convidado chutou a fila de TX, drene-a") e retoma. O mecanismo: o convidado lê/escreve endereços mágicos; a CPU captura esses para o host.[^mmio]
• Threads vCPU são os corredores. Uma por CPU convidada, cada uma em um loop apertado: pedir ao KVM para executar o convidado até que algo interessante aconteça algo interessante (toque em dispositivo, interrupção, halt), lidar com isso, loop.

Eles se comunicam através de canais Rust (filas de mensagens lock-free entre threads). O convidado vê exatamente quatro dispositivos.

Os quatro dispositivos

• virtio-net é a NIC da VM, sem emulação de 1998. O convidado escreve pacotes em uma virtqueue (um buffer circular em memória compartilhada); o VMM os drena através de um dispositivo TAP do lado do host (uma interface Ethernet virtual que o kernel expõe como um arquivo), acionado por io_uring ou epoll para que a thread VMM não bloqueie.
• virtio-block é o disco da VM, apenas IO de arquivo no host. O convidado coloca requisições de setor em uma virtqueue; o VMM emite pread/pwrite simples contra um arquivo do host. Sem IDE, sem AHCI, sem SCSI.
• virtio-vsock é o interfone da VM para o host. Endereçado por uma tupla (context-id, port) em vez de um par IP/porta, para que o agente convidado possa telefonar para casa (logs, pings de saúde, metadados de snapshot) sem IP convidado e nada na rede para falsificar.
• UART serial 8250 é o console de inicialização. Um pequeno chip serial legado emulado em um endereço fixo. Usado para logs de inicialização e dumps de falha antes do virtio subir. Barato, universal, nunca vai embora.

Inicializando uma microVM, de ponta ponta a ponta

A API é todo o plano de controle: o canal de configuração, mantido deliberadamente separado do plano de dados (as threads vCPU que realmente executam código convidado). Você inicia o binário apontado para um socket Unix:

<code-segment id="2" lang="text">

$ ./firecracker --api-sock /tmp/firecracker.sock</code-segment>

Então você coloca configuração nele:

<code-segment id="3" lang="json">

1. Definir kernel

curl --unix-socket /tmp/firecracker.sock -i \

-X PUT 'http://localhost/boot-source' \

-H 'Accept: application/json' \

-H 'Content-Type: application/json' \

-d'{"kernel_image_path": "/path/to/vmlinux.bin"}'

2. Definir disco raiz

curl --unix-socket /tmp/firecracker.sock -i \

-X PUT 'http://localhost/drives/rootfs' \

-H 'Accept: application/json' \

-H 'Content-Type: application/json' \

-d '{"drive_id": "rootfs", "path_on_host": "/path/to/rootfs.ext4", "is_root_device": true}'

3. Definir rede

curl --unix-socket /tmp/firecracker.sock -i \

-X PUT 'http://localhost/network-interfaces/eth0' \

-H 'Accept: application/json' \

-H 'Content-Type: application/json' \

-d '{"iface_id": "eth0", "host_dev_name": "tap0"}'

4. Iniciar a VM

curl --unix-socket /tmp/firecracker.sock -i \

-X PUT 'http://localhost/actions' \

-H 'Accept: application/json' \

-H 'Content-Type: application/json' \

-d '{"action_id": "InstanceId": "1", "action_type": "InstanceStart"}'</code-segment>

Quatro chamadas HTTP. Esse é o plano de controle inteiro.

A cebola de segurança

Uma única fronteira KVM já é forte. O Firecracker envolve mais duas camadas ao redor dela.

O jailer é um construtor de sandbox. Seu único trabalho é isolar o VMM antes mesmo de ele executar. Ele cria um chroot (um recurso do Linux que trava um processo a uma única subárvore de diretório como se esse diretório fosse a raiz do sistema de arquivos; o processo literalmente não pode nomear nada acima dela), cai em um novo namespace de PID para que não possa ver os outros processos do host, muda para um uid/gid não privilegiado, aplica limites de CPU/memória do cgroup, e só então executa o binário Firecracker dentro dessa jaula:

<code-segment id="4" lang="text">

$ ./jailer --id my-vm --exec-file ./firecracker --uid 1000 --gid 1000 --chroot-base-dir /srv/jailer -- -- --api-sock /tmp/firecracker.sock</code-segment>

Agora o próprio processo VMM não tem sistema de arquivos exceto um chroot dedicado, nenhuma visão de outros processos no host e nenhuma capacidade de root. Se uma fuga do convidado para o host acontecer através do virtio ou KVM, o atacante cai naquele chroot com limites de cgroup.

Seccomp é uma lista de permissão de syscalls por thread. Qualquer coisa não na lista é morta (ou retorna EPERM) antes de chegar ao manipulador de syscall do kernel. O Firecracker oferece três níveis:

1. Nível 0: desligado. Não use em produção.
2. Nível 1: lista de permissão por número de syscall.
3. Nível 2: também restringe valores de argumentos (ex.: ioctl é permitido, mas apenas com KVM_RUN como comando). Padrão e recomendado.

Cada thread obtém a superfície mínima possível: a thread da API não precisa de ioctl(KVM_RUN); as threads vCPU não precisam de socket(). Uma visão simplificada de como uma regra se parece:

<code-segment id="5" lang="json">

{

"syscall": "ioctl",

"action": "allow",

"args": [

{

"index": 1,

"type": "dtype": "dword",

"op": "eq": 0": 0xAE01 # KVM_RUN

}

]

}</code-segment>

Cada camada precisa falhar independentemente para um atacante alcançar o host.

Snapshots: o código secreto por trás do Lambda SnapStart

Tire um Snapshot de uma microVM em execução. Restaure-o em milissegundos, em um host diferente, em um novo processo VMM. Pule a inicialização do kernel, pule o init, pule o aquecimento JIT.

Você congela a VM em execução e despeja o estado da memória + dispositivos no disco:

<code-segment id="6" lang="json">

curl --unix-socket /tmp/firecracker.sock -i \

-X PUT 'http://localhost/snapshot/create' \

-H 'Accept: application/json' \

-H 'Content-Type: application/json' \

-d '{"snapshot_type": "Full", "snapshot_path": "./snapshot_file": "/snapshots/my-vm", "mem_file_path": "/snapshots/my-vm.mem"}'</code-segment>

Um snapshot captura um snapshot do snapshot captura o estado pós-aquecimento, então a VM restaurada acorda no meio da sua vida, não no começo.

Isso é exatamente o que o AWS Lambda SnapStart faz: inicializar um Java Lambda uma vez, tirar snapshot da microVM e restaurar esse snapshot em toda inicialização fria subsequente (anúncio). Inicializações frias da JVM vão de 8+ segundos para menos de um segundo.

Como eles se encaixam

gVisor é um design diferente: um kernel em userspace em Go, uma reimplementação da interface de syscall do Linux que roda como um processo normal. As syscalls do convidado batem no gVisor em vez do kernel host, e o gVisor decide o que (se algo) encaminhar adiante. Mais rápido de iniciar que uma microVM, 10–30% de overhead de syscall no caminho quente e um limite de confiança diferente.

O Firecracker fica na caixa "meu próprio kernel, mas sem PCI BIOS": isolamento de hardware, modelo de dispositivo minúsculo e inicialização em milissegundos.

Escolha sua ferramenta:

<code-segment id="7" lang="text">

Quem usa isso

É quase mais rápido listar as plataformas serverless que não ficam em cima de microVMs.

Firecracker em produção:

• AWS Lambda e AWS Fargate: o caso de uso original. Cada invocação do Lambda cai em uma microVM do Firecracker; tarefas do Fargate são VMs do Firecracker com um runtime de contêiner fino dentro.
• [Fly.io Machines](https://fly.io/docs/machines/): cada máquina fly é uma microVM do Firecracker, globalmente distribuída, com inicializações frias abaixo de um segundo e discos persistentes.
• Quase todo sandbox de execução de código de agente de IA que você usou nos últimos dezoito meses vive em uma microVM do Firecracker.

A forma de uma API de sandbox é mais ou menos a mesma entre fornecedores neste ponto:

<code-segment id="8" lang="text">

<code-segment id="8" lang="python">

from browserbase import Sandbox

sandbox = Sandbox(api_key="sk-...")

with sandbox.create() as vm:

result = vm.run("pip install numpy && python -c 'import numpy; import numpy; print(numpy.__version__)")

print(result.stdout)</code-segment>

Em cerca de quatro linhas de código: uma microVM do Firecracker inicializa, um kernel inicializa, um processo agente dentro do convidado recebe seu comando via vsock, executa, transmite resultados de volta e a VM morre.

A era do Agente: por que tudo isso importa agora

Um ano atrás, "o que é um sandbox de IA?" era uma pergunta nicho. Se um LLM gerasse código, provavelmente não era 100% seguro executar em qualquer máquina, então você o executava em um sandbox efêmero.

Hoje todo produto de IA sério envia um agente. Os sandboxes deles também melhoraram, mas a forma dos agentes mudou, e as respostas antigas de runtime não se encaixam na nova forma.

Agentes in-process vs agentes em nível de host

A primeira rodada de agentes de IA vivia dentro da sua aplicação. Você importava uma biblioteca, montava um loop e executava no seu backend existente:

<code-segment id="9" lang="python">

from openai import OpenAI

client = OpenAI()

tools = [get_weather, send_email]

def agent_loop(query):

messages = [{"role": "user", "content": query}]

while True:

response = client.chat.completions.create(

model="gpt-4",

messages=messages,

tools=tools

)

if response.choices[0].finish_reason == "stop":

return response.choices[0].message.content

Executar chamada de ferramenta

tool_call = response.choices[0].message.tool_calls[0]

result = execute_tool(tool_call)

messages.append(tool_call)

messages.append({"role": "tool", "content": result})</code-segment>

Cada chamada era uma viagem de ida e volta HTTP para um modelo. Cada chamada de ferramenta era uma função no seu próprio processo. O "sandbox" era seu próprio servidor. Este é o mundo do Vercel AI SDK, LangChain, OpenAI Agents SDK. Funciona muito bem e ainda entrega uma grande parte dos agentes de produção hoje.

A segunda rodada é diferente. Claude Code, Codex e OpenCode são agentes em nível de host-level agents: binários que assumem uma máquina, não bibliotecas que vivem dentro da sua. Eles esperam um shell real, um gerenciador de pacotes e um disco gravável. Quando você dá uma tarefa ao Claude Code, ele executa algo assim:

<code-segment id="10" lang="bash">

$ claude "Refatore o arquivo src/main.ts para usar async/await em vez de callbacks"

Claude Code:

1. Lê o arquivo

2. Edita o arquivo

3. Executa os testes

4. Verifica o resultado</code-segment>

Isso é um shell/bash. Ele precisa de um sistema de arquivos real, um fork/exec real, um gerenciador de pacotes, disco gravável, uma rede acessível. Nada disso é expressável como um esquema de ferramenta de chat-completion, e nada disso é seguro de executar em um contêiner de kernel compartilhado ao lado de outros inquilinos.

Os laboratórios estão pós-treinando seus modelos diretamente nesses harnesses (o arcabouço ao redor do modelo): o shell, o editor de arquivos, o executor de testes, o próprio loop do agente. Isso significa que a lacuna entre "modelo + harness no qual foi treinado" e "modelo + arcabouço DIY" está crescendo a cada trimestre.

Uma máquina Linux inteira por agente, executando código não confiável que o agente acabou de inventar, é exatamente a carga de trabalho para a qual o Firecracker foi construído. A convergência acima não foi um acidente.

Estamos começando a ver mais experimentação com agentes em torno da separação entre computação e harness. O Managed Agents da Anthropic é um exemplo disso, onde o harness do agente está sendo executado ao lado do sandbox, não dentro dele.

Algumas empresas estão até construindo sistemas de arquivos hospedados completos (como Archil e Mesa), para dar aos agentes melhor busca e armazenamento.

À medida que os agentes melhoram e mudam ao longo do tempo, haverá muitas mais ofertas de infraestrutura interessantes, construídas sobre o Firecracker.

O que você está realmente pagando para as plataformas de infra de agente

Os sandboxes genéricos de "executar código arbitrário" são uma commodity agora. A infraestrutura é totalmente open-source. A camada de microVM é Firecracker ou Cloud Hypervisor, disponível sob Apache 2.0. A conversão de contêiner para rootfs é um script Go de 200 linhas. Engenheiros talentosos podem montar uma plataforma de sandbox funcional em um fim de semana.

Você paga pelo que está conectado à VM. A microVM nua é o mínimo para entrar no jogo.

A superfície de produto interessante:

• Observabilidade é o produto, não uma ajuda de debug. Tudo que o agente faz (stdout, syscalls, escritas em arquivo, requisições de rede) flui através de um único socket para um coletor do lado do host. Construtores de agente precisam de replay completo de sessão e os artefatos por ação para criar os melhores produtos.
• Segredos são intermediados no fio, nunca entregues ao convidado. O convidado só vê variáveis de ambiente placeholder; echo $SECRET dentro do sandbox retorna o placeholder. Um proxy de egresso do lado do host (todo pacote de saída tem que cruzá-lo) substitui a credencial real no TAP do lado do host (a extremidade do kernel da NIC virtual da VM, que o convidado não pode ver ou endereçar), contra uma lista de permissão explícita, com uma trilha de auditoria por sessão. O agente pode estar executando código arbitrário que gerou cinco segundos atrás e ainda não consegue exfiltrar uma credencial que nunca teve.
• Identidade é assinada no host, não dentro do agente. Requisições de saída podem carregar uma identidade criptográfica por sessão (incluindo assinaturas Web Bot Auth, construídas sobre HTTP Message Signatures + Ed25519) cunhada pelo host antes do pacote sair da ponte. A chave de assinatura nunca entra na microVM.
• A outra computação é agrupada na mesma microVM que o runtime. O Browserbase emparelha cada runtime de agente 1:1 com um navegador no mesmo host, muitas vezes na mesma microVM. A distância física entre o processo do agente e o Chromium é efetivamente zero: comandos CDP (o Chrome DevTools Protocol, o formato de fio JSON sobre WebSocket usado para dirigir o Chrome programaticamente) vão sobre um socket Unix, não através de uma rede de serviços, então a latência de ação é de dígitos únicos milissegundos. Frames de screencast não precisam cruzar a internet pública para cair no replay de sessão.

E você não pode simplesmente costurar tudo isso de forma limpa em cima do Docker. As costuras não estão lá. Nossa aposta é que o mercado de runtime de agente não será vencido com computação bruta, mas com a melhor observabilidade, segredos, identidade, parcerias e a computação colocalizada colapsada em uma única superfície de produto.

Alternativas de runtime que vale a pena observar

• [Bubblewrap](https://github.com/containers/bubblewrap): sandboxing de namespace de usuário não privilegiado. Um usuário não-root pode criar um sandbox sem sudo, usando os mesmos primitivos do kernel que o Flatpak usa para confinar aplicativos desktop. Mais leve que uma VM, ainda compartilha o kernel host, então não é um substituto para microVMs contra código verdadeiramente não confiável. Mas é uma ótima camada de isolamento aninhado para executar dentro de uma microVM, ou uma boa escolha para código razoavelmente confiável no seu próprio host.
• [Isolados V8](https://blog.cloudflare.com/cloud-computing-without-containers/): o modelo do Cloudflare Workers. Cada isolado é um contexto de execução JS separado com seu próprio heap, todos compartilhando um único processo V8 com potencialmente milhares de outros inquilinos. A inicialização é ~5ms, duas ordens de grandeza mais rápida que uma microVM. O limite de confiança é o próprio sandbox do V8; historicamente ele se manteve bem, mas é uma linha muito mais fina que a de um hypervisor. Outro problema: você só obtém semânticas ao estilo Node. Sem fork, sem exec, sem módulos nativos, sistemas de arquivos simulados. Devastador para código de agente JS puro; inútil se você precisa pip install numpy.
• [gVisor](https://gvisor.dev/): kernel em userspace do Google em Go. Isolamento forte sem virtualização aninhada (uma VM convidada rodando dentro de outra VM, que a maioria dos provedores de nuvem desabilitam por padrão; o gVisor não precisa, então funciona no GKE direto da caixa). Paga ~10–30% em cargas de trabalho pesadas de syscall. Um meio-termo sólido quando a virtualização de hardware não está disponível.
• Sandboxes WASM ([wasmtime](https://wasmtime.dev/), [wasmer](https://wasmer.io/)): determinísticos, pequenos, rápidos, mas o ecossistema é raso. WASI (a API de syscall padrão para WASM) está amadurecendo. Ainda não é um alvo drop-in para "execute este binário Python/Node arbitrário".

Se você está construindo para código de propósito geral não confiável: Firecracker (ou Cloud Hypervisor, um design VMM/virtio similar). Se você está construindo para cargas de trabalho JS conhecidas de JS: isolados V8. Todo o resto é uma resposta especializada para uma pergunta especializada.

O panorama geral

O Firecracker pegou uma das ideias mais antigas da computação, uma máquina virtual, e deletou o suficiente dela para torná-la barata. Ele aposta que o isolamento forçado por hardware vale a pena se você puder torná-lo rápido o suficiente.

Essa aposta sempre iria se pagar para serverless. O que mudou é que a carga de trabalho "código multi-inquilino não confiável" cresceu de "uma função web que não quero isolar" para "um agente gerando comandos arbitrários que podem tocar em produção." O perímetro se moveu e a tolerância para escapes de kernel compartilhado foi de "risco aceitável" para "impossível de lançar."

E funcionou. É um binário Rust, com 50.000 linhas, que fala com /dev/kvm.

Contêineres empacotam software. MicroVMs isolam. A engenharia interessante da próxima década é tudo que você envolve em volta da caixa.

→ Kyle

Este post do blog tem componentes interativos e animações (que não aparecem em artigos do X. Se você quiser a versão, está aqui: https://www.browserbase.com/blog/what-is-firecracker.