{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless","title":"Unikernels vs MicroVMs: Los Internals de Firecracker, Unikraft, y el Costo Real del Aislamiento Serverless","description":"Comparación exhaustiva de Firecracker MicroVMs y Unikraft unikernels: benchmarks de tiempo de boot, análisis de memoria, internals de KVM, y qué provee realmente aislamiento para funciones serverless en producción.","language":"es","datePublished":"2025-12-09","dateModified":null,"contentFormat":"text/markdown","content":"Infrastructure\n\n# Unikernels vs MicroVMs: Los Internals de Firecracker, Unikraft, y el Costo Real del Aislamiento Serverless\n\n2025-12-097 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/unikernels-firecracker-microvm-serverless>)\n\n## El Problema del Aislamiento\n\nEmpecemos con por qué importa. En una plataforma serverless, se está corriendo código no confiable de diferentes tenants en hardware compartido. El mecanismo de aislamiento debe garantizar que:\n\n1. Tenant A no puede leer la memoria de Tenant B\n2. Tenant A no puede acceder al filesystem de Tenant B\n3. Tenant A no puede consumir más CPU/memoria de lo asignado\n4. Un bug o exploit en el código de Tenant A no puede comprometer el host\n\nLos containers proveen propiedad 2 (vía mount namespaces), propiedad 3 (vía cgroups), y parcialmente propiedad 1 (vía PID/user namespaces). Pero fallan críticamente en la propiedad 4: todos los containers comparten el kernel del host, y el kernel Linux tiene una superficie de ataque masiva.\n\n## Firecracker: Un VMM Escrito en Rust\n\n[Firecracker](<https://firecracker-microvm.github.io/>) fue construido por [AWS](<https://aws.com/>) específicamente para Lambda y Fargate. Es un Virtual Machine Monitor que usa KVM (el hypervisor built-in de Linux) para crear máquinas virtuales livianas. Cada VM obtiene su propio kernel Linux, su propio espacio de memoria, y sus propios dispositivos virtuales.\n\n```\n┌─────────────────────────────────────────┐\n│ HOST OS │\n│ ┌──────────┐ ┌──────────┐ ┌────────┐ │\n│ │Firecracker│ │Firecracker│ │ ... │ │\n│ │ VMM │ │ VMM │ │ │ │\n│ │ (Rust) │ │ (Rust) │ │ │ │\n│ ├──────────┤ ├──────────┤ ├────────┤ │\n│ │ KVM │ │ KVM │ │ KVM │ │\n│ ├──────────┤ ├──────────┤ ├────────┤ │\n│ │Guest │ │Guest │ │Guest │ │\n│ │Linux │ │Linux │ │Linux │ │\n│ │Kernel │ │Kernel │ │Kernel │ │\n│ ├──────────┤ ├──────────┤ ├────────┤ │\n│ │Function A│ │Function B│ │Func C │ │\n│ └──────────┘ └──────────┘ └────────┘ │\n└─────────────────────────────────────────┘\n```\n\nLo que hace \"micro\" a Firecracker:\n\n**Modelo de dispositivos mínimo**: Los VMMs tradicionales (QEMU) emulan cientos de dispositivos, controladores USB, tarjetas de sonido, buses ISA legacy. Firecracker emula exactamente 5 tipos de dispositivo: virtio-net, virtio-block, consola serial, un controlador de teclado i8042 mínimo (para shutdown), y un reloj KVM. Eso es todo. Menos dispositivos = menor superficie de ataque = menos código que auditar.\n\n**Sin BIOS, sin UEFI**: Firecracker carga el kernel Linux directo en la memoria del guest y configura los parámetros de boot manualmente. Esto saltea toda la secuencia de boot de firmware.\n\nEsto es lo que Firecracker hace al arrancar:\n\n```rust\n// Secuencia de boot simplificada de Firecracker\nfn boot_microvm(config: &VmConfig) -> Result<Vm> {\n // 1. Abrir /dev/kvm y crear una VM\n let kvm_fd = open(\"/dev/kvm\", O_RDWR)?;\n let vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, 0)?;\n\n // 2. Configurar memoria del guest (típicamente 128MB-2GB)\n let guest_mem = GuestMemory::new(config.mem_size_mib)?;\n ioctl(vm_fd, KVM_SET_USER_MEMORY_REGION, &guest_mem.region())?;\n\n // 3. Cargar el kernel directo en memoria del guest\n let kernel = load_kernel(&config.kernel_path, &guest_mem)?;\n\n // 4. Configurar parámetros de boot\n let boot_params = configure_boot_params(kernel.entry_point, &config)?;\n\n // 5. Crear vCPUs y configurar registros\n let vcpu_fd = ioctl(vm_fd, KVM_CREATE_VCPU, 0)?;\n set_initial_registers(vcpu_fd, &boot_params)?;\n\n // 6. Configurar dispositivos virtio (net, block)\n let mmio_bus = setup_virtio_devices(&config, &guest_mem)?;\n\n // 7. Entrar al loop de VM (ejecuta código del guest vía KVM_RUN)\n Ok(Vm { vm_fd, vcpu_fd, guest_mem, mmio_bus })\n}\n```\n\n## Tiempos de Boot: Números Reales\n\nLos tiempos de boot de Firecracker medidos en una instancia m5.metal (bare-metal, sin virtualización anidada):\n\n```\nFase Tiempo\n─────────────────────────────────────\nioctl KVM_CREATE_VM: 0.2ms\nSetup de memoria (256MB): 1.8ms\nCarga del kernel (5.10): 3.1ms\nSetup vCPU + init registros: 0.4ms\nSetup dispositivos virtio: 0.8ms\n─────────────────────────────────────\nVMM listo para KVM_RUN: 6.3ms\nBoot kernel guest hasta init: ~125ms\nInit Alpine Linux hasta shell: ~30ms\n─────────────────────────────────────\nTotal hasta userspace corriendo: ~160ms\n```\n\n160ms de la nada a un userspace Linux corriendo. Es notable, pero para funciones serverless que necesitan responder en \\<200ms, ese tiempo de boot sigue siendo una tajada significativa del presupuesto de latencia. Aquí es donde entran los snapshots.\n\n### Snapshots de Firecracker\n\nFirecracker puede tomar un snapshot del estado completo de una VM corriendo y restaurarlo en ~5ms:\n\n```bash\n# Crear snapshot de VM corriendo\ncurl --unix-socket /tmp/firecracker.socket -X PUT \\\n http://localhost/snapshot/create \\\n -d '{\n \"snapshot_type\": \"Full\",\n \"snapshot_path\": \"/snapshots/function-v1.snap\",\n \"mem_file_path\": \"/snapshots/function-v1.mem\"\n }'\n\n# Restaurar VM desde snapshot (~5ms)\ncurl --unix-socket /tmp/firecracker.socket -X PUT \\\n http://localhost/snapshot/load \\\n -d '{\n \"snapshot_path\": \"/snapshots/function-v1.snap\",\n \"mem_file_path\": \"/snapshots/function-v1.mem\"\n }'\n```\n\nAWS Lambda usa exactamente este mecanismo: cuando despliega una función, Lambda la bootea una vez, snapshottea el estado inicializado, y restaura desde snapshot en cold starts subsiguientes.\n\n## Unikraft: Library Operating Systems\n\nLos unikernels toman un approach fundamentalmente diferente. En vez de correr un kernel Linux completo con miles de syscalls, drivers, y subsistemas, un unikernel incluye solo los componentes del OS que la aplicación realmente usa.\n\n```\nVM Tradicional:\n Aplicación → libc → Kernel Linux (25M+ líneas de código) → Hardware\n\nUnikernel Unikraft:\n Aplicación → lib/nolibc → lib/vfscore → lib/9pfs → driver KVM\n → lib/uknetdev → driver virtio-net\n → lib/uksched → scheduler cooperativo\n (total: ~100K líneas de código)\n```\n\n```bash\n# Buildear el unikernel\nkraft build --target firecracker/x86_64 --log-level debug\n\n# Correr con Firecracker\nkraft run --target firecracker/x86_64 \\\n --memory 64 \\\n --network bridge:kraft0 \\\n -- /my-http-server --port 8080\n```\n\n## Comparación Cara a Cara\n\nTodas las mediciones en el mismo hardware (c5.metal, bare-metal):\n\n```\n Firecracker Unikraft Docker\n (guest Alpine) (servidor HTTP) (Alpine)\n────────────────────────────────────────────────────────────────────────────\nBoot a primer HTTP response: 160ms 8ms ~800ms*\nMemoria (idle): 32MB 2MB ~15MB\nTamaño de imagen: ~50MB ~1.2MB ~8MB\nSyscalls soportadas: ~400 ~160 ~400\nBoundary de seguridad: KVM + VMM KVM Namespace\nExperiencia de debugging: Buena (gdb) Dolorosa Excelente\nCompatibilidad ecosistema: Binarios Linux Recompilación Todo\n────────────────────────────────────────────────────────────────────────────\n```\n\nEse es 8ms de boot time de Unikraft no son un typo. Un unikernel no tiene BIOS, no tiene bootloader, no carga módulos del kernel, no tiene systemd, no tiene proceso init. Va directo de \"VM arrancada\" a \"main() de la aplicación corriendo.\"\n\nPero observar la fila de compatibilidad del ecosistema. Firecracker corre cualquier binario Linux, Node.js, Python, Go, Java, cualquier cosa con un build para Linux. Unikraft requiere recompilación contra su libc (basada en musl) y puede no soportar todas las syscalls que tu aplicación usa. En un caso, se pasaron dos días tratando de hacer andar una app de Flask en Python sobre Unikraft antes de descubrir que usaba ` sendfile() ` que no estaba implementada en el stack de red de Unikraft en ese momento.\n\n## Elecciones Prácticas para Producción\n\nPara aislamiento de funciones serverless: **Firecracker**. La compatibilidad con el ecosistema vale la memoria extra y el tiempo de boot. Con snapshot-restore, los cold starts son ~5ms de todas formas.\n\nPara edge computing con workloads conocidos y controlados: **Unikraft**. Cuando el comportamiento de la aplicación está bien caracterizado (servir archivos estáticos, correr módulos WASM, proxear HTTP), un unikernel de 2MB que bootea en 8ms es irresistible. El overhead operativo es más alto porque debuggear es más complico, pero para workloads bien caracterizados, vale la pena.\n\nPara todo lo demás: **Firecracker con Kata Containers**. Esto te da la ergonomía de containers (docker build, docker push, CI/CD estándar) con aislamiento de VM. El overhead de boot time es ~150ms, que es aceptable para la mayoría de los workloads que no son funciones serverless críticas en latencia.\n\nLa verdad honesta es que los unikernels vienen siendo \"el futuro\" hace una década, y todavía no son mainstream. Firecracker triunfó donde los unikernels no porque hizo un tradeoff pragmático: aceptar un kernel Linux completo con su overhead y superficie de ataque, pero hacerlo lo suficientemente rápido y aislado para que no importe. A veces \"suficientemente bueno\", despachado y probado en batalla, supera a perfecto pero todavía madurando.\n\n## Preguntas frecuentes\n\n### ¿Por qué AWS Lambda no usa containers para aislamiento?\n\nLos containers comparten el kernel del host, y las vulnerabilidades del kernel permiten escapes. Lambda corre sobre Firecracker MicroVMs donde cada invocación de función obtiene una instancia dedicada del kernel Linux con superficie de ataque mínima. Un escape de container te da acceso al host; un escape de VM requiere una vulnerabilidad de KVM, que es un target mucho más difícil.\n\n### ¿Los unikernels están listos para producción?\n\nDepende del framework. Unikraft alcanzó madurez para producción en workloads específicos, servidores HTTP estáticos, runtimes WASM, runtimes de lenguajes específicos. MirageOS se usa en producción en algunas organizaciones. Pero unikernels de propósito general que puedan correr binarios Linux arbitrarios no existen. Cambiás compatibilidad por performance y seguridad.\n\n### ¿Firecracker puede correr containers?\n\nNo directamente. Firecracker es un VMM que bootea un kernel Linux y un root filesystem. Pero herramientas como Kata Containers y el containerd-snapshotter de AWS usan Firecracker como backend de aislamiento para imágenes OCI. La imagen del container se convierte en el root filesystem de la MicroVM, dándote la ergonomía de containers con aislamiento de VM.\n\n## Tips\n\n1. **Tip:** Cuando se benchmarkean tiempos de boot de Firecracker, medir desde el ioctl ` CreateVM ` hasta la primera respuesta HTTP exitosa del guest, no hasta el boot del kernel. El kernel bootea en ~125ms pero el init de tu aplicación agrega 20-500ms dependiendo del runtime. El número que importa es time-to-first-response.\n2. **Tip:** Usar el binario ` jailer ` de Firecracker en producción, no ` firecracker ` pelado. El jailer configura cgroups, chroot, filtros seccomp, y dropea privilegios antes de arrancar el VMM. Correrlo sin jailer es como correr Docker sin namespaces, técnicamente funciona, pero se saca la capa de seguridad exterior.\n3. **Tip:** Para Unikraft, empezar con el CLI ` kraft ` y el catálogo de apps prearmadas en ` unikraft.org/apps ` antes de intentar buildear imágenes custom. Buildear un unikernel Unikraft desde cero implica configurar un menú KConfig con 400+ opciones, y si le errás te da un kernel panic sin debugger. Aprender el tooling primero.\n\n- unikernels\n- firecracker\n- microvm\n- serverless\n- unikraft\n- kvm\n- virtualización\n- infraestructura-cloud\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Unikernels vs MicroVMs: Los Internals de Firecracker, Unikraft, y el Costo Real del Aislamiento Serverless","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#title"},{"level":2,"text":"El Problema del Aislamiento","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#el-problema-del-aislamiento"},{"level":2,"text":"Firecracker: Un VMM Escrito en Rust","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#firecracker-un-vmm-escrito-en-rust"},{"level":2,"text":"Tiempos de Boot: Números Reales","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#tiempos-de-boot-nmeros-reales"},{"level":3,"text":"Snapshots de Firecracker","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#snapshots-de-firecracker"},{"level":2,"text":"Unikraft: Library Operating Systems","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#unikraft-library-operating-systems"},{"level":2,"text":"Comparación Cara a Cara","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#comparacin-cara-a-cara"},{"level":2,"text":"Elecciones Prácticas para Producción","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#elecciones-prcticas-para-produccin"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#questions"},{"level":3,"text":"¿Por qué AWS Lambda no usa containers para aislamiento?","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#question-1"},{"level":3,"text":"¿Los unikernels están listos para producción?","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#question-2"},{"level":3,"text":"¿Firecracker puede correr containers?","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#article-tips"}],"sections":[{"heading":"Unikernels vs MicroVMs: Los Internals de Firecracker, Unikraft, y el Costo Real del Aislamiento Serverless","level":1,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless","content":"Infrastructure"},{"heading":"Unikernels vs MicroVMs: Los Internals de Firecracker, Unikraft, y el Costo Real del Aislamiento Serverless","level":1,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#title","content":"2025-12-097 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/unikernels-firecracker-microvm-serverless>)"},{"heading":"El Problema del Aislamiento","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#el-problema-del-aislamiento","content":"Empecemos con por qué importa. En una plataforma serverless, se está corriendo código no confiable de diferentes tenants en hardware compartido. El mecanismo de aislamiento debe garantizar que:\n\n1. Tenant A no puede leer la memoria de Tenant B\n2. Tenant A no puede acceder al filesystem de Tenant B\n3. Tenant A no puede consumir más CPU/memoria de lo asignado\n4. Un bug o exploit en el código de Tenant A no puede comprometer el host\n\nLos containers proveen propiedad 2 (vía mount namespaces), propiedad 3 (vía cgroups), y parcialmente propiedad 1 (vía PID/user namespaces). Pero fallan críticamente en la propiedad 4: todos los containers comparten el kernel del host, y el kernel Linux tiene una superficie de ataque masiva."},{"heading":"Firecracker: Un VMM Escrito en Rust","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#firecracker-un-vmm-escrito-en-rust","content":"[Firecracker](<https://firecracker-microvm.github.io/>) fue construido por [AWS](<https://aws.com/>) específicamente para Lambda y Fargate. Es un Virtual Machine Monitor que usa KVM (el hypervisor built-in de Linux) para crear máquinas virtuales livianas. Cada VM obtiene su propio kernel Linux, su propio espacio de memoria, y sus propios dispositivos virtuales.\n\n```\n┌─────────────────────────────────────────┐\n│ HOST OS │\n│ ┌──────────┐ ┌──────────┐ ┌────────┐ │\n│ │Firecracker│ │Firecracker│ │ ... │ │\n│ │ VMM │ │ VMM │ │ │ │\n│ │ (Rust) │ │ (Rust) │ │ │ │\n│ ├──────────┤ ├──────────┤ ├────────┤ │\n│ │ KVM │ │ KVM │ │ KVM │ │\n│ ├──────────┤ ├──────────┤ ├────────┤ │\n│ │Guest │ │Guest │ │Guest │ │\n│ │Linux │ │Linux │ │Linux │ │\n│ │Kernel │ │Kernel │ │Kernel │ │\n│ ├──────────┤ ├──────────┤ ├────────┤ │\n│ │Function A│ │Function B│ │Func C │ │\n│ └──────────┘ └──────────┘ └────────┘ │\n└─────────────────────────────────────────┘\n```\n\nLo que hace \"micro\" a Firecracker:\n\n**Modelo de dispositivos mínimo**: Los VMMs tradicionales (QEMU) emulan cientos de dispositivos, controladores USB, tarjetas de sonido, buses ISA legacy. Firecracker emula exactamente 5 tipos de dispositivo: virtio-net, virtio-block, consola serial, un controlador de teclado i8042 mínimo (para shutdown), y un reloj KVM. Eso es todo. Menos dispositivos = menor superficie de ataque = menos código que auditar.\n\n**Sin BIOS, sin UEFI**: Firecracker carga el kernel Linux directo en la memoria del guest y configura los parámetros de boot manualmente. Esto saltea toda la secuencia de boot de firmware.\n\nEsto es lo que Firecracker hace al arrancar:\n\n```rust\n// Secuencia de boot simplificada de Firecracker\nfn boot_microvm(config: &VmConfig) -> Result<Vm> {\n // 1. Abrir /dev/kvm y crear una VM\n let kvm_fd = open(\"/dev/kvm\", O_RDWR)?;\n let vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, 0)?;\n\n // 2. Configurar memoria del guest (típicamente 128MB-2GB)\n let guest_mem = GuestMemory::new(config.mem_size_mib)?;\n ioctl(vm_fd, KVM_SET_USER_MEMORY_REGION, &guest_mem.region())?;\n\n // 3. Cargar el kernel directo en memoria del guest\n let kernel = load_kernel(&config.kernel_path, &guest_mem)?;\n\n // 4. Configurar parámetros de boot\n let boot_params = configure_boot_params(kernel.entry_point, &config)?;\n\n // 5. Crear vCPUs y configurar registros\n let vcpu_fd = ioctl(vm_fd, KVM_CREATE_VCPU, 0)?;\n set_initial_registers(vcpu_fd, &boot_params)?;\n\n // 6. Configurar dispositivos virtio (net, block)\n let mmio_bus = setup_virtio_devices(&config, &guest_mem)?;\n\n // 7. Entrar al loop de VM (ejecuta código del guest vía KVM_RUN)\n Ok(Vm { vm_fd, vcpu_fd, guest_mem, mmio_bus })\n}\n```"},{"heading":"Tiempos de Boot: Números Reales","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#tiempos-de-boot-nmeros-reales","content":"Los tiempos de boot de Firecracker medidos en una instancia m5.metal (bare-metal, sin virtualización anidada):\n\n```\nFase Tiempo\n─────────────────────────────────────\nioctl KVM_CREATE_VM: 0.2ms\nSetup de memoria (256MB): 1.8ms\nCarga del kernel (5.10): 3.1ms\nSetup vCPU + init registros: 0.4ms\nSetup dispositivos virtio: 0.8ms\n─────────────────────────────────────\nVMM listo para KVM_RUN: 6.3ms\nBoot kernel guest hasta init: ~125ms\nInit Alpine Linux hasta shell: ~30ms\n─────────────────────────────────────\nTotal hasta userspace corriendo: ~160ms\n```\n\n160ms de la nada a un userspace Linux corriendo. Es notable, pero para funciones serverless que necesitan responder en \\<200ms, ese tiempo de boot sigue siendo una tajada significativa del presupuesto de latencia. Aquí es donde entran los snapshots."},{"heading":"Snapshots de Firecracker","level":3,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#snapshots-de-firecracker","content":"Firecracker puede tomar un snapshot del estado completo de una VM corriendo y restaurarlo en ~5ms:\n\n```bash\n# Crear snapshot de VM corriendo\ncurl --unix-socket /tmp/firecracker.socket -X PUT \\\n http://localhost/snapshot/create \\\n -d '{\n \"snapshot_type\": \"Full\",\n \"snapshot_path\": \"/snapshots/function-v1.snap\",\n \"mem_file_path\": \"/snapshots/function-v1.mem\"\n }'\n\n# Restaurar VM desde snapshot (~5ms)\ncurl --unix-socket /tmp/firecracker.socket -X PUT \\\n http://localhost/snapshot/load \\\n -d '{\n \"snapshot_path\": \"/snapshots/function-v1.snap\",\n \"mem_file_path\": \"/snapshots/function-v1.mem\"\n }'\n```\n\nAWS Lambda usa exactamente este mecanismo: cuando despliega una función, Lambda la bootea una vez, snapshottea el estado inicializado, y restaura desde snapshot en cold starts subsiguientes."},{"heading":"Unikraft: Library Operating Systems","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#unikraft-library-operating-systems","content":"Los unikernels toman un approach fundamentalmente diferente. En vez de correr un kernel Linux completo con miles de syscalls, drivers, y subsistemas, un unikernel incluye solo los componentes del OS que la aplicación realmente usa.\n\n```\nVM Tradicional:\n Aplicación → libc → Kernel Linux (25M+ líneas de código) → Hardware\n\nUnikernel Unikraft:\n Aplicación → lib/nolibc → lib/vfscore → lib/9pfs → driver KVM\n → lib/uknetdev → driver virtio-net\n → lib/uksched → scheduler cooperativo\n (total: ~100K líneas de código)\n```\n\n```bash\n# Buildear el unikernel\nkraft build --target firecracker/x86_64 --log-level debug\n\n# Correr con Firecracker\nkraft run --target firecracker/x86_64 \\\n --memory 64 \\\n --network bridge:kraft0 \\\n -- /my-http-server --port 8080\n```"},{"heading":"Comparación Cara a Cara","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#comparacin-cara-a-cara","content":"Todas las mediciones en el mismo hardware (c5.metal, bare-metal):\n\n```\n Firecracker Unikraft Docker\n (guest Alpine) (servidor HTTP) (Alpine)\n────────────────────────────────────────────────────────────────────────────\nBoot a primer HTTP response: 160ms 8ms ~800ms*\nMemoria (idle): 32MB 2MB ~15MB\nTamaño de imagen: ~50MB ~1.2MB ~8MB\nSyscalls soportadas: ~400 ~160 ~400\nBoundary de seguridad: KVM + VMM KVM Namespace\nExperiencia de debugging: Buena (gdb) Dolorosa Excelente\nCompatibilidad ecosistema: Binarios Linux Recompilación Todo\n────────────────────────────────────────────────────────────────────────────\n```\n\nEse es 8ms de boot time de Unikraft no son un typo. Un unikernel no tiene BIOS, no tiene bootloader, no carga módulos del kernel, no tiene systemd, no tiene proceso init. Va directo de \"VM arrancada\" a \"main() de la aplicación corriendo.\"\n\nPero observar la fila de compatibilidad del ecosistema. Firecracker corre cualquier binario Linux, Node.js, Python, Go, Java, cualquier cosa con un build para Linux. Unikraft requiere recompilación contra su libc (basada en musl) y puede no soportar todas las syscalls que tu aplicación usa. En un caso, se pasaron dos días tratando de hacer andar una app de Flask en Python sobre Unikraft antes de descubrir que usaba ` sendfile() ` que no estaba implementada en el stack de red de Unikraft en ese momento."},{"heading":"Elecciones Prácticas para Producción","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#elecciones-prcticas-para-produccin","content":"Para aislamiento de funciones serverless: **Firecracker**. La compatibilidad con el ecosistema vale la memoria extra y el tiempo de boot. Con snapshot-restore, los cold starts son ~5ms de todas formas.\n\nPara edge computing con workloads conocidos y controlados: **Unikraft**. Cuando el comportamiento de la aplicación está bien caracterizado (servir archivos estáticos, correr módulos WASM, proxear HTTP), un unikernel de 2MB que bootea en 8ms es irresistible. El overhead operativo es más alto porque debuggear es más complico, pero para workloads bien caracterizados, vale la pena.\n\nPara todo lo demás: **Firecracker con Kata Containers**. Esto te da la ergonomía de containers (docker build, docker push, CI/CD estándar) con aislamiento de VM. El overhead de boot time es ~150ms, que es aceptable para la mayoría de los workloads que no son funciones serverless críticas en latencia.\n\nLa verdad honesta es que los unikernels vienen siendo \"el futuro\" hace una década, y todavía no son mainstream. Firecracker triunfó donde los unikernels no porque hizo un tradeoff pragmático: aceptar un kernel Linux completo con su overhead y superficie de ataque, pero hacerlo lo suficientemente rápido y aislado para que no importe. A veces \"suficientemente bueno\", despachado y probado en batalla, supera a perfecto pero todavía madurando."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#questions","content":""},{"heading":"¿Por qué AWS Lambda no usa containers para aislamiento?","level":3,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#question-1","content":"Los containers comparten el kernel del host, y las vulnerabilidades del kernel permiten escapes. Lambda corre sobre Firecracker MicroVMs donde cada invocación de función obtiene una instancia dedicada del kernel Linux con superficie de ataque mínima. Un escape de container te da acceso al host; un escape de VM requiere una vulnerabilidad de KVM, que es un target mucho más difícil."},{"heading":"¿Los unikernels están listos para producción?","level":3,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#question-2","content":"Depende del framework. Unikraft alcanzó madurez para producción en workloads específicos, servidores HTTP estáticos, runtimes WASM, runtimes de lenguajes específicos. MirageOS se usa en producción en algunas organizaciones. Pero unikernels de propósito general que puedan correr binarios Linux arbitrarios no existen. Cambiás compatibilidad por performance y seguridad."},{"heading":"¿Firecracker puede correr containers?","level":3,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#question-3","content":"No directamente. Firecracker es un VMM que bootea un kernel Linux y un root filesystem. Pero herramientas como Kata Containers y el containerd-snapshotter de AWS usan Firecracker como backend de aislamiento para imágenes OCI. La imagen del container se convierte en el root filesystem de la MicroVM, dándote la ergonomía de containers con aislamiento de VM."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#article-tips","content":"1. **Tip:** Cuando se benchmarkean tiempos de boot de Firecracker, medir desde el ioctl ` CreateVM ` hasta la primera respuesta HTTP exitosa del guest, no hasta el boot del kernel. El kernel bootea en ~125ms pero el init de tu aplicación agrega 20-500ms dependiendo del runtime. El número que importa es time-to-first-response.\n2. **Tip:** Usar el binario ` jailer ` de Firecracker en producción, no ` firecracker ` pelado. El jailer configura cgroups, chroot, filtros seccomp, y dropea privilegios antes de arrancar el VMM. Correrlo sin jailer es como correr Docker sin namespaces, técnicamente funciona, pero se saca la capa de seguridad exterior.\n3. **Tip:** Para Unikraft, empezar con el CLI ` kraft ` y el catálogo de apps prearmadas en ` unikraft.org/apps ` antes de intentar buildear imágenes custom. Buildear un unikernel Unikraft desde cero implica configurar un menú KConfig con 400+ opciones, y si le errás te da un kernel panic sin debugger. Aprender el tooling primero.\n\n- unikernels\n- firecracker\n- microvm\n- serverless\n- unikraft\n- kvm\n- virtualización\n- infraestructura-cloud\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/unikernels-firecracker-microvm-serverless"},{"text":"Firecracker","url":"https://firecracker-microvm.github.io/"},{"text":"AWS","url":"https://aws.com/"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless"},"headline":"Unikernels vs MicroVMs: Los Internals de Firecracker, Unikraft, y el Costo Real del Aislamiento Serverless","description":"Comparación exhaustiva de Firecracker MicroVMs y Unikraft unikernels: benchmarks de tiempo de boot, análisis de memoria, internals de KVM, y qué provee realmente aislamiento para funciones serverless en producción.","datePublished":"2025-12-09","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://lucioduran.com/favicons/og-default.png","url":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"Infrastructure","keywords":"unikernels, firecracker, microvm, serverless, unikraft, kvm, virtualización, infraestructura-cloud","wordCount":1207,"timeRequired":"PT7M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/unikernels-firecracker-microvm-serverless"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Unikernels vs MicroVMs: Los Internals de Firecracker, Unikraft, y el Costo Real del Aislamiento Serverless","item":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Por qué AWS Lambda no usa containers para aislamiento?","acceptedAnswer":{"@type":"Answer","text":"Los containers comparten el kernel del host, y las vulnerabilidades del kernel permiten escapes. Lambda corre sobre Firecracker MicroVMs donde cada invocación de función obtiene una instancia dedicada del kernel Linux con superficie de ataque mínima. Un escape de container te da acceso al host; un escape de VM requiere una vulnerabilidad de KVM, que es un target mucho más difícil."}},{"@type":"Question","name":"¿Los unikernels están listos para producción?","acceptedAnswer":{"@type":"Answer","text":"Depende del framework. Unikraft alcanzó madurez para producción en workloads específicos, servidores HTTP estáticos, runtimes WASM, runtimes de lenguajes específicos. MirageOS se usa en producción en algunas organizaciones. Pero unikernels de propósito general que puedan correr binarios Linux arbitrarios no existen. Cambiás compatibilidad por performance y seguridad."}},{"@type":"Question","name":"¿Firecracker puede correr containers?","acceptedAnswer":{"@type":"Answer","text":"No directamente. Firecracker es un VMM que bootea un kernel Linux y un root filesystem. Pero herramientas como Kata Containers y el containerd-snapshotter de AWS usan Firecracker como backend de aislamiento para imágenes OCI. La imagen del container se convierte en el root filesystem de la MicroVM, dándote la ergonomía de containers con aislamiento de VM."}}]}]}],"contentHash":"51d90c160d828ca3055c454461b23e12eae95bff6e67591bdc1714e5eefec9bd","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/unikernels-firecracker-microvm-serverless","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":61962,"contentBytes":12718}}