Serverless¶

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

¶История возникновения

Концепция serverless берёт начало в развитии облачных вычислений и платформ как услуги (PaaS). Первым коммерческим продуктом, реализовавшим идею serverless, стала AWS Lambda, запущенная компанией Amazon Web Services в ноябре 2014 года. AWS Lambda позволяла запускать код в ответ на события (например, загрузку файла в S3 или HTTP-запрос) без необходимости предварительно создавать или настраивать серверы. Это стало прорывом, так как разработчики могли сосредоточиться на бизнес-логике, а не на инфраструктуре.

В последующие годы другие крупные облачные провайдеры представили аналогичные сервисы: Google Cloud Functions (2016), Azure Functions (2016) от Microsoft, IBM Cloud Functions (на базе Apache OpenWhisk). В 2017 году появилась платформа Cloudflare Workers, которая выполняет код на границе сети (edge computing), что ещё больше расширило возможности serverless. К 2020-м годам serverless стала стандартной опцией в большинстве облачных экосистем, а также появились open-source решения, такие как OpenFaaS и Knative, позволяющие разворачивать serverless-архитектуры на собственных серверах.

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

¶Автоматическое масштабирование

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

¶Оплата по факту использования

В отличие от традиционных виртуальных машин или контейнеров, где оплачивается время аренды (даже при простое), в serverless оплата производится за количество выполнений функции (запросов) и время выполнения, измеряемое в миллисекундах. Это делает модель экономически эффективной для приложений с нерегулярной или непредсказуемой нагрузкой.

¶Управляемая инфраструктура

Облачный провайдер полностью берёт на себя управление серверами, операционной системой, обновлениями безопасности, мониторингом и балансировкой нагрузки. Разработчик отвечает только за код функции и её конфигурацию (например, объём выделяемой памяти, тайм-аут выполнения).

¶Событийно-ориентированная архитектура

Serverless-функции обычно запускаются в ответ на события: HTTP-запросы (через API Gateway), изменения в базах данных, загрузка файлов, сообщения из очередей (например, Amazon SQS, Azure Queue Storage), таймеры (CRON-расписания) и другие триггеры. Это хорошо сочетается с микросервисной архитектурой и системами, построенными на событийной модели.

¶Архитектура и компоненты

Типичная serverless-архитектура включает несколько ключевых компонентов:

1. Функция как услуга (FaaS) — ядро serverless. Это единица выполнения кода (например, на Python, Node.js, Java, Go), которая запускается в изолированном контейнере (часто на базе Docker) и имеет ограниченное время жизни (обычно до 15 минут у AWS Lambda, до 10 минут у Azure Functions). Функция не имеет состояния (stateless) — данные между вызовами не сохраняются в памяти, поэтому для хранения состояния используются внешние сервисы (базы данных, кэши).

1. Бэкенд как услуга (BaaS) — внешние управляемые сервисы, которые serverless-функции используют для выполнения своих задач. К ним относятся: базы данных (Amazon DynamoDB, Azure Cosmos DB), хранилища объектов (Amazon S3, Google Cloud Storage), очереди сообщений (Amazon SQS, Google Pub/Sub), аутентификация (Amazon Cognito, Auth0), API-шлюзы (Amazon API Gateway, Azure API Management).

1. Триггеры и события — механизмы, которые запускают выполнение функции. Примеры: HTTP-запрос (через API Gateway), изменение записи в базе данных (например, DynamoDB Streams), загрузка файла в S3, поступление сообщения в очередь, срабатывание таймера (CloudWatch Events).

1. Оркестрация — для сложных рабочих процессов, состоящих из нескольких функций, используются сервисы оркестрации, такие как AWS Step Functions или Azure Durable Functions. Они позволяют координировать последовательное или параллельное выполнение функций, обрабатывать ошибки и управлять состоянием длительных процессов.

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

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

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

¶Недостатки

• Холодный старт — при первом вызове функции после длительного простоя или при масштабировании требуется время на инициализацию контейнера (обычно от сотен миллисекунд до нескольких секунд). Это может увеличить задержку для пользователей.
• Ограничения по времени и ресурсам — максимальное время выполнения функции ограничено (обычно 15 минут), что делает serverless непригодным для длительных задач (например, обработка видеофайлов большого размера). Также есть ограничения по объёму памяти (до 10 ГБ) и дискового пространства (до 512 МБ для временного хранилища).
• Сложность отладки и мониторинга — распределённая архитектура и отсутствие доступа к серверу усложняют трассировку запросов и отладку. Требуются специализированные инструменты (например, AWS X-Ray, Azure Application Insights).
• Зависимость от провайдера — привязка к конкретному облачному провайдеру (vendor lock-in). Перенос serverless-приложения между платформами может потребовать значительных изменений кода из-за различий в API, триггерах и сервисах BaaS.
• Безопасность — разработчик не контролирует среду выполнения, что может создавать риски, связанные с изоляцией функций и утечкой данных между арендаторами (хотя провайдеры обеспечивают высокий уровень изоляции).

¶Применение

Serverless-архитектура широко используется в различных сценариях:

• Веб-приложения и API — создание RESTful API с помощью API Gateway и функций. Например, бэкенд для интернет-магазина, обработка форм обратной связи.
• Обработка данных в реальном времени — анализ потоков данных из IoT-устройств, логов, социальных сетей. Функции могут фильтровать, агрегировать и сохранять данные.
• Автоматизация задач — создание триггеров для автоматических действий: отправка уведомлений, генерация отчётов по расписанию, резервное копирование, обработка изображений при загрузке.
• Чат-боты и голосовые ассистенты — обработка запросов от пользователей через мессенджеры или голосовые интерфейсы (например, Amazon Alexa, Google Assistant).
• Парсинг и веб-скрапинг — выполнение периодических запросов к веб-сайтам для сбора данных.
• Микросервисы — реализация отдельных микросервисов в виде serverless-функций, что упрощает их развёртывание и масштабирование.

¶Примеры платформ

¶Критика и ограничения

Несмотря на популярность, serverless-архитектура подвергается критике по нескольким причинам:

• Холодный старт остаётся одной из главных проблем, особенно для приложений, требующих минимальной задержки. Для её смягчения используются техники «прогрева» (keep-warm) или предварительного выделения ресурсов (provisioned concurrency), что увеличивает стоимость.
• Сложность мониторинга — в распределённой системе трудно отследить полный путь запроса, особенно при использовании множества функций и сервисов. Требуется внедрение распределённой трассировки (distributed tracing).
• Стоимость при высоких нагрузках — для приложений с постоянной высокой нагрузкой (например, 1000 запросов в секунду 24/7) serverless может оказаться дороже, чем аренда выделенных серверов или контейнеров, из-за наценки за управляемость и масштабирование.
• Ограничения на размер пакета — код функции и её зависимости должны быть упакованы в архив, размер которого обычно ограничен (например, 250 МБ для AWS Lambda). Это может быть проблемой для больших библиотек или моделей машинного обучения.
• Отсутствие полного контроля — разработчик не может настроить операционную систему, сетевые параметры или установить произвольное программное обеспечение на сервере выполнения.

¶Источники

• Amazon Web Services. «AWS Lambda — Serverless Compute».
• Microsoft Azure. «Azure Functions Documentation».
• Google Cloud. «Cloud Functions Documentation».
• Jonas, E., et al. (2019). «Cloud Programming Simplified: A Berkeley View on Serverless Computing». Technical Report No. UCB/EECS-2019-3.
• Lynn, T., et al. (2017). «A Survey of Serverless Computing». Future Generation Computer Systems.
• Miller, R. (2020). «Serverless Architectures on AWS». Manning Publications.