Minimalismo, velocidad y seguridad

Llevo un tiempo cuestionándome si Docker y Kubernetes son realmente el techo de lo que podemos hacer al empaquetar microservicios, o si simplemente son el estándar que heredamos porque funcionó bien durante la última década. Esa duda me llevó a investigar a fondo los unikernels, y quiero dejar por escrito lo que encontré, con números incluidos.

El estado actual: contenedores en todas partes

Docker y Kubernetes dominan el mercado. Revisando ofertas laborales recientes, el patrón es evidente: orquestación y contenerización, experiencia con Kafka, RabbitMQ, pipelines CI/CD, control de versiones, dominio de arquitectura de microservicios con Docker y Kubernetes. Es el vocabulario estándar de cualquier vacante backend hoy.

Y con razón: los contenedores han resuelto problemas reales.

• Rápidos: con un pool caliente de contenedores ya inicializados, los tiempos de respuesta bajan de ~220ms a un rango de 4-6ms en peticiones subsecuentes.
• Relativamente seguros: herramientas como Docker Sandboxes permiten aislar procesos y detectar vulnerabilidades por severidad (en un escaneo típico: decenas de altas, cientos de medias, un centenar de bajas).
• Ligeros: técnicas como multi-stage builds mantienen las imágenes en el rango de decenas o pocos cientos de MB, en lugar de gigabytes.

Pero un contenedor sigue siendo un proceso más sobre un kernel compartido. Namespaces y cgroups aíslan, pero no eliminan la superficie de ataque del kernel host, ni el overhead de las syscalls que atraviesan esa capa compartida.

La pregunta técnica de fondo

Si el objetivo real es:

• Seguridad por diseño (no por configuración)
• Aislamiento total, no namespace-level
• Superficie de ataque mínima
• Arranque en el orden de milisegundos
• Consumo de recursos reducido al mínimo necesario

…entonces el modelo contenedor-sobre-kernel-compartido tiene un techo estructural. La alternativa que fui a explorar es más radical: eliminar el sistema operativo de propósito general por completo.

Qué es exactamente un unikernel

Un unikernel es un binario que combina, en una sola imagen, el kernel y la aplicación. No es un sistema operativo de propósito general con la aplicación encima: es un sistema operativo especializado, compilado específicamente para ejecutar un único proceso, con solo los drivers, el stack de red y las primitivas que esa aplicación necesita.

Características técnicas concretas:

• Un único proceso en ejecución: no hay multiproceso, no hay scheduler multiusuario.
• Sin shell, sin usuarios, sin subsistema de permisos: no hay superficie para un ataque de escalación de privilegios porque no hay privilegios que escalar.
• Inmutable por diseño: la imagen no se modifica en runtime; cualquier cambio implica reconstruir y redesplegar.
• Sin librerías ni drivers innecesarios: el linker estático solo incluye lo que el código realmente invoca.

El resultado son imágenes de unos pocos MB, frente a los cientos de MB (o GB) de una imagen de contenedor típica basada en una distro completa.

Por qué el rendimiento es estructuralmente distinto

Eliminación de cambios de contexto kernel/usuario: en un sistema operativo tradicional, cada syscall implica un cambio de contexto entre espacio de usuario y espacio de kernel (ring 3 → ring 0). En un unikernel esa distinción prácticamente desaparece: la aplicación y el “kernel” comparten el mismo espacio de direcciones y el mismo nivel de privilegio. Las llamadas que normalmente costarían miles de ciclos de CPU se convierten en llamadas a función directas.

Arranque en microsegundos/milisegundos: al no haber que inicializar subsistemas genéricos (gestión de usuarios, múltiples drivers de dispositivo, montaje de sistemas de archivos complejos, etc.), el tiempo de boot cae drásticamente. Esto es clave para arquitecturas serverless, donde el cold-start es uno de los principales cuellos de botella.

Superficie de ataque mínima: si tu binario no incluye un intérprete de shell, no tiene sentido buscar un exploit de shell. Si no hay gestión de usuarios, no hay ataques de escalación de privilegios vía usuarios. La inmutabilidad además cierra la puerta a ataques de persistencia (el atacante no puede escribir un backdoor en un sistema de archivos que se descarta en cada despliegue).

Densidad de instancias: al consumir mucha menos memoria y CPU en reposo, es posible empaquetar un número significativamente mayor de instancias por servidor físico, algo directamente relevante para el costo por unidad de cómputo.

Comparando el stack de virtualización

Vale la pena poner los cuatro modelos lado a lado, capa por capa:

Cada capa que desaparece es una fuente de overhead (contexto de CPU, latencia de I/O, superficie de ataque) que se elimina con ella. Un unikernel corriendo directamente sobre un hipervisor tipo 1 tiene, literalmente, una capa menos que un contenedor corriendo sobre un SO host que a su vez corre sobre un hipervisor.

El hipervisor sigue siendo necesario

Los unikernels no eliminan la necesidad de aislamiento a nivel de hardware; de hecho, casi siempre se ejecutan dentro de una VM ligera sobre un hipervisor. En el ecosistema Linux, las piezas relevantes son:

• KVM — hipervisor de tipo 1, integrado en el kernel Linux.
• QEMU — actúa como VMM (Virtual Machine Monitor), emulando el hardware que la VM ve.
• Firecracker — el VMM desarrollado por AWS, optimizado específicamente para microVMs de arranque rápido y huella mínima. Es la base de AWS Lambda y AWS Fargate.

El detalle técnico importante: Firecracker recorta deliberadamente el device model de QEMU a lo mínimo indispensable (virtio-net, virtio-block, un teclado serie), lo que reduce tanto la superficie de ataque como el tiempo de arranque de la VM en sí, antes incluso de que arranque el unikernel que corre dentro.

Dos implementaciones que se pueden usar hoy

Unikraft — kraft

Unikraft apunta a una experiencia de desarrollo similar a la de Docker, con un archivo de definición declarativo:

spec: v0.6

runtime: base:latest
rootfs: ./Dockerfile
cmd: ["/server"]

env:
  ENV: prod
  GIN_MODE: release

Instalación:

curl -sSf https://get.kraftkit.sh | sh

Flujo de trabajo:

# Construir el unikernel a partir del Kraftfile
kraft build

# Ejecutar la imagen resultante
kraft run

# Listar los paquetes/unikernels disponibles localmente
kraft pkg list

Un detalle técnico relevante: Unikraft permite reutilizar un Dockerfile existente como rootfs, lo cual reduce bastante la fricción de migración desde una imagen de contenedor ya construida.

NanoVMs — ops

NanoVMs (Nanos) toma un enfoque distinto: en lugar de requerir que recompiles tu aplicación contra un runtime específico, ejecuta binarios ELF directamente, implementando una capa de compatibilidad con el ABI de Linux.

Configuración vía config.json:

{
  "Env": {
    "ENV": "prod",
    "GIN_MODE": "release"
  },
  "RunConfig": {
    "Ports": ["8080"]
  }
}

Instalación:

curl https://ops.city/get.sh -sSfL | sh

Flujo de trabajo:

# Construir el unikernel a partir del binario
ops build <APP>

# Ejecutar la imagen
ops run <APP>

# Listar imágenes locales
ops image list

# Listar imágenes remotas
ops pkg list

La diferencia de enfoque es importante: Unikraft suele requerir mayor especialización (drivers y librerías construidos para su runtime específico), mientras que Nanos prioriza compatibilidad binaria directa con aplicaciones ya compiladas para Linux.

Benchmarks: números concretos

Comparé Docker, NanoVMs y Unikraft bajo las mismas condiciones de infraestructura, midiendo tiempo de arranque acumulado (25 iteraciones) y latencia de una petición simple:

Métrica	Docker	NanoVMs	Unikraft
Arranque (25 iteraciones)	9.2s	8.9s	5.2s
Latencia (1 petición)	2221µs	640µs	85µs

La diferencia en latencia es la que más llama la atención: Unikraft resuelve la petición en un orden de magnitud menor que Docker, y varias veces más rápido que NanoVMs. Esto es consistente con la eliminación de cambios de contexto kernel/usuario que mencioné antes.

Es importante ser riguroso sobre las condiciones del benchmark, porque afectan directamente la interpretación de los resultados:

• Se ejecutó sobre una instancia EC2 no bare metal, lo que añade capas intermedias: hipervisor Nitro de AWS → instancia EC2 → Firecracker/QEMU → unikernel. Cada una de esas capas introduce overhead adicional que no es atribuible al unikernel en sí.
• La CPU asignada era de tipo burstable/compartida, no dedicada, lo que introduce ruido en la medición de latencia.
• La configuración de red no estaba optimizada (sin ajustes de MTU, sin SR-IOV, etc.).
• No se aplicó ningún tuning al kernel Linux del host.

En un entorno bare metal, con CPU dedicada y red optimizada, es razonable esperar que las diferencias sean aún mayores, ya que se eliminarían varias de las capas intermedias que actualmente absorben parte del beneficio teórico.

Interoperabilidad con el ecosistema Docker

Un punto técnico que suele sorprender: no es necesario abandonar el tooling de Docker para adoptar unikernels. Existen runtimes compatibles con la especificación OCI que permiten ejecutar unikernels como si fueran contenedores normales, entre ellos urunc y runu.

El flujo, a nivel de configuración del daemon, es:

# 1. Instalar un runtime OCI compatible con unikernels
#    (urunc, runu u otro runtime)

# 2. Registrar el runtime en /etc/docker/daemon.json
#    agregando la entrada correspondiente en "runtimes"

# 3. Ejecutar la imagen especificando el runtime
docker run --runtime urunc <imagen>

Esto es relevante porque implica que la migración puede ser incremental: se puede mantener el orquestador (Docker, containerd, incluso Kubernetes vía runtimeClass) y sustituir selectivamente el runtime de bajo nivel para las cargas donde el unikernel realmente aporta valor.

Limitaciones que hay que asumir

Ningún análisis técnico está completo sin las contras:

• Ecosistema inmaduro: la cantidad de librerías, frameworks y runtimes soportados de forma nativa es mucho menor que en el mundo Linux tradicional.
• Compatibilidad limitada: no todas las syscalls, ni todo el multithreading complejo, ni ciertas dependencias del sistema (por ejemplo, algunas implementaciones de JIT) funcionan igual dentro de un unikernel.
• Debugging complejo: sin shell, sin strace, sin las herramientas habituales de introspección, depurar un problema en producción requiere un cambio de mentalidad y, en muchos casos, herramientas específicas del propio proyecto (kraft/ops).

Dónde tiene sentido usarlos hoy

Con todo lo anterior, la conclusión técnica a la que llego es que los unikernels no reemplazan a Docker de forma generalizada, pero sí resuelven un problema muy específico mejor que cualquier alternativa actual: cargas de corta duración, sensibles a la latencia y al tiempo de arranque, donde la seguridad por diseño importa más que la flexibilidad operativa. Esto los hace especialmente atractivos para:

• Serverless / FaaS, donde el cold-start es un costo directo (no es casualidad que AWS Lambda use microVMs con Firecracker por debajo).
• Edge computing, donde el hardware es limitado y cada MB de RAM cuenta.
• Green computing, porque una densidad de instancias mayor por servidor se traduce directamente en menor consumo energético por unidad de trabajo.

La pregunta que me queda abierta, y que probablemente define hacia dónde va esta parte de la industria, es hasta qué punto el ecosistema madurará lo suficiente como para que “compilar contra un unikernel” deje de ser una decisión de nicho y se convierta en una opción de despliegue tan estándar como hoy lo son los contenedores.