Deno уходит в Cloudflare, поддержка рантайма - ещё год. Разбираем, как считать стоимость выхода из зависимости от рантайма и AI-модели.
Cloudflare покупает Deno и через год прекращает поддерживать сам рантайм. Рядом лежит комментарий Саймона Уиллисона про embedding-модели: проприетарную модель вендор однажды снимет с продажи, а миллионы сохранённых векторов придётся считать заново. Мысль у обеих историй одна: у зависимости от чужого рантайма или чужой модели есть срок годности, и его стоимость надо заложить в бюджет до внедрения.
В августе команда Deno выпустила первую версию celld.
Durable Object - объект с собственным состоянием, который живёт в одном месте и обрабатывает запросы последовательно.
На нём удобно строить чаты, счётчики, блокировки и координацию без отдельной базы.
Цель, как её формулирует компания: опереться на celld и сделать self-hosting workerd (открытого рантайма, на котором работают Workers) полноценным, официально поддерживаемым способом запускать приложения на модели Workers.
Для тех, кто уже пишет на Deno, новость тяжёлая: Cloudflare будет поддерживать сам рантайм Deno ещё год. В этот год войдут ежемесячные релизы с исправлениями ошибок и частью других обновлений.
Полный состав обещания в источнике обрезан, поэтому проверяйте его по первоисточнику.
После этого срока развитие продолжится в другой технологии.
Команда выбирает рантайм, потому что он быстрее, безопаснее или удобнее.
Через два года на нём работают десятки сервисов, а вендор принимает стратегическое решение, в котором эти сервисы не участвовали.
Платить за него приходится руководителю, у которого есть дедлайн и бюджет.
Миграция рантайма не даёт ни новых функций, ни роста выручки и занимает инженеров, которые могли бы делать продукт.
Стоимость выхода надо оценивать в момент выбора технологии.
Уиллисон разбирает похожий случай на примере EmbeddingGemma 2, которая выходит под лицензией Apache 2.0.
Его рассуждение строится на механике.
Приложение с embedding-моделью считает тысячи или миллионы векторов и хранит их для последующего сравнения.
Векторы одной модели нельзя сравнивать с векторами другой, поэтому смена модели означает пересчёт всего массива.
Если модель проприетарная и доступна только как хостинг, вендор рано или поздно её снимет, потому что у него появится модель получше.
Пересчёт всех сохранённых данных вам придётся оплатить заново. С открытой моделью старую версию можно держать у себя столько, сколько нужно.
Отсюда правило для бизнеса: если вокруг системы вырастает хранилище, привязанное к конкретной модели, лицензия модели входит в архитектуру наравне с базой данных.
Риск снимают слоями архитектуры, и выбор «правильного» вендора здесь ничего не гарантирует. - Шлюз перед моделями.
Приложения обращаются к LLM через единый шлюз.
Смена провайдера или модели меняет конфигурацию шлюза, а код сервисов остаётся прежним.
Так устроен наш LLM & Security Gateway: он же ведёт учёт запросов и фильтрует чувствительные данные. - Версия модели рядом с вектором. В RAG-системе каждый вектор хранится с идентификатором модели и версии.
Пересчёт тогда запускается порциями в фоне, и поиск не останавливается. - Интеграции через стандартные протоколы.
Инструменты для агентов публикуются через MCP, обмен между системами идёт через Apache Kafka.
Рантайм сервиса (Node.js, Python или C#) можно заменить без пересмотра контрактов. - Открытые веса для больших массивов данных.
Для больших массивов эмбеддингов открытая модель с понятной лицензией (Qwen, Llama, Gemma) обходится дешевле, чем зависимость от хостинга, который могут закрыть.
Такая архитектура выглядит скучно, и цель у неё конкретная: если через год вендора купят или поднимут цену, переезд должен стоить недели работы одной команды, а квартал работы нескольких команд мы в этот расчёт не допускаем.
Инженеры часто меряют технологию скоростью старта.
Мы считаем время до результата, и у него есть вторая половина: сколько времени займёт выход, когда технология перестанет подходить. Рантайм, на котором сервис собрали за неделю, но который требует полугода миграции при смене владельца, дороже рантайма, на котором сервис собрали за две недели и который меняется за выходные. Я не утверждаю, что Deno был плохим выбором.
Для многих команд он остаётся рабочим весь обещанный год.
Но тем, кто строил на нём долгоживущие системы, нужен план на второй год.
Когда вы выбираете рантайм или модель, попросите команду письменно ответить на один вопрос: что мы делаем, если вендор завтра объявит о продаже или закрытии? Если ответ укладывается в одну страницу с цифрами по срокам и стоимости, зависимость управляема. Если ответ звучит как «будем думать», вы арендуете свой продукт у чужой компании на условиях, которых не читали.
