Бессерверная архитектура

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

История

Концепция бессерверных вычислений начала формироваться в середине 2010-х годов как развитие идей облачных вычислений и платформ как услуги (PaaS). Ключевым импульсом стал запуск сервиса AWS Lambda компанией Amazon Web Services в ноябре 2014 года. Этот сервис впервые позволил разработчикам запускать код в ответ на события без необходимости управлять серверами. Вслед за AWS аналогичные сервисы представили Google (Google Cloud Functions, 2016), Microsoft (Azure Functions, 2016) и IBM (IBM Cloud Functions, 2016). В 2017 году появился проект OpenWhisk (позднее — Apache OpenWhisk), ставший основой для открытых бессерверных платформ.

К концу 2010-х годов бессерверная архитектура стала одним из основных трендов в облачных вычислениях, хотя и оставалась нишевой из-за ряда ограничений. В 2020 году появился проект Knative, построенный на Kubernetes, который позволил развёртывать бессерверные приложения в собственных кластерах, а не только у публичных облачных провайдеров.

Основные принципы и характеристики

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

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

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

Бессерверную архитектуру принято разделять на два основных направления:

Функции как услуга (FaaS — Function as a Service)

Это наиболее распространённая форма бессерверных вычислений. Разработчик пишет отдельные функции (обычно на языках Python, JavaScript/Node.js, Java, Go, C#), которые загружаются в облачную платформу. Платформа предоставляет среду выполнения (runtime) и API для вызова функций. Примеры: AWS Lambda, Azure Functions, Google Cloud Functions, Яндекс.Облако (Cloud Functions). FaaS идеально подходит для микросервисов, обработки данных, веб-хуков, задач по расписанию.

Бэкенд как услуга (BaaS — Backend as a Service)

Этот подход предполагает использование готовых облачных сервисов для реализации типовой серверной логики без необходимости писать и разворачивать собственный код. К BaaS относятся: облачные базы данных (Firebase, AWS DynamoDB, MongoDB Atlas), аутентификация (Auth0, AWS Cognito), хостинг статических сайтов (AWS S3, Netlify), сервисы очередей (AWS SQS, Google Pub/Sub), push-уведомления, аналитика. Разработчик использует готовые API и SDK, а не пишет серверный код.

Устройство и компоненты

Типичная архитектура бессерверного приложения включает следующие компоненты:

Функции (Functions) — единицы кода, выполняющие одну задачу. Каждая функция имеет свой триггер, среду выполнения и настройки (тайм-аут, память, переменные окружения).
Триггеры (Triggers) — события, которые запускают выполнение функции. Типы триггеров: HTTP-запросы (API Gateway), изменения в базе данных, загрузка файлов в хранилище, сообщения из очередей, таймеры (cron), события из других облачных сервисов.
API Gateway — сервис, который принимает внешние HTTP-запросы, маршрутизирует их к соответствующим функциям, управляет аутентификацией, квотами и кэшированием.
Объектное хранилище (например, AWS S3, Google Cloud Storage) — используется для хранения статических файлов (изображения, видео, документы) и как триггер для функций.
Базы данных — обычно NoSQL (DynamoDB, Firebase) или реляционные (Aurora Serverless, Google Cloud SQL) с бессерверным режимом.
Очереди сообщений (AWS SQS, Google Pub/Sub) — для асинхронной обработки задач и развязывания компонентов.
Логирование и мониторинг — встроенные сервисы (AWS CloudWatch, Google Cloud Logging) для отслеживания выполнения функций, ошибок и метрик производительности.

Применение

Бессерверная архитектура нашла применение в ряде сценариев, где её преимущества наиболее заметны:

Веб-приложения и API. Создание RESTful или GraphQL API с помощью FaaS и API Gateway. Каждый эндпоинт реализуется отдельной функцией.
Обработка данных в реальном времени. Анализ потоков данных (например, из IoT-устройств, логов, социальных сетей), фильтрация, агрегация, сохранение.
Пакетная обработка и ETL. Запуск функций по расписанию для обработки больших объёмов данных (например, ежедневная генерация отчётов).
Чат-боты и голосовые ассистенты. Обработка запросов от пользователей с помощью функций, вызываемых через API мессенджеров или голосовых платформ.
Автоматизация инфраструктуры. Запуск функций в ответ на события в облаке (например, автоматическое создание резервных копий, реагирование на инциденты).
Мобильные приложения. Использование BaaS для аутентификации, хранения данных, push-уведомлений, что позволяет быстро запустить бэкенд без серверов.
Микросервисы. Бессерверная архитектура хорошо подходит для реализации отдельных микросервисов, особенно если они не требуют постоянного выполнения и могут быть асинхронными.

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

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

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

Недостатки

Холодный старт (cold start). При первом вызове функции после периода бездействия платформа загружает среду выполнения, что может занять от нескольких сотен миллисекунд до нескольких секунд. Это может быть критично для приложений, требующих низкой задержки.
Ограничения по времени выполнения и ресурсам. Функции имеют максимальное время выполнения (обычно 15 минут) и ограничение по памяти (до 10 ГБ). Долгие задачи требуют другого подхода.
Сложность отладки и мониторинга. Распределённая природа бессерверных приложений усложняет локальную отладку и трассировку запросов. Требуются специализированные инструменты.
Привязка к вендору (vendor lock-in). Использование специфических сервисов конкретного облачного провайдера (например, AWS Lambda + DynamoDB) может затруднить миграцию на другую платформу.
Сложность управления состоянием. Поскольку функции статистические, любое состояние должно храниться во внешних сервисах, что увеличивает сложность и задержки.
Стоимость при высоких нагрузках. При постоянной и высокой нагрузке бессерверная модель может оказаться дороже, чем традиционные виртуальные машины или контейнеры, из-за наценки за управление и масштабирование.

Критика

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

Интересные факты

Крупнейшие облачные провайдеры (AWS, Google Cloud, Microsoft Azure) предлагают бесплатные лимиты на использование бессерверных функций, что позволяет разработчикам тестировать и прототипировать приложения без затрат.
Бессерверная архитектура активно используется в проектах с открытым исходным кодом, таких как OpenFaaS и Knative, которые позволяют развёртывать бессерверные функции в собственных кластерах Kubernetes.
В 2020 году компания Netflix (организация, признанная нежелательной в РФ) использовала бессерверную архитектуру для обработки видео и управления контентом, хотя основные сервисы стриминга работают на традиционной инфраструктуре.

Источники

AWS Lambda Documentation — Amazon Web Services.
Google Cloud Functions Documentation — Google Cloud.
Azure Functions Documentation — Microsoft Azure.
Knative Documentation — Knative Project.
OpenFaaS Documentation — OpenFaaS Project.
«Serverless Architectures» — Martin Fowler, 2016.
«Serverless Computing: One Step Forward, Two Steps Back» — J. M. Hellerstein et al., 2018.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →