DevZero робить ставку на checkpoint-restore для оптимізації K8s без перезапусків
Уявіть планування ємності Kubernetes як дублінський паб у п'ятницю ввечері: власник завжди тримає забагато бочок, бо одна порожня бочка обходиться дорожче, ніж нерозпродане пиво. Саме так більшість платформних команд провізіонує кластери. DevZero щойно представив інструмент, який нібито може тихо переставляти бочки під час виступу гурту — не зупиняючи роботу.
Що сталося
У четвер, як повідомив IT Brief UK, сіетлська компанія DevZero запустила автономну платформу оптимізації інфраструктури для Kubernetes-навантажень, яка перерозподіляє ресурси в реальному часі без перезапусків. Суть проста: припинити надмірне провізіонування, не платити за простій і не перезапускати поди для цього.
Компанію заснували у 2022 році колишні інженери Uber Дебо Рей та Роб Флетчер — спочатку як хмарну платформу розробки для підвищення продуктивності програмних інженерів. Засновники самі запускали цей сервіс на Kubernetes, стикнулися з тими самими неефективностями, що й усі інші, і побудували інструменти для їх вирішення. Тепер ці інструменти стали основним продуктом.
Це ставить DevZero у пряму конкуренцію з Cast.ai та ScaleOps — двома назвами, які більшість платформних лідів уже мають у своєму списку постачальників, коли CFO починає ставити незручні запитання про витрати на EC2. Відмінність, на яку робить ставку DevZero, — технологія checkpoint-restore, яка, за їхніми словами, забезпечує живу міграцію навантажень під час змін попиту або збоїв інфраструктури.
Серед клієнтів, яких вони публічно згадують, — DataBahn, Dentira, Starburst, OpenObserve та Outerbounds: помітно AI- та data-platform-орієнтований список. Інвестори — Anthos Capital, Foundation Capital та Madrona.
DevZero стверджує, що середній клієнт витрачав на 53% більше за обчислення до впровадження платформи, а користувачі зазвичай скорочують рахунки за обчислення на 30–60%. Компанія сама зазначає, що ці цифри не були незалежно перевірені — і це хоча б чесно. Чому вони вважають, що ринок готовий: опитування Cloud Native Computing Foundation показало, що 66% організацій, які розміщують генеративні AI-моделі, використовують Kubernetes для управління частиною або всіма інференс-навантаженнями, а дослідження Datadog показало, що 83% витрат на контейнери йде на неактивні ресурси, з яких 54% — на надмірно провізіоновану кластерну інфраструктуру.
Технічна анатомія
Цікавість становить механізм, а не дашборд. DevZero працює на рівні кластера, вузла та навантаження, профілює попит на ресурси та коригує виділення CPU, пам'яті й GPU в міру зміни використання. Це базовий функціонал. Cast.ai та ScaleOps роблять щось подібне. Нудна частина однакова у всіх постачальників: збір метрик, моделювання попиту, вибір типів інстансів, планування.
Цікавіше там, де з'являється checkpoint-restore. Кожен, хто намагався вертикально масштабувати stateful-под у ванільному Kubernetes, знає цей танець: вбудована зміна ресурсів у місці все ще дозріває, VerticalPodAutoscaler історично хотів виселити под, а "виселити под" інженерською мовою означає "перезапустити навантаження і молитись, що пул з'єднань відновиться". Checkpoint-restore (та сама родина технологій, що й CRIU, навколо якої проекти CNCF ходять роками) робить знімок стану запущеного процесу і відновлює його деінде. Без холодного старту. Без податку на прогрів JVM. Без втрати кешу в пам'яті.
Це важливо у двох конкретних випадках. По-перше, AI-інференс. Велика модель, завантажена в GPU-пам'ять, коштує дорого при виселенні. Якщо можна перенести її в режимі реального часу на вузол з правильно підібраним GPU, ви уникаєте як затримки холодного старту, так і спокуси надмірно провізіонувати GPU-ємність "на всякий випадок". По-друге, збій зони доступності. Міхір Наїр, керівник архітектури DataBahn, сказав: "Під час нещодавнього збою зони доступності DevZero прозоро перенесло наші навантаження в режимі реального часу без жодного перезапуску чи оперативного втручання з боку нашої команди."
Платформа також працює на AWS, Azure, GCP, OCI та OpenShift, і DevZero стверджує, що аналізує понад 3 000 типів інстансів, 69 000 цінових точок, 23 моделі GPU та понад 80 регіонів для вибору оптимального розміщення. Комбінаторний простір хмарних SKU роками є прихованою катастрофою для платформних команд, і делегування цього рішення солверу — чесно кажучи, єдиний розумний крок на цьому етапі. Складніше інженерне питання — чи витримує заявлена жива міграція по-справжньому складні навантаження: з TCP-сесіями, GPU-буферами з відображенням пам'яті, залежностями від модулів ядра. Маркетинг каже "так". Пейджер о 3 ночі розставить усе по місцях.
Хто постраждає
Cast.ai та ScaleOps — очевидні гравці, яких зачепить цей запуск. Обидва побудували сильні наративи навколо оптимізації витрат на K8s, і тепер обом доведеться пояснювати, чому їхній шлях до rightsizing — який зазвичай передбачає заміну подів — прийнятний для AI-інференсу та довгоживучих stateful-сервісів. Очікуйте сторінок із функціями, де згадується checkpoint-restore, впродовж кварталу. Так рухається цей ринок.
Більша група, яка постраждає, — це мовчазна більшість платформних команд, які провели останні два роки, пишучи внутрішні Confluence-сторінки під назвою "Kubernetes Cost Optimisation Roadmap" з нульовим прогресом. Їхній CFO вже прочитав статистику Datadog про те, що 83% витрат на контейнери йде на неактивні ресурси. Термін дії відповіді "ми вивчаємо Karpenter та налаштування HPA" швидко спливає.
AI-інференс-спільнота знаходиться під загрозою інакше. Якщо ви запускаєте LLM-інференс на зарезервованій GPU-ємності, розрахованій на пікове навантаження, ваша юніт-економіка тихо жахлива. Цифра 66% Kubernetes для інференсу з опитування CNCF говорить про те, що субстрат достатньо стандартизований, щоб такі постачальники, як DevZero, могли цілитися в нього безпосередньо. Команди, які побудували власні інференс-стеки на чистому EC2, незабаром виявлять, що їхня cost-story гірша, ніж у K8s-native-шопів, над якими вони раніше сміялися.
Нарешті, хмарні провайдери отримують невеликий укус. Кожен долар, який платформа оптимізації заощаджує клієнту, — це долар, знятий з рахунку AWS, Azure або GCP. Гіперскейлери терплять це, бо альтернатива (відхід клієнтів) гірша, але зверніть увагу: їхній власний нативний інструментарій (Compute Optimizer, Azure Advisor) зручно зупиняється на порозі агресивного живого rightsizing. Дивно, правда.
Дорожня карта для інженерних команд
Якщо ви керуєте платформою Kubernetes, ось три речі, які варто зробити цього тижня. По-перше, реально виміряйте свій коефіцієнт простою. Порівняйте запити CPU та пам'яті контейнерів з фактичним використанням за 14-денний період. Якщо ви наближаєтесь до тих 83% простою, у вас є cost-story на рівні ради директорів, подобається вам це чи ні. Метрики OpenTelemetry, передані в те, що ви вже використовуєте, достатні; вам не потрібен новий постачальник, щоб дізнатися, що є проблема.
По-друге, відокремте навантаження, які можуть терпіти виселення, від тих, які не можуть. Stateless HTTP-сервіси: нормально, HPA та VPA впораються з більшою частиною роботи. Stateful-сервіси, довгоживучі gRPC-потоки, GPU-завантажені інференс-поди, будь-що зі значним часом прогріву — це ті навантаження, де checkpoint-restore по-справжньому виправдовує себе. Знання вашого розподілу дозволяє об'єктивно оцінювати DevZero, Cast.ai, ScaleOps або власне рішення.
По-третє, проведіть пілот на одному некритичному кластері, перш ніж вірити будь-якій цифрі від 30 до 60% економії. Сам DevZero зазначає, що ці цифри не були незалежно перевірені, а ваш mix навантажень не є середньостатистичним. Проведіть чотиритижневий тест із реальним виробничим трафіком. Вимірюйте не лише різницю у вартості, але й p99-затримку, кількість перезапусків та оперативні втручання. Власне формулювання Рея було "автономна оптимізація, якій можна довіряти о 3 ночі". Перевірте це о 3 ночі. У неділю. Зі синтетичним збоєм зони доступності. Якщо витримає — у вас є щось цінне. Якщо ні — у вас дуже дорогий дашборд.
Ключові висновки
- Запуск DevZero ставить checkpoint-restore в центр K8s FinOps-дискусії, змушуючи Cast.ai та ScaleOps відповідати на питання про живу міграцію.
- Цифра 83% витрат на контейнери для неактивних ресурсів від Datadog плюс 66% GenAI-інференсу на K8s означає, що rightsizing тепер видима для CFO стаття витрат, а не хобі платформної команди.
- AI-інференс та stateful-навантаження — це те місце, де евікшн-автоскейлери дають збій, і де жива міграція змінює економіку.
- Заявлена DevZero економія в 30–60% надана компанією і не перевірена; сприймайте її як гіпотезу для тестування, а не цифру для дошки директорів.
- Повертаючись до пабу: власник, який може переставляти бочки під час роботи, не пролив ні краплі, виграє. Усі інші продовжують надмірно закуповуватись. На це й робить ставку DevZero, і це розумна ставка.
Часті запитання
Q: Що таке checkpoint-restore і чому це важливо для rightsizing у Kubernetes?
Checkpoint-restore робить знімок стану запущеного процесу (пам'ять, відкриті файли, мережеві сокети там, де підтримується) і відновлює його деінде без холодного старту. Для Kubernetes це означає, що ви можете перенести под на менший або інакше розташований вузол без перезапуску — що критично для AI-інференс-навантажень та довгоживучих stateful-сервісів, де перезапуски коштують реальних грошей і затримок.
Q: Як DevZero порівнюється з Cast.ai та ScaleOps?
Усі три орієнтовані на оптимізацію витрат Kubernetes через rightsizing, автоскейлінг та вибір інстансів. Відмінність DevZero — використання checkpoint-restore для живої міграції навантажень під час змін попиту або збоїв, що, за їхніми словами, дозволяє виконувати rightsizing без евікшну подів, якого зазвичай вимагають конкуруючі підходи. Чи справджується це для складних виробничих навантажень — кожна команда має перевірити в пілоті.
Q: Чи достовірна заявлена DevZero економія на обчисленнях у 30–60%?
Вона правдоподібна з огляду на дослідження Datadog про те, що 83% витрат на контейнери йде на неактивні ресурси і 54% — на надмірно провізіоновані кластери, але сам DevZero зазначає, що цифри надані компанією і не перевірені незалежно. Ваша фактична економія суттєво залежить від mix навантажень, поточної дисципліни провізіонування та того, наскільки агресивно ви готові дозволити автономному інструментарію змінювати розміри виробництва.
Datadog відмовляється від SaaS-моделі: BYOC та федеративні логи
Datadog цього тижня відмовився від суворої SaaS-позиції: BYOC, федеративні логи для Snowflake, Databricks і ClickHouse, а також нова консоль витрат AI-агентів.
PeopleSoft 0-Day Спустошує Університети, поки ShinyHunters Збирає Врожай
SSRF-вразливість із рівнем критичності 9.8 в Oracle PeopleSoft дала ShinyHunters два тижні непоміченого доступу, 300 точок входу та 48 ГБ даних з однієї жертви. Найбільше постраждали університети.
Quantova випускає документацію для пост-квантового L1, поки відлік до Q-Day триває
Quantova опублікувала повну документацію для розробників і розширила GitHub для пост-квантового Layer-1 на основі Dilithium, Falcon і SPHINCS+ від NIST. Ось що це означає.




