Capítulo 1: Conceptos Fundamentales de Firecracker
Capítulo 1: Conceptos Fundamentales
¿Qué es Firecracker?
Firecracker es un Virtual Machine Monitor (VMM) open-source escrito en Rust por AWS. No es un emulador completo como QEMU ni un runtime de contenedores como Docker — es algo entre ambos: proporciona el aislamiento fuerte de las VMs con la eficiencia de los contenedores.
Datos clave
- Tiempo de arranque de microVM: < 125 ms
- Footprint de memoria del VMM: < 5 MiB por microVM
- Throughput: hasta 150 microVMs/segundo por host
- Dispositivos emulados: solo 6 (vs. cientos en QEMU)
- Lenguaje: Rust (seguridad de memoria sin GC)
El problema que resuelve
Las plataformas serverless (AWS Lambda, Fargate) necesitan ejecutar código de miles de clientes diferentes en el mismo hardware físico, con:
- Aislamiento fuerte: que el código del cliente A no pueda afectar al cliente B
- Arranque rápido: las funciones deben iniciarse en milisegundos
- Alta densidad: cientos de instancias por servidor
- Overhead mínimo: cada instancia debe consumir el menor RAM posible
Los contenedores Docker ofrecen velocidad y densidad pero comparten el kernel del host (menor aislamiento). Las VMs tradicionales ofrecen aislamiento fuerte pero son lentas y pesadas. Firecracker ocupa el punto óptimo.
Arquitectura interna
Cada instancia de Firecracker ejecuta tres tipos de threads:
graph TD
A[Proceso Firecracker] --> B[API Thread]
A --> C[VMM Thread]
A --> D[vCPU Thread 1]
A --> E[vCPU Thread N]
B -->|"HTTP via Unix socket"| F[Cliente externo]
C --> G[Dispositivos VirtIO]
C --> H[Consola serial]
D -->|KVM_RUN| I[CPU virtual]
E -->|KVM_RUN| I
- API Thread: servidor HTTP sobre Unix socket. Recibe peticiones de configuración. No está en el camino crítico de ejecución.
- VMM Thread: gestiona el modelo de máquina, dispositivos VirtIO (red, bloque, vsock), MMDS y rate limiting.
- vCPU Threads: uno por CPU virtual. Ejecutan el loop principal
KVM_RUNen el kernel de Linux.
Modelo de máquina mínimo
Firecracker no emula hardware genérico. Solo expone los dispositivos estrictamente necesarios:
| Dispositivo | Tipo | Propósito |
|---|---|---|
| VirtIO Net | Red | Comunicación de red |
| VirtIO Block | Almacenamiento | Acceso a disco |
| VirtIO Balloon | Memoria | Gestión dinámica de RAM |
| VirtIO Vsock | IPC | Comunicación host↔guest |
| VirtIO RNG | Entropía | Fuente aleatoria segura |
| Serial Console | Debug | Salida de consola (ttyS0) |
KVM: el fundamento
Firecracker no emula la CPU — usa KVM (Kernel-based Virtual Machine), un módulo del kernel Linux que convierte el host en un hypervisor tipo 1. El guest ejecuta instrucciones directamente en el hardware físico.
graph LR
A[Guest Linux] -->|instrucciones privilegiadas| B[KVM]
B -->|hardware real| C[CPU física]
A -->|dispositivos VirtIO| D[VMM Thread]
D -->|syscalls| E[Kernel host]
Esto requiere que el hardware tenga soporte de virtualización: Intel VT-x o AMD-V.
Comparación con alternativas
| Criterio | Docker | QEMU | Firecracker |
|---|---|---|---|
| Aislamiento | Kernel compartido | Fuerte | Fuerte |
| Tiempo de arranque | ~100 ms | ~5-10 s | ~125 ms |
| Overhead RAM | ~10 MB | ~100 MB | ~5 MB |
| Seguridad | Media | Alta | Alta |
| Velocidad I/O | Nativa | Moderada | Alta (VirtIO) |
| Uso en prod | Microservicios | VMs generales | Serverless, FaaS |
Casos de uso reales
- AWS Lambda: cada invocación corre en una microVM Firecracker
- AWS Fargate: contenedores con aislamiento de VM
- Fly.io: deploys de aplicaciones en microVMs
- Kata Containers: runtime alternativo para containerd/Kubernetes
Limitaciones importantes
- Solo soporta arquitecturas x86_64 y aarch64 (no hay emulación cruzada)
- El guest debe tener la misma arquitectura que el host
- Requiere Linux con KVM habilitado (no funciona en macOS ni Windows directamente)
- Kernel guest mínimo: v5.10