Hacker News Digest

Команда Zed перешла на новую облачную инфраструктуру под названием Zed Cloud, построенную на Rust и WebAssembly через Cloudflare Workers. Это решение заменяет старый бэкенд Collab, использовавшийся с основания компании, и призвано снизить операционные затраты на обслуживание сервисов, позволив команде сосредоточиться на развитии основного продукта. Cloudflare Workers обеспечивает простое масштабирование, а такие сервисы, как Hyperdrive для Postgres, Workers KV для временного хранения и Queues для асинхронной обработки задач, обеспечивают необходимую функциональность.

В основе новой системы лежит фреймворк с трейтом Platform, позволяющий писать код независимо от платформы, сохраняя при этом доступ ко всем возможностям Cloudflare Workers. Для этого реализованы две платформы: CloudflarePlatform для работы в продакшене и локальной разработки, и SimulatedPlatform для тестирования, имитирующей практически все компоненты системы. Такой подход обеспечивает гибкость и тестируемость всей инфраструктуры Zed Cloud.

• Обсуждение в основном вращается вокруг трёх тем: использование WebAssembly в облачных сервисах, сравнение производительности и стоимости Rust vs JavaScript в Cloudflare Workers, и перспективы FOSS альтернатив.
• Участники обсуждают, что на данный момент Rust в WASM всё ещё имеет существенные накладные расходы по сравнению с нативным кодом, но при этом отмечается, что Cloudflare Workers и Supabase Edge Functions предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in.
• Также поднимается вопрос о том, что хотя WASM в браузере может и не достигает нативной скорости, он предоставляет беспрецедентную переносимость и безопасность, что делает его идеальным для серверлесс вычислений.
• Наконец, участники высказывают, что хотя Cloudflare и Supabase предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in, но всё ещё остаётся вопрос о том, какие именно преимущества предоставляет использование Rust в WASM в контексте редактора кода, если учесть, что большинство пользователей не будут замечать разницу в производительности, но при этом будут страдать от ограничений вендора.

Инженеры 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.

• Обсуждение показало, что serverless не всегда подходит для высоконагруженных API, особенно если требуется низкая латентность и стабильность.
• Участники отметили, что serverless может быть полезен для MVP или спайков, но не для высоконагруженных сервисов.
• Некоторые участники подчеркнули, что serverless может быть дороже и сложнее в управлении, чем традиционные серверы.
• Было отмечено, что serverless может быть полезен для специфических задач, таких как обработка фото или видео, но не для высоконагруженных API.
• Участники также обсудили, что выбор между serverless и традиционными серверами должен основываться на конкретных потребностях и ограничениях проекта.

Зачем и как мы сделали Vectroid

Почти все векторные БД заставляют выбирать: скорость, точность или цена. Мы решили, что жертвы не нужны, и собрали serverless-решение, где всё хорошо одновременно.

Ключевая идея:

• нагрузка скачет ⇒ ресурсы выделяем динамически;
• алгоритм HNSW жрёт память, но его можно «сплющить» квантованием и развернуть обратно при необходимости.

Что умеет Vectroid

• Поиск по HNSW: 90 % recall при 10 QPS и P99 = 34 мс (MS Marco, 138 M векторов).
• Индексация 1 M векторов в минуту, 1 B — за 48 мин.
• Записи становятся видны почти сразу после вставки.
• Масштаб до миллиардов векторов в одном пространстве.
• Пишущая и читающая части масштабируются отдельно, данные живут в GCS/S3, индексы подгружаются лениво и выгружаются при простое.

Архитектура
Два независимых микросервиса: ingest и query. Все слои (вставка, индекс, поиск) масштабируются отдельно, память экономится квантованием и покадровой выгрузкой.

Попробовать бесплатно — 100 ГБ индексов навсегда.

• Предложена идея «векторного движка» как лёгкой встраиваемой библиотеки для быстрого построения и поиска эмбеддингов, без переизобретения велосипеда в каждом продукте.
• Участники спорят о масштабируемости: 1 млрд 4096-мерных векторов теоретически невозможно держать в одной VRAM-карте (4 Т скаляров), но можно разбить на кластеры или сжать квантованием.
• Ключевой вызов — не алгоритм (HNSW/IVF), а распределённая архитектура: отдельное масштабирование записи и чтения, баланс цена-точность-латентность.
• Уже есть похожие open-source решения (USearch в ClickHouse, TurboPuffer), но новые SaaS-продукты (Vectroid и др.) обещают серверлесс, объектное хранилище и «редисо-подобный» кэш.
• Часть аудитории критикует закрытость кода и риск вендор-локина; стартапы отвечают, что opensource пока замедляет релизы, а вектора легко экспортировать.

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

• $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 часто прощает счета после публичных твитов, но это выживший эффект: официальной политики нет, и никто не гарантирует прощение.

Trystero — безсерверный WebRTC-матчмейкинг.
Добавь мультиплеер в пару строк.

Прямо сейчас все на этой странице соединяются напрямую и синхронизируют курсоры и клики.
Поддерживаются BitTorrent, Nostr, MQTT, IPFS, Supabase, Firebase.

Пример:

import {joinRoom} from 'trystero'
const room = joinRoom({appId: 'trystero-lounge'}, '101')

room.onPeerJoin(addCursor)
room.onPeerLeave(removeCursor)

const [sendMove, getMove] = room.makeAction('mouseMove')
const [sendClick, getClick] = room.makeAction('click')

window.addEventListener('mousemove', e => sendMove([e.clientX, e.clientY]))
window.addEventListener('click', () => sendClick(randomFruit()))

getMove(([x, y], id) => setCursorPosition(id, x, y))
getClick((fruit, id) => dropFruitFrom(id, fruit))

Также доступны аудио/видео-потоки и файлы.

• Демо-страница Trystero вызвала восторг: «круто», «весело», «отличный API», но подчёркнули, что это не «serverless» — просто чужие серверы для SDP-сигналинга.
• Вопросы масштабируемости: p2p-видео комнаты выше 4-8 человек требуют SFU/TURN-серверов, иначе падает кодировка и сеть.
• Safari и Firefox жалуются на лаги, зависания и DOMException при множестве PeerConnection.
• Сравнение с PeerJS: тот использует один центральный сервер, Trystero — гибкий мульти-сигналинг.
• Подняли юридические риски: в UK и штате Mississippi такой «социальный» сайт обязывает собирать ID пользователей.

• 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.

Chroma Cloud — серверлес-база поиска с открытым исходным кодом: быстро, дёшево, масштабируемо, надёжно.

Возможности

• Векторный, полнотекстовый и мета-поиск
• Форк коллекций
• Скоро: автоматическая синхронизация данных

Производительность

• Низкая латентность, высокий QPS
• Линейное масштабирование данных
• Хранение в объектном хранилище

DevEx

• Оплата по факту использования
• Веб-дашборд, CLI, локальная разработка
• Интеграция в CI/CD

Как начать

pip install chromadb
import chromadb
client = chromadb.CloudClient()
collection = client.get_or_create_collection("my_docs")
collection.add(
    documents=["Hello, world!", "Chroma is cool"],
    metadatas=[{"src": "demo"}, {"src": "demo"}],
    ids=["d1", "d2"]
)
print(collection.query(query_texts=["hello"], n_results=1))

Документация | Бесплатный старт

• Пользователи спрашивают, почему «open-source» просит деньги: ответ — сам Chroma под Apache 2.0 и бесплатен при самостоятельном развёртывании, а платная версия — это управляемый Chroma Cloud.
• Chroma поддерживает комбинированный поиск: фильтрацию по метаданным (category=X AND value>Y) + векторное сходство.
• Некоторые считают, что продукт и калькулятор цен слишком похожи на Turbopuffer; команда Chroma отвечает, что архитектуру обсуждали публично два года и уважают конкурентов.
• Для нетехнических пользователей Chroma решает задачу «R» в RAG: позволяет LLM «на лету» подтягивать нужные данные без дообучения модели.
• Стартапам предлагают помощь: совместное планирование, Slack-канал и персональная поддержка.
• Отличия от pgvector/Redis: собственные индексы (SPANN, SPFresh), шардирование, масштабирование, встроенный regex и trigram-поиск без нагрузки на основную БД.
• По сравнению с Qdrant Chroma позиционируется как «0 конфигураций и 0 операционной боли».

• Проблема цены: Heroku, контейнеры и serverless дорожают при росте проектов.
• Проблема админки: VPS дешёв, но требует обновлений и бекапов.

Решение

1. coreOS/Flatcar — минималистичная ОС, обновляется сама, ставится один раз.
2. Dokploy — open-source PaaS в контейнере: деплой из Git, БД, логи, оркестрация.
3. Итог: VPS-прайс + Heroku-удобство, независимость от облаков.

Когда не подходит: резкие пики нагрузки или совсем старт проекта — бери serverless или Heroku.

• Лицензия Dokploy вызывает вопросы; авторы обещают её переработать.
• Пользователи хвалят простоту и «Heroku-вайб», но жалуются на отсутствие удобного «pull latest», слабое управление секретами и эпизодические проблемы с деплоем.
• Часть аудитории предпочла Coolify (чуть богаче фичами) или старый добрый Dokku/Portainer.
• Для статических сайтов и CI по git-push многие используют Coolify как «домашний Netlify».
• Арм64 поддерживается; wildcard-домены и резервное копирование volume-ов приходится настраивать вручную.