Hacker News Digest

Deno команда присоединяется к Cloudflare, чтобы продолжить работу над упрощением создания серверного ПО. Их цель — объединить вычисления, хранение и связь в единую модель, где приложения не собирают инфраструктуру сами. Это логичное продолжение пути от Deno через Deno Deploy к celld — платформе, построенной на Cloudflare Workers и Durable Objects, где масштабирование заложено в саму модель программирования, а не в инфраструктуру каждого приложения. Команда видит в этом способ сделать такую модель стандартной для серверной разработки, независимо от того, где запущено приложение.

В рамках перехода Deno runtime получит поддержку с исправлениями и обновлениями безопасности ещё год, после чего разработка прекратится, но код останется открытым. Deno Deploy будет работать шесть месяцев с поддержкой миграции на Cloudflare Workers для платных клиентов. JSR продолжит работу, перенеся свою инфраструктуру на Cloudflare, а rusty_v8 будет интегрирован в workerd. Команда особенно заинтересована в применении Durable Objects для ИИ-агентов благодаря их дешёвому serverless-исполнению, постоянному состоянию, WebSockets и высокоуровневому JS-интерфейсу. Kenton Varda и Райан Дал подробно описывают это в совместном посте в блоге Cloudflare.

Сообщество воспринимает поглощение Deno Cloudflare как конец официальной поддержки рантайма, выражая разочарование из‐за утраты уникальных возможностей: безопасности и импорта модулей по URL. Большинство считают это «закрытием» проекта, несмотря на открытый код, и обеспокоены прекращением поддержки через год. Однако открытый исходный код даёт шанс сообществу продолжить развитие, а Cloudflare может интегрировать лучшие идеи Deno в Workers и получить талантливую команду. Ключевые преимущества Deno — простота импорта модулей напрямую из репозиториев и строгая безопасность — делают его уникальным для скриптов и sandbox‐окружений, и их потеря в Node и Bun отмечается как существенный недостаток. Некоторые советуют сообществу взять на себя развитие Deno после ухода Cloudflare. Пользователь @steve_adams_86 рекомендует перенести механизмы безопасности Deno в workerd для улучшения sandbox‐а. @johnbellone планирует продолжать использовать Deno как встроенный рантайм и надеется на сообще‐форк. @sholladay считает, что Deno стал «раздутым» после добавления совместимости с npm, что оттолкнуло их от проекта. О бизнес‐модели Deno многие считают, что отсутствие монетизации (платные планы, донаты) и зависимость от венчурных инвестиций сделали проект уязвимым к поглощению. Приобретение Cloudflare рассматривается как часть более широкой тенденции консолидации инструментов разработки (Bun, Astro, Vite и др.) под крупные облачные компании. @jppope отмечает, что Cloudflare получит талантливую команду, что может улучшить безопасность и стандартную библиотеку Workers.

Cloudflare K2 — это серверless-примитив для потоковой передачи событий, построенный на Developer Platform и использующий R2 как основу для долговечного, партицированного лога. Он решает проблему синхронизации производителей и потребителей в традиционных RPC-архитектурах, где несогласованность масштаба или времени приводит к потере данных. K2 буферизует события, позволяя потребителям читать их независимо и в своём темпе — будь то разделение нагрузки между несколькими воркерами или доставка всех сообщений каждому потребителю (паттерн pub/sub). Поддерживается долгосрочное хранение, так что даже длительные простои потребителей не приводят к потере данных. Поток хранит события как упорядоченный лог, сегменты которого записываются в R2 после накопления в памяти, что обходит ограничение объектного хранилища на дозапись. Архитектура разделяет вычисления и хранение, позволяя масштабировать их независимо и использовать глобальную инфраструктуру Cloudflare — близкую к пользователям и способную к горизонтальному масштабированию — несмотря на эфемерность edge-серверов и ограничения традиционных распределённых систем вроде Kafka.

K2 доступен в публичной бета-версии для аккаунтов с оплаченной подпиской Workers, с ограничениями: до 10 ГБ хранилища и 30 МБ/с производительности на поток. Во время бета-тестирования использование не тарифицируется; ожидаемая модель ценообразования после выхода: $0.04/ГБ заproduced и consumed данные, $0.02/ГБ/месяц за хранение. Планируется расширение возможностей: повышение параллелизма записи до multi-GB/s, поддержка ключевой упорядоченности, push-потребители, экспресс-уровень с низкой латентностью и совместимость с клиентами Apache Kafka. Начало работы — создание потока за секунды по официальному гайду. Обратная связь принимается в Discord Cloudflare Developers.

K2 решает проблему масштабируемости потоков событий через объектное хранилище, но имеет ограничения: задержки доставки до 7.5 с, высокая стоимость потребления данных ($0.04/GB) и отсутствие совместимости с Kafka, что снижает его применимость для низколатентных сценариев и создает барьер для миграции из Kafka-систем. Объектные хранилища (R2, S3) становятся основой для систем хранения данных, заменяя управляемые дисковые системы благодаря надежности, масштабируемости и простоте. K2 и аналогичные решения (AutoMQ, WarpStream) используют S3/R2 как основу, при этом Cloudflare имеет преимущество за счет тесной интеграции R2 и K2 в одной команде. Высокая задержка объектных хранилищ (до 7.5 с) противоречит возможностям NVMe SSD с микросекундной задержкой, делая такой подход неоптимальным для некоторых сценариев. Потребление данных по $0.04/GB делает сценарии с множеством потребителей дорогостоящими по сравнению с конкурентами, где потребление часто бесплатное или дешевле. S3 и R2 позволяют строить сложные системы (регистры контейнеров, etcd, POSIX-файловые системы) через тонкий слой, расширяя применение за пределы простого хранения. AWS Aurora и другие системы давно используют S3 как основу хранения, подтверждая устойчивость тренда «object-store first». Наличие встроенной поддержки многорегионального распределения и отказоустойчивости в R2 делает K2 привлекательным для глобальных приложений, где управление традиционными Kafka-кластерами сложно. Для улучшения производительности предлагается добавить быстрый in-memory прокси-слой с тем же API, чтобы сделать объектное хранилище приемлемым для обычных бизнес-приложений. Также предложено заменить ack-батчи на передачу ID последнего прочитанного события в запросе consume — это снизит сложность и риск дублирования. Для не-AI стартапов рекомендуется фокусироваться на read-heavy сценариях с большим объемом данных, как это сделал Turbopuffer — эффективный путь к созданию ценности на базе объектного хранилища. Azure Blob Storage поддерживает операции append с самого начала, опровергая утверждение о том, что S3 — единственный или лучший вариант для потоковой записи. Cloudflare активно выпускает новые продукты с малым количеством персонала, вызывая опасения по поводу безопасности и долгосрочной надежности инфраструктуры клиентов. K2 отличается от очередей Cloudflare тем, что обеспечивает долговечный, партиционированный лог событий, а не просто надежную доставку с повторными попытками. NATS JetStream рассматривается как недооцененный альтернативный вариант, способный обеспечить высокую пропускную способность для средних предприятий при правильной настройке.

Fireworks Research представила Ember-1 — специализированную модель, построенную на базе Kimi K3, которая сохраняет её качество, но использует на 40% меньше токенов. Это достигнуто не простым снижением уровня рассуждений, а обучением модели более эффективному мышлению: она научилась отсекать избыточные внутренние размышления, сохраняя при этом полезное саморефлексирование и адаптацию к обратной связи. Разработчики провели более 50 экспериментов и 200 оценок, создав новые алгоритмы обучения на Fireworks Serverless Training, что позволило быстро перейти от идеи к выпуску без управления инфраструктурой.

Ember-1 прошла тестирование на внешних бенчмарках, в live A/B-тестах с клиентами и во внутренних рабочих нагрузках Fireworks — включая программирование и агентные задачи. Внутреннее использование показало, что разработчики не заметили подмены модели, несмотря на значительное снижение расхода токенов — что подтверждает её ключевое преимущество: те же ответы, но вдвое дешевле по токенам. Модель уже доступна в качестве Research Preview на Serverless, а Fireworks планирует выпустить серию подобных специализированных моделей Ember, а также предоставить инструменты для дообучения Ember-1 под конкретные задачи企业, чтобы токеновая эффективность стала стандартом.

Обсуждение дополняет статью, выявляя противоречие между эффективностью Ember-1 и закрытостью Fireworks. Пользователи (@tukHelix, @nxtfari, @intothemild, @ed_mercer) критикуют компанию за модификацию открытых весов Kimi K3 без публикации результата, что подрывает доверие к их бизнес-модели и этике open source. Экономическая целесообразность Ember-1 ставится под сомнение: @soerxpso отмечает, что при сокращении использования токенов на 40% цена за токен выросла вдвое по сравнению с Kimi K3. Также @netvarun и @soerxpso указывают, что Sol предлагает лучшее качество при значительно меньшей стоимости. @sailfast предполагает, что модель может быть лишь рекламой инфраструктуры Fireworks. Для анализа и улучшения предлагается: — опубликовать Ember-1 на unbenchmark.com для независимой валидации (@gitghxst); — уточнить, не пострадали ли специфические навыки (например, Golang) при сокращении токенов (@tomrod); — оценить качество в креативном письме (@tdhz77); — использовать синтетические трассы мышления в стиле «caveman-speak» для масштабирования подхода (@spdustin). @qeternity напоминает, что в агентных сценариях основная стоимость приходится на prefill, а не на decode, поэтому оптимизация последних может быть малоэффективной. @GodelNumbering, @Arcuru, @erichocean и @ls612 отмечают, что обучение локальных моделей на синтетических данных с использованием баз Qwen, K3 или DeepSeek стало доступным, что делает метод Ember-1 универсальным. Сотрудник Fireworks @madisonkanna подтвердил работу над моделью, но не раскрыл деталей, что усилило подозрения в закрытости компании.

Инженеры Nanit сэкономили $500,000 в год, создав собственную систему хранения N3 на Rust вместо использования AWS S3 для обработки видео. При тысячах загрузок в секунду, плата за запросы PutObject в S3 становилась основной статьей расходов, а минимальный период хранения в 24 часа правил out стоимость обработки, занимавшей всего 2 секунды.

N3 работает как in-memory landing zone, используя S3 только как буфер перегрузки. В исходной архитектуре камеры загружали видео чанками напрямую в S3 через presigned URL, после чего Lambda отправлял ключи в SQS FIFO очередь для обработки. Подход сохранил надёжность и строгую последовательность данных, но исключил плату за запросы на основном пути и сократил затраты на хранение.

• Стоимость S3 для короткоживущих файлов оказалась настолько высокой, что компания вместо него реализовала собственное in-memory хранилище, что позволило сэкономить $500k, но оставляет вопрос о том, что будет, если этот кэш упадёт.
• Обсуждение вылилось в критику концепции "serverless" архитектуры, где-то между линиями прочиталось, что сама архитектура была проблемой, а не решением.
• Участники обсуждения также подняли вопросы о приватности: камера в детской комнате передаёт аудио/видео в облако без шифрования, и кто-то может прослушивать ваш дом.
• Несколько комментаторов отметили, что вместо того, чтобы писать собственные сервисы, компании могли бы использовать существующие open-source решения, такие как MinIO или SeaweedFS, но при этом они также отметили, что даже эти решения не предоставляют той же степени удобства, что и делает S3.

Сборник коротких серверлес-кошмаров

• $1189 – Webflow снял за месяц вместо $69.
• $100 000 – DoS на игровом сайте → счёт за Firebase за сутки.
• $738 – Vercel Pro + лимит $120 ≠ защита от «сюрприза».
• $70 000 – Проснулся с таким счётом за Firebase при тарифе $50.
• $22 640 – BigQuery на публичных данных.
• $250/мес – 9 тыс. просмотров в Framer.
• $1274 – AI Devin случайно устроил ддос в PostHog.
• $530 – Платный PostHog после нулевого периода.
• $384 – Документация на Mintlify.
• $103 – AWS Free Tier ловушка.
• $96 281 – Vercel: «я просто молчу».
• $120 000 – Cloudflare выключает сайт, требуя деньги за сутки.
• $1301 – Пустой приватный S3 + ддос.
• $11 000 – Mailgun во время атаки.
• $104 500 – Письмо от Netlify «переплата».
• $23 000 – Спам-атака на EchoFox в Vercel.
• $3000 – Тестовый деплой в Vercel.
• $620 – Sitemap.txt сожрал трафик.
• $72 000 – Тест Firebase + Cloud Run чуть не разорил.

Хочешь поделиться своим счётом-ужасом — пиши в твиттере или PR на GitHub.

• Пользователи делятся историями о «серверлес-ужасах» — внезапных счетах за десятки и сотни тысяч долларов из-за DDoS, ошибок в конфигурации или забытого ресурса.
• Критика сосредоточена не на технологии serverless, а на модели оплаты «плати за использование» без жёстких потолков: бюджет — лишь уведомление, а не отключение.
• Многие считают, что провайдеры могли бы автоматически отключать сервис при превышении лимита, но не делают этого, теряя деньги на «ошибках» новичков.
• Участники советуют: ставить rate-limit, использовать VPS с фиксированной ценой, поднимать bare-metal или хотя бы включать billing-alerts и «пауz-лимиты» вроде Vercel.
• Поддержка AWS/GCP/Azure часто прощает счета после публичных твитов, но это выживший эффект: официальной политики нет, и никто не гарантирует прощение.

• EC2

  • Менять IAM-роли и security-groups можно без остановки инстанса.
  • EBS можно расширять, подключать и отключать «на горячую».
  • Принудительный stop/terminate без ожидания таймаута.
  • Live-migration между хостами почти убрала деградацию инстансов.
  • Надёжность выросла: «исчезновение» инстансов стало редкостью.
  • Spot-рынок стал стабильнее, без аукционов.
  • Dedicated Instances почти не нужны — даже для HIPAA.
  • AMI Block Public Access включён по умолчанию.

• S3

  • Стал строго согласованным (read-after-write).
  • Не нужно рандомить префиксы ключей для равномерного распределения.
  • ACL устарели и отключены по умолчанию.
  • Block Public Access включён на новых бакетах.
  • Шифрование покоя включено по умолчанию.

• AWS теперь по умолчанию блокирует публичный доступ к новым S3-бакетам; это снижает утечки, но усложняет легитимное открытие доступа.
• Пользователи обсуждают, что многие «улучшения» AWS — это просто исправление первоначально неудобных решений, и это влияет на репутацию.
• По-прежнему спорны детали: нужно ли случайное префиксирование ключей S3, почему NAT Gateway взимается за трафик внутри одного региона и почему Transit Gateway дороже peering.
• Некоторые разработчели «деградируют» от сложных serverless-стеков к простым EC2 + S3 + Route 53 ради простоты и экономии времени на IAM.
• Участники просят ежегодные сводки изменений и жалуются на ослабление платной поддержки AWS.