Миф: serverless дешевле своего сервера

MAATRIX

«Платите только за то, что реально используете» — питч serverless звучит настолько логично, что кажется универсальным правилом: зачем держать сервер, который простаивает по ночам, если можно платить строго за вызовы функции. На практике всё сложнее: кто-то переезжает на serverless и режет счёт втрое, а кто-то получает счёт, который непредсказуемо скачет и в итоге кратно превышает аренду обычного VPS. Разберём, почему универсальной экономии тут нет, и как посчитать, что выгоднее конкретно для вашей нагрузки.

Откуда берётся миф и когда он отчасти прав

Миф не на пустом месте — у него есть честное рациональное зерно. Serverless (функции по требованию: код разворачивается платформой на лету, масштабируется от нуля до нужного числа параллельных выполнений и тарифицируется по факту вызовов и потреблённых ресурсов) действительно экономит деньги в конкретном классе задач: там, где нагрузка низкая или сильно неравномерная, а простои — это большая часть времени жизни сервиса.

Если функция обрабатывает вебхук раз в несколько минут, разбирает загруженный файл раз в час или досчитывает отчёт по ночному крону — 99% времени она вообще не должна работать. VPS в этом сценарии простаивает почти всё время и тем не менее тарифицируется по фиксированной ставке 24/7. Serverless в этом же сценарии не тарифицируется вовсе, пока функция не вызвана — вы платите за секунды реального выполнения, а не за часы простоя.

Проблема в том же месте, где мы уже разбирали похожие мифы этого цикла: рациональное зерно превращается в универсальное правило без учёта формы нагрузки. Мы уже показывали на примере Kubernetes, что технология, спроектированная под конкретный класс задач, не становится обязательной для всех проектов просто потому что она современная и о ней много говорят. С serverless та же логика: экономия — не свойство архитектуры самой по себе, а следствие совпадения формы вашей нагрузки с моделью тарификации платформы. При другой форме нагрузки та же архитектура работает в минус.

Как serverless считает деньги: не время работы, а вызовы и ресурсы

Чтобы понять, где миф ломается, нужно посмотреть, из чего вообще складывается счёт за serverless-функцию. Модель тарификации у разных платформ отличается в деталях, но принцип общий:

Цена_serverless_за_месяц ≈
    (число_вызовов × цена_за_вызов)
  + (суммарное_время_выполнения_в_GB-секундах × цена_за_GB-секунду)
  + доплата_за_исходящий_трафик
  + доплата_за_доп._сервисы_вокруг_функции (очередь, шлюз API, оркестрация)

Здесь GB-секунда — это выделенная функции память (в гигабайтах), умноженная на время её реального выполнения (в секундах). Функция с 512 МБ памяти, отработавшая 800 мс, потребляет 0.4 GB-секунды за один вызов; помножьте на число вызовов в месяц — получите суммарный объём, за который платите.

Ключевой момент, который упускают при сравнении «на глаз»: цена за единицу вычислительного ресурса (vCPU-секунда, GB-секунда) в serverless почти всегда выше, чем цена той же единицы, «зашитой» в тариф VPS или выделенного сервера. Это не жадность платформы — это плата за то, что вы можете вообще не платить, когда функция не вызывается, и мгновенно отмасштабироваться на сотни параллельных выполнений без звонка в поддержку. Такая опциональность стоит денег тому, кто её предоставляет: платформа держит резерв мощности под ваш возможный всплеск, даже когда вы им не пользуетесь. Это тот же принцип, что и в сравнении облака с VPS в целом, просто раздробленный до уровня отдельного вызова функции, а не целого инстанса.

Отсюда прямое следствие: чем больше суммарных GB-секунд в месяц вы потребляете, тем меньше смысла в premium-цене за единицу этого ресурса — в какой-то точке фиксированная цена сервера, работающего 24/7, обгоняет накопленную стоимость вызовов, даже с учётом того, что сервер часть времени простаивает.

Скрытые накладные расходы: сеть, холодный старт и платный прогрев

Прямая стоимость вызовов — это ещё не весь счёт. У serverless есть минимум три статьи расходов, которые редко считают заранее, а потом они оказываются заметной частью бюджета.

Сетевой трафик между сервисами. Serverless-функция почти никогда не работает в изоляции — она читает из базы, кладёт файл в объектное хранилище, дергает другую функцию или внешний API. Если эти сервисы физически разнесены (разные зоны доступности, разные провайдеры, разные регионы), каждый такой вызов — это сетевой запрос с задержкой и часто с отдельной тарификацией трафика. На выделенном сервере тот же обмен между компонентами приложения обычно идёт через localhost или внутреннюю сеть дата-центра бесплатно и без задержки. Чем более «распределённой» становится архитектура из мелких функций, тем больше накладных расходов на межсервисное общение — это тот же эффект, что мы разбирали в мифе о микросервисах: дробление монолита на отдельные сервисы добавляет сетевые издержки, которых не было, пока всё работало в одном процессе.

Холодный старт. Если функцию давно не вызывали, платформе нужно поднять для неё новое окружение — это и есть cold start: задержка на инициализацию рантайма, загрузку кода и зависимостей, иногда — на прогрев соединений с базой. Для фонового задания, где секунда-другая ничего не решает, это не проблема. Для функции за пользовательским API, отвечающей мгновенно на клик в интерфейсе, дополнительная задержка в сотни миллисекунд — иногда больше секунды на «тяжёлых» рантаймах — уже ощутимо ухудшает отклик и может влиять на конверсию.

Платный прогрев как решение cold start. Платформы предлагают механизм, который держит N экземпляров функции уже запущенными и прогретыми, чтобы избежать холодного старта на первом запросе (в разных экосистемах это называется по-разному — provisioned concurrency, warm instances, minimum instances). Экономически это означает: вы платите за постоянно выделенные ресурсы вне зависимости от того, вызывается ли функция прямо сейчас — то есть частично возвращаетесь к модели «плачу за время, а не за вызов», но по цене serverless-единицы ресурса, которая выше цены той же единицы на VPS. Если для стабильного отклика приходится держать прогретыми несколько экземпляров постоянно — вы одной рукой платите premium за эластичность, а другой платите за то, чтобы ей не пользоваться. Это сигнал, что для такой нагрузки, скорее всего, дешевле обычный процесс на сервере, который просто всегда запущен.

Когда serverless реально экономит

Собрав всё вместе, экономия serverless устойчиво проявляется в нескольких конкретных формах нагрузки:

• Редкие вызовы с длинными простоями. Вебхуки, обработка загруженных файлов, крон-задачи раз в час или реже, интеграционные скрипты, срабатывающие по событию. Если суммарное время реальной работы функции за месяц — минуты, а не часы, VPS 24/7 почти всегда проигрывает по стоимости за единицу полезной работы.
• Сильно пиковая, непредсказуемая по времени нагрузка. Разовый маркетинговый всплеск, вебинар раз в месяц, сезонный пик заказов. Здесь важна не средняя нагрузка, а то, что пик редкий и непредсказуем по времени — держать под него сервер весь месяц означает почти всегда простаивающий запас.
• Ранняя стадия проекта без истории нагрузки. Когда неизвестно, придёт ли вообще трафик и какой формы он будет, serverless снимает вопрос выбора размера тарифа — вы буквально не платите, пока нет вызовов. Это скорее хедж на этапе неопределённости, чем постоянная архитектура.
• Задачи с естественно короткими, изолированными единицами работы, где каждый вызов независим и не требует «тёплого» состояния между вызовами — обработка изображения, конвертация файла, разовая валидация.

Во всех этих случаях объединяющий признак один и тот же: доля времени, когда вычислительная мощность реально используется, мала по сравнению с временем простоя, и этот простой непредсказуем или редок настолько, что держать под него постоянный сервер — чистая переплата за резерв, которым вы почти не пользуетесь.

Когда выгоднее выделенный сервер или VPS

Зеркальная сторона того же принципа: как только нагрузка становится постоянной, предсказуемой или достаточно частой, чтобы суммарное время выполнения приближалось к «почти всегда», premium-цена serverless-единицы ресурса начинает перевешивать выгоду от отсутствия оплаты простоя — потому что простоя, по сути, уже нет.

Типичные случаи, где выделенный сервер или VPS выгоднее:

• Постоянный высоконагруженный backend. API, который обрабатывает запросы непрерывно в течение рабочего дня (а часто и ночью — из-за пользователей в других часовых поясах или фоновых процессов), фактически «занят» большую часть времени — вы платите за GB-секунды почти как за постоянную работу, но по более высокой ставке за единицу, чем дала бы аренда сервера.
• Долгоживущие соединения и состояние в памяти. WebSocket-серверы, очереди с долгими подписчиками, задачи, которым выгодно держать кеш или соединение с базой открытым между запросами — сама модель serverless (короткоживущие изолированные вызовы) плохо ложится на такую нагрузку, и приходится либо эмулировать постоянство платным прогревом, либо мириться с повторными затратами на переустановку соединений на каждый вызов.
• Стабильная нагрузка с предсказуемым ростом. Если трафик растёт плавно и предсказуемо (не скачками), тарифная модель VPS с понятным фиксированным счётом и плановым апгрейдом тарифа управляется проще и обходится дешевле, чем накопленная сумма по факту вызовов, которая растёт вместе с трафиком без верхней границы.
• Задачи, чувствительные к задержке отклика. Если cold start недопустим по бизнес-требованиям (например, у пользовательского API с жёстким SLA по времени ответа), а платный прогрев экономически сводит выгоду serverless на нет — постоянно работающий процесс на сервере предсказуемее и часто дешевле, чем serverless с оплаченным прогревом под ту же надёжность отклика.

Методика расчёта: считаем точку перелома для своей нагрузки

Вместо решения «на ощущение» посчитайте два числа для своей реальной или прогнозируемой нагрузки и сравните их напрямую — методика похожа на ту, что мы разбирали для сравнения облака и VPS в целом, но применена к уровню отдельной функции.

Шаг 1. Собрать вводные по нагрузке функции

Нужны четыре величины за представительный период (2–4 недели минимум):

• число вызовов в месяц (N);
• среднее время выполнения одного вызова в секундах (t);
• выделенная функции память в гигабайтах (m);
• объём исходящего трафика на вызов, если он значимый.

Шаг 2. Посчитать суммарные GB-секунды в месяц

GB_sec_total = N × t × m

Пример (числа условные, для иллюстрации логики расчёта, а не как ориентир по ценам): функция вызывается 500 000 раз в месяц, среднее время выполнения 300 мс, память 512 МБ.

GB_sec_total = 500000 × 0.3 × 0.5 = 75000 GB-секунд в месяц

Шаг 3. Перевести в условную стоимость serverless и сравнить с VPS

# Условные ставки — подставьте актуальные цифры из прайса
# конкретной платформы на момент расчёта, здесь только логика.
price_per_invocation = 0.0000002   # условная цена за вызов
price_per_gb_sec = 0.0000166       # условная цена за GB-секунду

invocations = 500000
gb_sec_total = 75000

cost_serverless = invocations * price_per_invocation + gb_sec_total * price_per_gb_sec
print(f"Условная стоимость serverless: {cost_serverless:.2f}")

# Сопоставимая постоянная нагрузка на сервере:
# t × N секунд суммарной работы в месяц / (30 × 86400) секунд в месяце
utilization = (invocations * 0.3) / (30 * 86400)
print(f"Эквивалентная утилизация сервера: {utilization*100:.1f}%")

Смысл второй части кода: перевести суммарное время выполнения функции в долю месяца, которую занял бы аналогичный процесс на постоянно работающем сервере. Если утилизация выходит на уровень, для которого вы бы всё равно держали сервер под другие задачи (или он приближается к 15–20% и выше от постоянной загрузки одного ядра), — стоит явно посчитать стоимость аренды сервера того же класса и сравнить с cost_serverless напрямую.

Шаг 4. Учесть накладные расходы отдельной строкой

К стоимости из шага 3 добавьте отдельно: трафик между сервисами, если функция и её зависимости территориально разнесены; стоимость прогрева (provisioned concurrency), если задержка cold start неприемлема — это отдельная позиция, которую легко забыть при первой прикидке; и трудозатраты на поддержку самой распределённой архитектуры — не строка в счёте платформы, но реальный ресурс, который стоит держать в уме при сравнении с одним процессом на одном сервере.

Шаг 5. Пересчитывать при росте нагрузки

Точка перелома не статична: то, что выгодно при 50 000 вызовов в месяц, может стать невыгодным при 5 миллионах — суммарные GB-секунды растут линейно с трафиком, а цена VPS остаётся фиксированной до апгрейда тарифа. Разумно пересчитывать баланс раз в квартал или при заметном изменении профиля нагрузки, а не полагаться на решение, принятое один раз на старте проекта.

Частые вопросы