Deux compteurs ont démarré le 9 octobre
Le rachat par Cloudflare de toute l'équipe de Deno, annoncé le 9 octobre, lance deux comptes à rebours de migration pour quiconque fait tourner du logiciel sur Deno.
| Élément | Ce qui a été annoncé | Date qui en découle |
|---|---|---|
| Deno Deploy | Continue de fonctionner six mois puis ferme ; les clients payants reçoivent une aide à la migration vers Cloudflare Workers | Vers avril 2027 |
| Runtime Deno | Versions mensuelles de correctifs et de sécurité pendant un an, puis Deno met fin à son propre développement | Vers octobre 2027 |
| Registre JSR | Continue de fonctionner, son infrastructure passant chez Cloudflare | Aucune date de fin |
| rusty_v8 | Le support continue, avec un travail d'intégration dans workerd | Aucune date de fin |
La colonne de droite est notre calcul à partir de la date d'annonce, pas une date publiée par l'une des sociétés. Aucun des deux billets de blog n'indique de prix, et The New Stack rapporte que les conditions n'ont pas été divulguées. Le site ajoute que Deno avait levé environ 26 millions de dollars en deux tours.
Le vide que Cloudflare a payé pour combler
Cloudflare dit que la pièce manquante était l'auto-hébergement. Son runtime open source pour Workers, workerd, ne gère les Durable Objects qu'en instance unique, suffisante pour des tests locaux mais incapable de monter en charge, et Kenton Varda a écrit que des commentaires de tâches à faire à ce sujet remontent à la publication d'origine.
La réponse de Deno a été celld, sorti en août : un seul binaire en Rust qui n'exige comme service externe qu'un bucket de stockage d'objets. Ryan Dahl et Bert Belder vont maintenant mener l'effort pour faire de l'auto-hébergement de workerd un mode de premier rang et pris en charge pour exécuter le modèle Workers, en ramenant dans workerd du code et des idées de celld.
La logique commerciale est énoncée sans détour. Varda a dit à The New Stack que si le modèle Workers est réservé à Cloudflare, il réduit le marché atteignable de l'entreprise, donc le faire fonctionner chez tous les fournisseurs profite à Cloudflare. Dahl a dit que le projet commun devrait rester open source, probablement sous la licence Apache 2.0 que celld utilise déjà.
Promis n'est pas livré
L'auto-hébergement à grande échelle est une promesse pour les mois à venir, pas un produit aujourd'hui. Le billet de Cloudflare dit qu'on peut déjà auto-héberger celld ou workerd, mais workerd seul ne sait toujours pas répartir les Durable Objects sur plusieurs machines.
Pour les acheteurs européens qui pèsent la souveraineté, la perspective est réelle. Un runtime pris en charge, avec la même API que la plateforme de Cloudflare, exécuté sur vos propres serveurs, serait une sortie du réseau de Cloudflare, et Varda soutient que l'open source et une porte de sortie sont de bonnes affaires. Cette voie n'existe pas encore sous forme prise en charge, alors jugez-la sur les fonctions livrées, pas sur des billets de blog.
Que faire ce trimestre
Listez chaque projet qui tourne sur Deno Deploy, avec son responsable et son trafic, et choisissez la destination avant la fin mars 2027. Cloudflare Workers est la voie avec aide à la migration pour les clients payants, mais tout hébergeur qui exécute du JavaScript standard convient.
Si vous exécutez le runtime Deno sur vos propres serveurs, vous avez un an de mises à jour de sécurité mensuelles. Figez la version et choisissez entre un passage à Node.js et un fork communautaire. Dahl explique que la compatibilité croissante de Deno avec Node.js l'avait conduit à maintenir une autre implémentation de la même technologie, et que chacun est le bienvenu pour poursuivre le runtime.
Si vous publiez des paquets sur JSR, rien ne change aujourd'hui. Continuez à publier et notez que l'infrastructure du registre passe chez Cloudflare.
À lire ensuite: Cloudflare écrit déjà vos règles d'entraînement IA | FMI : 14 accords d'IA, 1 400 milliards d'engagements
