Zeroserve: servidor web scriptable con eBPF

Si alguna vez has tenido que levantar un servidor web solo para servir una API pequeña, una página de estado o un proxy de pruebas, sabes que el problema no suele ser el código. El problema es todo lo demás: configuración, observabilidad, reglas de enrutamiento, logs, permisos, despliegue y mantenimiento. Al final terminas usando más piezas de las que realmente necesitas para resolver algo que, en teoría, era simple.

Ahí entra Zeroserve, una propuesta que mezcla servidor web, scripting y eBPF en un solo paquete. La idea no es solo correr HTTP, sino darte control fino sobre lo que pasa en cada request sin obligarte a montar una plataforma completa alrededor. Para equipos pequeños, entornos de laboratorio o despliegues muy específicos, eso abre una conversación útil: ¿cuánto puedes simplificar sin perder visibilidad ni control?

Qué es Zeroserve y por qué llama la atención

Zeroserve se presenta como un web server zero-config que puedes scriptar con eBPF. Según la publicación de lanzamiento de su autor, la apuesta es mover parte de la lógica de manejo de tráfico al kernel sin obligarte a escribir un servidor completo desde cero. La promesa es clara: menos configuración externa, menos piezas y más capacidad de intervenir el flujo de red con precisión.

La parte interesante no es solo que sirva HTTP. Eso ya lo hacen decenas de herramientas. Lo distinto es la combinación de tres capas que normalmente viven separadas: el servidor, la lógica de comportamiento y la observabilidad de bajo nivel. Si tú has usado Nginx, Caddy o un reverse proxy con plugins, sabes que muchas veces terminas encajando soluciones alrededor del core. Zeroserve intenta acercar esa lógica al punto donde ocurre el tráfico.

En la práctica, esto apunta a casos donde no quieres desplegar un stack grande para algo relativamente acotado. Piensa en una API interna para un equipo de producto, un endpoint de health checks, una herramienta de staging o una pieza de infraestructura para laboratorio. En esos escenarios, reducir configuración y tener scripting a nivel de eBPF puede ser más útil que sumar más abstracciones.

El problema que intenta resolver

El problema no es nuevo: cuando el tráfico es simple, la infraestructura suele ser demasiado pesada. Un ejemplo realista es el de una empresa pequeña en Quito o Guayaquil que necesita exponer un servicio interno para monitoreo y autenticación básica. Montar un gateway completo puede ser excesivo si solo necesitas enrutar dos o tres rutas y medir latencia por petición.

Con una herramienta como Zeroserve, la idea es que tú puedas definir comportamiento sin armar una cadena de componentes externos. Eso reduce el número de puntos de falla y también el tiempo que pasas manteniendo YAML, plugins o sidecars que no aportan al caso de uso.

Cómo encajan servidor, scripting y eBPF

eBPF no es magia y tampoco es un reemplazo universal para todo lo que haces en user space. Es un mecanismo del kernel para ejecutar programas seguros y limitados en eventos concretos. En redes, eso permite observar, filtrar o modificar ciertos flujos con muy poco overhead comparado con enfoques tradicionales. Si quieres revisar la base técnica, la documentación oficial de Linux es un buen punto de partida: https://docs.kernel.org/bpf/

En Zeroserve, la lectura interesante es que eBPF no aparece como una capa aislada de observabilidad, sino como parte del comportamiento del servidor. Eso cambia el modelo mental. En lugar de pensar solo en “recibo una request y la proceso”, piensas en “puedo inspeccionar, decidir y responder con reglas cercanas al kernel”. Para ciertos patrones, eso puede ser más eficiente y más expresivo.

Ahora bien, no conviene idealizarlo. eBPF tiene límites claros: verificación estricta, restricciones en loops y cuidado con la complejidad del programa. Si tu lógica de negocio crece mucho, probablemente querrás moverla a user space. Pero si tu objetivo es intervenir tráfico con reglas concretas, la combinación tiene sentido.

Qué te da eBPF en este contexto

En un servidor web scriptable, eBPF puede servir para varias cosas concretas:

1. Medir latencia por ruta sin instrumentar toda la app.
2. Detectar patrones de tráfico antes de que lleguen a la capa de aplicación.
3. Aplicar filtros o decisiones simples con menos overhead.
4. Obtener trazas más cercanas al sistema operativo.
5. Reducir la dependencia de agentes externos para observabilidad básica.

Eso no significa que reemplaces Prometheus, OpenTelemetry o tus logs de aplicación. Significa que puedes capturar señales más abajo en la pila, donde algunos problemas se ven antes. En entornos con recursos limitados, esa diferencia importa.

Qué significa “zero-config” de verdad

“Zero-config” suele usarse con mucha ligereza, así que conviene aterrizarlo. En este caso, la idea no es que nunca toques nada, sino que el arranque inicial y el caso básico requieran menos pasos que una solución tradicional. Eso es útil cuando quieres probar algo rápido o desplegar en una máquina pequeña.

Por ejemplo, si tu equipo necesita un servicio temporal para exponer un mock, un webhook receiver o una página de mantenimiento, no siempre quieres pasar por un proceso largo de configuración. Menos fricción significa menos tiempo entre la idea y el servicio corriendo.

Observabilidad y control fino sin una pila enorme

La palabra observabilidad se usa tanto que a veces pierde sentido. Aquí vale la pena bajarla a tierra: observabilidad es poder responder preguntas concretas sobre el sistema con señales útiles. ¿Cuántas requests fallaron? ¿Qué ruta tardó más? ¿Dónde se está acumulando el tráfico? Si tu servidor puede darte parte de eso desde una capa más baja, ganas contexto sin meter más agentes.

El ángulo de Zeroserve es atractivo porque mezcla control fino con visibilidad. No se trata solo de ejecutar lógica, sino de verla en acción cerca del tráfico. Para equipos que trabajan con despliegues mínimos, eso puede reducir la necesidad de montar herramientas separadas para cada cosa.

También hay un beneficio operativo: menos superficie de mantenimiento. Un stack mínimo suele ser más fácil de auditar, actualizar y explicar. Eso importa mucho cuando trabajas en organizaciones pequeñas o en equipos distribuidos entre países de LatAm, donde el tiempo de operación suele ser más valioso que la sofisticación técnica.

Casos donde sí tiene sentido

Zeroserve encaja mejor en escenarios concretos que en aplicaciones grandes y complejas. Algunos ejemplos:

• Un endpoint interno para health checks y métricas básicas.
• Un servicio temporal para staging o QA.
• Un proxy pequeño con reglas simples por ruta.
• Un entorno de laboratorio para probar tráfico y observabilidad.
• Un servicio de borde para una demo o PoC.

En esos casos, el valor no está en reemplazar toda tu arquitectura. El valor está en resolver una necesidad puntual con menos componentes. Si tu equipo hoy levanta un contenedor solo para devolver JSON y además necesita logs detallados, Zeroserve puede ser una opción interesante para evaluar.

Tabla comparativa rápida

La tabla no pretende decir que uno sea mejor en todo. Más bien muestra que Zeroserve ocupa un espacio específico: el de una pieza pequeña, con control fino y foco en comportamiento de red. Si tu problema es otro, probablemente necesites otra herramienta.

Qué debes mirar antes de usar algo así en producción

El primer filtro es la complejidad real del caso de uso. Si tu servicio necesita autenticación avanzada, plantillas, sesiones, colas o integración con varios sistemas, probablemente te convenga una arquitectura más convencional. eBPF ayuda mucho en observabilidad y control de tráfico, pero no reemplaza la lógica de una aplicación madura.

El segundo filtro es el equipo. Si nadie en tu grupo entiende eBPF, el costo de adopción puede ser más alto que el beneficio. No se trata solo de aprender una tecnología nueva, sino de operar algo que vive cerca del kernel. Eso exige más cuidado que una app común en Node, Go o Python.

El tercer filtro es el entorno. En servidores Linux modernos tienes más probabilidades de aprovechar eBPF bien. Si tu infraestructura es heterogénea o muy vieja, la historia cambia. Antes de apostar por una herramienta así, conviene revisar compatibilidad, permisos y el perfil de despliegue.

Señales de que sí te conviene probarlo

Si te reconoces en varios de estos puntos, vale la pena hacer una prueba:

1. Necesitas un servidor mínimo para una tarea muy concreta.
2. Quieres medir comportamiento de red sin sumar otro agente.
3. Tu equipo valora reducir configuración y dependencias.
4. Tu carga es pequeña o mediana, no una plataforma compleja.
5. Te interesa experimentar con eBPF sin construir toda la base desde cero.

Un piloto corto puede darte respuestas rápidas. Por ejemplo, puedes comparar latencia, facilidad de despliegue y claridad de métricas frente a tu solución actual. Si el resultado no mejora nada, lo sabrás pronto. Si mejora, tendrás una base para decidir con datos.

Lo que esta propuesta dice sobre el futuro de la infraestructura ligera

Más allá de Zeroserve, la idea de combinar runtime, observabilidad y control en una sola pieza apunta a una tendencia clara: menos capas para casos simples. No todo necesita una plataforma pesada. A veces basta con una herramienta bien enfocada que haga pocas cosas, pero las haga cerca del sistema.

Eso no elimina la necesidad de stacks grandes. Las aplicaciones complejas seguirán requiriendo bases de datos, colas, autenticación, cachés y observabilidad distribuida. Pero sí abre espacio para otra categoría de herramientas: las que resuelven problemas acotados con mucha precisión. Ahí eBPF está ganando terreno porque permite intervenir sin cargar tanto al usuario final ni al proceso principal.

Para equipos en LatAm, donde a menudo se trabaja con presupuestos ajustados y equipos pequeños, esta filosofía tiene sentido. Menos infraestructura significa menos costo operativo, menos tiempo de onboarding y menos fricción para probar ideas. Si además puedes observar mejor lo que pasa, el valor sube.

Qué puedes aprender aunque no lo adoptes

Aunque no uses Zeroserve en producción, puedes sacar varias ideas útiles:

• Diseñar servicios más pequeños y específicos.
• Mover observabilidad más cerca del tráfico.
• Reducir dependencias para prototipos y herramientas internas.
• Pensar en eBPF como una capa práctica, no solo experimental.
• Evaluar el costo operativo antes de sumar una pieza más.

Esa forma de pensar suele ahorrar tiempo. Muchas veces el problema no es que falte tecnología, sino que sobra infraestructura para el tamaño del caso de uso.

Tabla resumen

Si quieres entender mejor la base técnica, la documentación oficial de eBPF en Linux ayuda a poner contexto: https://docs.kernel.org/bpf/. También conviene leer la publicación original del proyecto para ver el enfoque del autor y sus límites: https://su3.io/posts/introducing-zeroserve