Бизнес платит за серверы круглосуточно, а используют их урывками. Ночью простаивает то, за что вы отдали деньги днём. Serverless ломает эту логику: вы платите за миллисекунды выполнения кода и за число вызовов, а не за арендованную машину. Простаивающая функция не стоит ничего. Разберём, где эта модель экономит деньги, а где создаёт новые риски.

Что скрывается за словом «serverless»

Серверы никуда не делись – вы просто перестаёте ими управлять. Облачный провайдер сам поднимает контейнер под ваш код, выполняет его и гасит. Частный случай – FaaS (Function as a Service): вы загружаете одну функцию, провайдер вызывает её в ответ на событие. Загрузили файл – сработала функция обработки. Пришёл HTTP-запрос – отработал обработчик. Между вызовами ресурсы не резервируются.

На западном рынке стандарт задаёт AWS Lambda, есть Azure Functions и Google Cloud Functions. В России на эту модель двигаются Yandex Cloud и Mail.ru Cloud Solutions. Для госсектора это принципиально: данные остаются в российских ЦОД, что снимает вопросы по 152-ФЗ о персональных данных и закону о хранении данных на территории РФ.

Когда платить за выполнение выгодно

Serverless окупается на нагрузке, которая скачет. Три типичных сценария:

  • Редкие фоновые задачи. Ночная выгрузка отчётов, пересчёт агрегатов, рассылка уведомлений. Запускать ради них постоянный сервер – переплата.
  • Непредсказуемые пики. Подача заявлений в первый день приёма, отчётность в конце квартала. FaaS масштабируется автоматически: один вызов или десять тысяч – инфраструктура подстроится сама, без вашего участия.
  • Обработка событий и обвязка. Конвертация изображений, постановка задач в очередь, склейка вызовов между сервисами.

Хорошо ложатся сюда и ресурсоёмкие, но эпизодические операции – например, прогон кадра через модель распознавания, как мы описывали в материале про биометрию и распознавание лиц. Платить за GPU-сервер ради нескольких вызовов в час бессмысленно.

Где модель не работает

Serverless – не замена всему. У него есть жёсткие ограничения, и игнорировать их дорого.

Первое – холодный старт. Если функцию давно не вызывали, провайдер поднимает контейнер заново: задержка от сотен миллисекунд до пары секунд. Для пакетной обработки это незаметно, для интерактивного API под высокой нагрузкой – чувствительно.

Второе – ограничения по времени и памяти. Функция, которая считает час, в FaaS не поместится: провайдеры обрывают выполнение по таймауту. Долгие расчёты, обучение моделей – а интерес к ним растёт на фоне обсуждения национальной стратегии в области ИИ – остаются за классическими серверами.

Третье – стоимость на ровной нагрузке. Если сервис загружен стабильно 24/7, выделенная машина обойдётся дешевле, чем поминутная оплата миллионов вызовов. Считайте на своих числах, а не на маркетинговых обещаниях провайдера.

Отдельно – привязка к провайдеру. Код функции переносится легко, но триггеры, очереди и хранилища у каждого облака свои. Миграция между провайдерами потребует переписать обвязку. Это та же проблема непредсказуемости поведения, что мы разбирали на примере генеративных моделей вроде GPT-2: мощный инструмент требует понимания границ применимости.

Вывод

Serverless – не модный ярлык, а инструмент для конкретной задачи: эпизодической, событийной, неравномерной нагрузки. Он режет счета там, где сервер простаивает, и не помогает там, где он загружен ровно. Правильный выбор начинается с анализа профиля нагрузки и расчёта на реальных данных, на основе которого и проектируется гибридная инфраструктура, где serverless соседствует с классическими серверами.