- OpenWorkers es un runtime de código abierto basado en V8 que ejecuta JavaScript, lo que permite implementar computación en el borde sobre infraestructura propia
- Soporta almacenamiento KV, PostgreSQL, almacenamiento compatible con S3/R2, service bindings, variables de entorno y secretos
- Mantiene una alta compatibilidad con Cloudflare Workers, incluyendo las principales Web API como fetch, ReadableStream y crypto.subtle
- Permite autohospedaje sencillo con sandbox V8 Isolate, programación cron y despliegue basado en Docker Compose
- Es un proyecto que ha evolucionado durante unos 7 años y busca ser un entorno de ejecución JavaScript sin dependencia de proveedor
Resumen de OpenWorkers
- OpenWorkers es un runtime compatible con Cloudflare Workers escrito en Rust que ejecuta JavaScript usando V8 Isolate
- Permite aprovechar las ventajas de la computación en el borde también en entornos de servidor propios
- Está publicado como código abierto, por lo que se puede desplegar y modificar libremente
Funciones principales
- Integra diversos recursos externos mediante la función de bindings
- Almacenamiento KV: soporta get, put, delete y list
- Integración con base de datos PostgreSQL
- Soporte para almacenamiento compatible con S3/R2
- Incluye service bindings, variables de entorno y gestión de secretos
- Soporte de Web API
- Proporciona API estándar como fetch, Request, Response y ReadableStream
- Incluye crypto.subtle, TextEncoder/Decoder, Blob, setTimeout y AbortController
Arquitectura
- El sistema está compuesto por proxy nginx, dashboard, API, servicio de logs, runner, PostgreSQL, NATS y scheduler, entre otros
- Cada runner ejecuta código dentro de un V8 Isolate, con límites de CPU de 100 ms y memoria de 128 MB
- Incluye un scheduler integrado con soporte para sintaxis cron de 5 a 6 campos
- Mantiene compatibilidad sintáctica con Cloudflare Workers
Autohospedaje
- El despliegue puede hacerse solo con una base de datos PostgreSQL y un archivo Docker Compose
- Se puede ejecutar fácilmente con los comandos
git clone, configuración de .env y docker compose up
- Incluye procedimientos de migración y generación de tokens
Contexto de desarrollo
- Es un proyecto completado tras cerca de 7 años de desarrollo
- Al principio se experimentó con sandboxing de JS usando vm2, y luego evolucionó inspirado por el modelo de Cloudflare Workers
- Pasó por Deno-core y actualmente fue reescrito sobre rusty_v8
- El objetivo es ofrecer una experiencia de desarrollo (DX) al nivel de Cloudflare Workers mientras construye un entorno de ejecución en servidores propios sin dependencia de proveedor
- En el futuro planea agregar depuración determinista mediante funciones de registro y reproducción de ejecución
1 comentarios
Comentarios en Hacker News
Me parece interesante la idea de llevar el poder del edge computing a infraestructura propia
Pero siento que el self-hosting choca un poco con la esencia misma del edge computing
Es un modelo posible porque grandes vendors como Cloudflare tienen más de 300 PoP (Point of Presence) en todo el mundo
Claro, se podría armar una estructura parecida combinando vendors más pequeños y éticos, pero implica mucho más esfuerzo y riesgo
Tal vez con unos 10 en regiones clave ya sería suficiente
Aunque también me preocupa que coordinar eso de forma segura y confiable sea demasiado difícil
El problema de una solución de sandbox es que debe ofrecer una garantía fuerte de que el código no puede escapar del sandbox
Para demostrarlo, hacen falta resultados de pruebas frente a múltiples escenarios de ataque y documentación detallada
Pero documentación de ese nivel es muy rara, y en la práctica cuesta encontrar ejemplos realmente confiables
Por eso yo reviso si hay casos en los que una gran empresa lo use en producción y un equipo de seguridad lo mantenga
Incluso llega a aplicar releases de V8 antes que Chrome
Cada worker se ejecuta como un isolate y no como un proceso separado, de forma similar al modelo de Cloudflare
Pero al manejar código de terceros completamente no confiable, es mejor añadir una capa extra de aislamiento con contenedores o VM
Este sandboxing está más enfocado en el aislamiento de recursos que en la seguridad
Una auditoría de seguridad del estilo “lo verificamos y es seguro, créannos” no es suficiente
pero en un entorno self-hosted ya existe acceso al sistema, así que hay menos motivo para preocuparse por un escape del sandbox
Me parece un gran proyecto
Si workerd es open source, me pregunto si la diferencia de OpenWorkers está en ofrecer un entorno completo
También quisiera saber si hay diferencias en el runtime en sí, o planes de ofrecer un servicio administrado en el futuro
1️⃣ workerd solo ofrece el runtime, mientras que OpenWorkers es una plataforma completa con dashboard, API, scheduler, logs y bindings (KV, S3/R2, Postgres)
2️⃣ workerd está basado en C++, mientras que OpenWorkers usa Rust + rusty_v8, por lo que es más simple y más fácil de hackear
3️⃣ Ya existe una versión administrada en dash.openworkers.com, con incluso un tier gratuito
Pero el self-hosting está diseñado como ciudadano de primera clase
Lo central de Cloudflare Workers es el cobro por función, pero si es self-hosted al final hay que aprovisionar hardware por adelantado
No todo tiene que tercerizarse, y está bien que existan opciones similares
Este tipo de alternativas ayuda a bajar la barrera de adopción
Antes trabajé bastante separando deno_core, así que entiendo por qué se pasaron a raw rusty_v8
deno_core tiene mucho código legacy, y al tocarlo seguido se rompían las pruebas
Pero nos movimos a rusty_v8 para tener un control más fino del runtime internamente,
y más adelante planeamos volver a agregar funciones faltantes también al runtime de deno
Si es un proyecto que ayuda a reducir la dependencia de un vendor, estoy totalmente a favor
Ojalá eso presione a los servicios cloud a ajustar sus precios a la realidad
Ahora mismo cobran de más incluso por funciones básicas como NAT
Claro, la nube es cómoda, pero el problema es su alto costo frente al DIY
Si las grandes empresas acaparan los recursos, podría volverse difícil para individuos alojar cosas por su cuenta
Pero en la práctica, en muchos países operarlo uno mismo cuesta más
No termina con la instalación; también son considerables los costos de personal de mantenimiento y monitoreo
Estaría bueno que la documentación dejara claro qué funciones todavía no operan y cuál es el roadmap
La siguiente prioridad es una función de registro/reproducción de ejecución para depuración, y planeamos agregar una sección de roadmap en la documentación
El diagrama de arquitectura ASCII se ve roto en Pixel + Firefox
Los diagramas basados en texto tienen su encanto, pero en la práctica es más útil publicar una versión compilada como imagen
Es una idea de producto excelente, tanto técnica como estructuralmente
En especial me gusta el modelo de devolver en open source los proyectos open source de los grandes vendors
Es decir, en vez de que ellos tomen open source y lo comercialicen, nosotros devolvemos su modelo al open source — creo que justamente así debería hacerse
Parece que está volviendo la idea de “¿y si hospedamos la nube directamente en nuestras computadoras?”
Últimamente se ve esta tendencia de self-hosting en varios lados
También está interesante este video de presentación
La esencia de la nube es la elasticidad (elasticity)
Poder subir y bajar instancias según la necesidad y pagar solo por lo que usas
En self-hosting las herramientas de despliegue pueden ser cómodas, pero al final igual tienes que asumir el costo completo de los servidores
Si la carga es constante o predecible, está bien, pero si no, es ineficiente
(Por poner una analogía: es la diferencia entre tomar el autobús y tener una van propia)
El desarrollador puede concentrarse en implementar handlers de eventos, y si además incluye colas o ejecución durable, se vuelve aún más potente
Al final, FaaS es una herramienta de alto nivel que abstrae el código boilerplate