Hacker News Digest

Netlify перестроила инфраструктуру Edge Functions, заменив V8 изоляты на Firecracker MicroVMы в сотрудничестве с Unikraft, что ускорило среднее время выполнения с 25–40 мс до 5–6 мс — почти в 5 раз. Теплые вызовы теперь занимают ~5–6 мс (p50), а p99 стал на 47,4% быстрее, при этом доступность достигла 99,998%, а доставка логов ускорилась в 5 раз. Холодные старты происходят в 1,2% случаев и занимают в среднем 9 мс, так как требуют загрузки образа VM перед выполнением.

Запрос проходит через ближайший edge-узел, где проверяется маршрут Edge Function; при совпадении запрос направляется внутрь собственной сети Netlify на выделенный compute-узел, где запускается либо уже существующая, либо новая MicroVM с файловой системой и полным Linux-окружением. Управление флотом узлов осуществляется через контрольную плоскость, которая обеспечивает обновления без простоев: новый флот выводится рядом со старым, проверяется на здоровье и постепенно принимает трафик. Эта архитектура сохраняет полную обратную совместимость — импорты через URL, npm-пакеты, Node.js built-ins, netlify.toml и локальная разработка работают без изменений — но открывает путь к снятию прежних ограничений: поддержка npm-пакетов выходит из бета, пересматриваются лимиты на CPU (50 мс), память (512 МБ) и размер кода (20 МБ), а также появляется возможность выполнять сложные вычисления, требующие контроля над сетевым путем, без выхода в публичный интернет.

Ускорение Netlify с 25–40 мс до 5–6 мс связано с переносом вычислений из внешней хостинговой инфраструктуры в собственную сеть, а не с самой технологией выполнения. Firecracker используется для изоляции и безопасности, но не заменяет Docker — запуск полной ОС в VM считается избыточным для многих задач из-за большего rootfs и зависимости от KVM. V8 изоляты не считаются надёжной изоляцией в эпоху ИИ — Chrome сам им не доверяет, поэтому требуются дополнительные слои безопасности. Firecracker — технология AWS, её использование Netlify подтверждает универсальность, но AWS Lambda остаётся медленнее из-за enterprise-слоёв, а не микровиртуализации. Холодные старты в 1,2% случаев и p50 ~5–6 мс у Netlify значительно лучше, чем у AWS Lambda (задержки до 1500 мс), несмотря на общую технологию. Спор: Cloudflare Workers быстрее, потому что их исполнение всегда внутри сети, а у Netlify ранее — нет. Создание снапшотов MicroVM после загрузки JS-сервера может вызывать проблемы с RNG и криптографией, но Firecracker имеет решения. AOT-компиляция может улучшить производительность, но не распространена в serverless-экосистеме. Fetchable API в Netlify Edge Functions не реализована, несмотря на наличие эксперта в компании. Netlify использует unikernels на базе Firecracker (через Unikraft) для минимизации образа и ускорения загрузки. Firecracker + Unikraft могут быть оптимальны для запуска ненадёжного кода на AWS — обсуждается как потенциальное решение. Firecracker для Edge Functions не заменяет контейнеры — это разные инструменты: VM для изоляции, контейнеры для эффективности, их можно комбинировать (например, Kata). Netlify перешёл от внешнего хостинга к собственной инфраструктуре — это дало прирост скорости; Firecracker обеспечил безопасность и контроль.

DeepSeek Elastic Compute (DSec) — это масштабируемая песочница для обучения агентных систем, объединяющая несколько уровней изоляции (FnCall, контейнеры, microVM, полные VM) через единый SDK. Платформа управляет размещением и жизненным циклом песочниц в кластере, используя независимо версионированные слои для быстрой сборки окружений. Для высокой плотности выполнения DSec комбинирует совместное использование памяти, её реклейм и гибкое CPU-планирование, а образцы данных загружаются по требованию из распределённой файловой системы Fire-Flyer File System (3FS).

DSec спроектирован совместно с фреймворком обучения с подкреплением, разделяя выполнение состоятельных роллаутов и прерываемое обучение на GPU. Это позволяет сохранять состояние агентов во время роллаутов, даже когда простаивающие ресурсы reclaimются для обучения. Платформа также активно противодействует нежелательному поведению агентов, такому как reward hacking, через контроль среды и изоляцию. В production один юнит DSec охватывает ~160 узлов, обслуживая около 3 миллионов песочниц в день, поддерживая более 380 тысяч одновременных песочниц и выдерживая более 5 тысяч созданий песочниц в секунду. Эти механизмы снижают накладные расходы на инициализацию окружений и распространение образов, повышают эффективность использования памяти и сохраняют низкую латентность даже при высокой степени переcommit ресурсов.

DSec заявляет о 380 000 одновременно работающих песочниц на 160 серверах с EPYC, что соответствует примерно 12 песочниц на ядро — подтверждая чрезвычайно высокую плотность вычислений. Длинный список авторов в статье обусловлен ограничением интерфейса arXiv; полный список доступен в PDF, это не скрытая стратегия. Платформа сравнивается с Google Ax как scheduler над Firecracker и микровиртуальными машинами. По мере роста возможностей моделей безопасные и изолированные среды становятся критически важными для предотвращения выхода ИИ за пределы песочницы. Нагрузка на песочницы сильно варьируется: многие простаивают, что усложняет предсказание ресурсных потребностей при большом количестве песочниц. Некоторые комментаторы рассматривают длинный список авторов как защиту талантов, другие — как обычную практику в крупном экспериментальном исследовании. Поднимается вопрос, что узким местом для масштабных агентных ройов будет не количество песочниц, а пропускная способность инференса. Упомянутые объёмы — петабайты слоёв, ~250 TB RAM, 3 млн запусков песочниц в день — указывают на модель, близкую к serverless, для обучения и RL‐агентов.

Docker Sandboxes — это набор изолированных микровМ, позволяющих запускать AI‑агенты (Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, Kiro и др.) в безопасном окружении без риска для хост‑системы. Каждый агент работает в отдельном микровМ, где доступны только его рабочая папка и необходимые зависимости; при этом сеть и файловая система ограничены правилами, задаваемыми пользователем. Это дает возможность агентам самостоятельно устанавливать пакеты, модифицировать конфиги и даже поднимать свои Docker‑контейнеры, сохраняя при этом чистоту хоста.

Ключевые преимущества: микровМ‑изоляция обеспечивает жёсткую границу безопасности, а «YOLO‑режим» (--dangerously-skip-permissions) позволяет агентам действовать без подтверждений, но при этом остаётся защита за счёт контейнеризации. Sandboxes легко разворачивать и уничтожать, они быстрее VM и не требуют Docker Desktop. Организации могут централизованно управлять политиками доступа через Docker AI Governance, а разработчики получают готовое решение для безопасного использования автономных агентов в реальном времени.

Docker Sandboxes не использует контейнеры, а применяет собственные microVM с гипервизором на каждом хосте, что обеспечивает более сильную изоляцию, чем Docker, но вызывает критику за закрытость, требование входа и отсутствие поддержки Linux.

• Использование microVM вместо контейнеров обеспечивает более надежную изоляцию, так как каждый агент работает в отдельном ядре с гипервизором (Hypervisor.framework, WHP, KVM), а не в общем ядре хоста.

• Спор: Некоторые пользователи считают, что Docker Sandboxes — это избыточное решение, так как аналогичную изоляцию можно достичь с помощью Incus/LXD, Bubblewrap или собственных Docker-образов, а требование входа снижает ценность.

• Совет: Для Linux-пользователей рекомендуется использовать Incus/LXD или Podman с Bubblewrap, так как Docker Sandboxes пока не поддерживает Linux, несмотря на наличие запросов и открытых issue.

• Открытые альтернативы, такие как Locki, VibePod, Gondolin и earendil-works, предлагают схожую функциональность без требований входа и с поддержкой git worktrees, что делает их привлекательными для разработчиков.

• Совет: Для iOS-разработчиков текущие sandbox-решения не поддерживают полноценный dev loop, что вынуждает запускать AI-агенты напрямую на машине, нарушая принципы изоляции.

• Docker Sandboxes предлагает удобный контроль над сетевым доступом и внедрением секретов через плейсхолдеры, что делает его привлекательным для ежедневного использования, несмотря на закрытость.

• Спор: Некоторые пользователи отмечают, что ограничения в настройке volume mounts в Docker Sandboxes делают его непригодным для сложных сценариев, где требуется доступ к нескольким директориям одновременно.

• Совет: Для обеспечения безопасности при работе с AI-агентами рекомендуется использовать изоляцию на уровне Kubernetes с разграничением прав: только чтение, создание PR, и полный доступ с ручным одобрением.

• Использование WASM-исполняемых сред (например, uutils, VMware-backed Python) для ограничения доступа к системным вызовам — перспективный путь для создания безопасных сред без полной виртуализации.

• Совет: Пользователи с macOS рекомендуют Tart или Apple Virtualization Framework как более гибкие и контролируемые альтернативы Docker Sandboxes, особенно для долгосрочного хранения состояния и установки пакетов.

• Docker Sandboxes не решает проблему полного доверия к агентам — если агенту разрешено обращаться к GitHub или внешним API, он может обойти изоляцию, что требует дополнительной политики разрешений.

• Спор: Критики утверждают, что требование входа для локальных sandbox-сессий — это маркетинговый трюк, снижающий доверие и повышающий риск rug pull, особенно при отсутствии открытого исходного кода.

• Совет: Для предотвращения проблем с правами на файлы, создаваемые агентами, рекомендуется запускать microVM без root-доступа и использовать привязку к пользовательским UID/GID на хосте.

• Изоляция на уровне ОС (systemd namespaces, cgroups) недостаточна для защиты от злонамеренных AI-агентов, так как они не являются традиционными вредоносными процессами, а действуют в рамках разрешенных команд.

• Совет: Использование AI-агентов через графические интерфейсы (например, Claude Desktop в VM с GUI) вместо CLI может снизить риски, связанные с прямым доступом к оболочке и системным вызовам.

I work at Docker. Lot of valid and useful feedback here that we're looking closely at.One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more… — @srini-docker