Resumen

  • Deno ofrece seis meses más de servicio para Deploy y un año de correcciones mensuales para su runtime; JSR sigue por una vía distinta mientras su infraestructura se traslada a Cloudflare.
  • Cloudflare quiere convertir el autoalojamiento de Workers en una opción oficialmente respaldada, aunque su propio anuncio describe los Durable Objects de workerd como una implementación de instancia única que todavía no escala de forma distribuida.

El cliente de Deploy tiene que actuar primero

La noticia se mide antes en el calendario del servicio alojado que en el del código. En su anuncio del 9 de octubre, Deno dice que Deploy seguirá operativo durante seis meses y luego cerrará. La compañía ofrecerá asistencia de migración a Cloudflare Workers a los clientes de pago.

Ese compromiso no publica una fecha exacta de cierre ni cuantifica cuántas cuentas, proyectos o cargas de trabajo están afectadas. Tampoco define una tasa de migración, protección de precios o equivalencia entre los servicios. El comunicado no promete la misma asistencia a quienes no son clientes de pago.

La mudanza abarca más que el código de una aplicación. Hay que trasladar despliegues, estado, secretos, enlaces a otros servicios, observabilidad y supuestos de facturación. Workers es el destino anunciado para los clientes de pago; la información pública no demuestra que la operación conserve rendimiento, coste o carga de soporte.

El runtime conserva su propio ciclo

Deno promete publicaciones mensuales del runtime con correcciones de errores y seguridad durante un año más. Después, dejará de desarrollar el runtime por su cuenta, aunque mantendrá el código abierto. La empresa no identifica a un sucesor que se haga cargo de versiones, respuesta a vulnerabilidades o decisiones de compatibilidad una vez concluya ese período.

Para un equipo de plataforma, la diferencia es concreta. Un repositorio público permite continuar el programa; no garantiza que alguien responda a un incidente de seguridad, mantenga una cadencia de versiones o valide una actualización. Deno no publica un plan de financiación de la comunidad ni el nombre de un futuro responsable de esas funciones.

JSR no entra en ninguno de esos dos plazos. Deno dice que JSR continuará y que su infraestructura se trasladará a Cloudflare. También mantendrá el soporte de rusty_v8 y trabajará para integrarlo en workerd. El anuncio no proporciona una fecha de finalización ni dice que la integración ya esté terminada.

La portabilidad se probará con tareas de operación

Deno dice que todo su equipo se incorpora a Cloudflare y que su trabajo futuro se centrará en una plataforma común basada en el modelo de Workers. Cloudflare afirma que Ryan Dahl y Bert Belder liderarán el esfuerzo para que workerd sea una vía de autoalojamiento plenamente respaldada, combinando código e ideas de celld.

La compañía también expone el límite actual. En su publicación del 9 de octubre, Cloudflare dice que los Durable Objects de workerd funcionan como una sola instancia: sirven para pruebas locales, pero no para escalar de forma distribuida. La implementación de producción dentro de su red depende de un sistema de encaminamiento y de servicios externos que un operador independiente no puede reproducir simplemente descargando el runtime.

La documentación de limitaciones de celld 0.6.2 califica esa versión como beta y deja a cargo del operador tareas como la entrada de tráfico, la confidencialidad de red y la gestión de la flota. Es una descripción de una versión concreta, no una predicción del producto que Cloudflare planea integrar. Sí ayuda a medir cuánto falta entre disponer del código y operar un sistema con procedimientos y límites de soporte.

Los estados públicos son distintos: Deploy tiene una ventana de cierre; el runtime, un período de mantenimiento; JSR, una promesa de continuidad con cambio de infraestructura; y el autoalojamiento, un objetivo de desarrollo. Cloudflare dice que dará más noticias en los próximos meses. Las fuentes públicas no prueban aún que una aplicación de Workers con Durable Objects pueda salir de la red Cloudflare conservando comportamiento, coste y carga operativa.

El lenguaje sobre la operación también requiere precisión. Deno y Cloudflare dicen que el equipo de Deno se une a Cloudflare. TechCrunch describe el movimiento como una adquisición y señala que no se divulgaron las condiciones financieras. Las empresas no publican una valoración ni los detalles contractuales. Lo que sí queda definido es el cambio del equipo y las decisiones anunciadas sobre los productos.

Fuentes