Бессерверный режим

Бессерверный режим (также бессерверные вычисления, serverless computing) — это модель выполнения облачных вычислений, при которой облачный провайдер динамически управляет выделением и распределением вычислительных ресурсов, а пользователь оплачивает только фактически потреблённые ресурсы, не занимаясь администрированием серверной инфраструктуры. Вопреки названию, серверы в этой модели физически существуют, но их управление, масштабирование и обслуживание полностью абстрагированы от разработчика.

История

Концепция бессерверных вычислений берёт начало в середине 2000-х годов с появлением платформ «функция как услуга» (Function as a Service, FaaS). Первым коммерческим продуктом в этой области считается сервис AWS Lambda, запущенный компанией Amazon Web Services в 2014 году. AWS Lambda позволял разработчикам загружать код и запускать его в ответ на события (например, HTTP-запросы, загрузка файлов, изменения в базе данных) без необходимости настраивать серверы.

Вслед за Amazon аналогичные сервисы представили другие крупные облачные провайдеры:

Google Cloud Functions (2016 год);
Microsoft Azure Functions (2016 год);
IBM Cloud Functions (на базе Apache OpenWhisk, 2016 год);
Yandex Cloud Functions (2019 год).

Параллельно развивалась модель «бэкенд как услуга» (Backend as a Service, BaaS), которая также относится к бессерверному подходу, но ориентирована на готовые серверные компоненты (аутентификация, базы данных, хранение файлов), предоставляемые через API.

Ключевые характеристики

Бессерверный режим отличается от традиционных моделей облачных вычислений (IaaS, PaaS) следующими особенностями:

Автоматическое масштабирование. Провайдер автоматически выделяет ресурсы под каждое выполнение функции. При увеличении нагрузки количество параллельно работающих экземпляров растёт без вмешательства пользователя.
Оплата по факту использования. Пользователь платит только за время выполнения кода (в миллисекундах) и количество запросов, а не за заранее выделенные ресурсы. В простое функция не потребляет ресурсов и не тарифицируется.
Абстракция инфраструктуры. Разработчик не управляет операционной системой, сетевыми настройками, обновлениями безопасности или масштабированием. Всё это — ответственность провайдера.
Событийно-ориентированная архитектура. Функции запускаются в ответ на события (триггеры): HTTP-запросы, изменения в базах данных, сообщения из очередей, загрузка файлов в объектное хранилище.
Ограниченное время выполнения. Большинство платформ FaaS устанавливают лимит на время выполнения одной функции (обычно от 5 до 15 минут). Долгие процессы требуют иных архитектурных решений.

Классификация

Бессерверный режим принято разделять на два основных направления:

Функция как услуга (FaaS)

Платформа, на которой разработчик загружает отдельные функции (фрагменты кода), а провайдер запускает их в изолированных контейнерах. FaaS — наиболее распространённая форма бессерверных вычислений. Примеры: AWS Lambda, Google Cloud Functions, Azure Functions, Yandex Cloud Functions.

Бэкенд как услуга (BaaS)

Готовые серверные сервисы, предоставляемые через API. Разработчик использует их без написания собственного серверного кода. К BaaS относятся:

аутентификация и управление пользователями (Firebase Authentication, Auth0);
базы данных (Firebase Firestore, MongoDB Atlas);
хранение файлов (Amazon S3, Google Cloud Storage);
отправка push-уведомлений;
обработка платежей (Stripe, YooKassa).

Устройство и принцип работы

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

Для снижения влияния холодного старта провайдеры используют:

резервирование предварительно инициализированных контейнеров (provisioned concurrency);
оптимизацию размера пакета функции;
использование языков с быстрым запуском (например, Node.js, Python).

Применение

Бессерверный режим получил широкое распространение в ряде сценариев:

Веб-приложения и API. Функции обрабатывают HTTP-запросы, выполняя бизнес-логику без необходимости поддерживать сервер.
Обработка данных. Автоматическая обработка файлов при загрузке (изменение размера изображений, конвертация форматов, анализ логов).
Потоковая обработка событий. Реагирование на сообщения из очередей (Kafka, RabbitMQ, Amazon SQS) или потоков данных (Amazon Kinesis).
Парсинг и сбор данных. Запуск функций по расписанию для сбора информации с веб-сайтов.
Чат-боты и голосовые ассистенты. Обработка запросов от пользователей через мессенджеры или голосовые интерфейсы.
DevOps и автоматизация. Запуск скриптов для управления инфраструктурой, резервного копирования, мониторинга.

Преимущества и недостатки

Преимущества

Снижение операционных затрат. Отсутствие необходимости в администрировании серверов, обновлении ПО, обеспечении безопасности инфраструктуры.
Экономия ресурсов. Оплата только за фактическое использование, что выгодно для приложений с непостоянной или непредсказуемой нагрузкой.
Высокая масштабируемость. Автоматическое масштабирование до тысяч параллельных вызовов без дополнительных настроек.
Быстрое развёртывание. Разработчик сосредоточен на коде, а не на инфраструктуре, что ускоряет выход новых версий.

Недостатки

Холодный старт. Задержка при первом вызове функции после простоя может достигать нескольких секунд, что критично для приложений реального времени.
Ограничения по времени и ресурсам. Функции не могут выполняться дольше установленного лимита (обычно до 15 минут), что ограничивает применение для длительных вычислений.
Сложность отладки и мониторинга. Распределённая архитектура усложняет трассировку запросов и поиск ошибок.
Привязка к провайдеру (vendor lock-in). Использование специфичных сервисов конкретного облачного провайдера затрудняет миграцию на другую платформу.
Сложность архитектуры. Необходимость проектирования приложения в виде множества мелких функций, что может усложнить поддержку и тестирование.

Критика

Основные критические замечания в адрес бессерверного режима связаны с потерей контроля над инфраструктурой и непредсказуемостью стоимости. При высокой и стабильной нагрузке бессерверная модель может оказаться дороже традиционного выделенного сервера или виртуальной машины. Кроме того, сложность прогнозирования расходов (особенно при большом количестве запросов) вызывает недовольство у некоторых организаций.

Также отмечается, что термин «бессерверный» вводит в заблуждение, создавая ложное впечатление об отсутствии серверов как таковых. На практике серверы существуют, но управляются провайдером, что может создавать риски, связанные с конфиденциальностью данных и соблюдением законодательства (например, Федерального закона «О персональных данных» № 152-ФЗ в России).