FaaS

FaaS, или Function as a Service, — это модель облачных вычислений, при которой разработчик размещает в облаке отдельные функции, а провайдер автоматически запускает их при наступлении определенного события.

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

FaaS часто рассматривают как один из вариантов Serverless Computing. При такой модели серверы физически существуют, но управление ими скрыто от разработчика.

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

Как расшифровывается FaaS

FaaS расшифровывается как Function as a Service — функция как услуга.

Основной единицей развертывания становится не целый сервер или постоянно работающий процесс, а отдельная функция.

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

Когда появляется новый файл, облачная платформа запускает функцию автоматически.

Как работает FaaS

Разработчик пишет функцию и загружает ее в облачную платформу.

Далее указывается событие, которое должно запускать код.

1. Происходит событие.
2. Платформа определяет связанную с ним функцию.
3. Создается или активируется среда выполнения.
4. Функция получает входные данные.
5. Код выполняется.
6. Результат передается другой системе или сохраняется.
7. После завершения ресурсы могут быть освобождены.

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

Что считается событием в FaaS

Функция обычно выполняется не постоянно, а в ответ на определенный trigger.

Такая событийная модель является одной из ключевых особенностей FaaS.

Пример FaaS простыми словами

Пользователь загружает фотографию в приложение.

Файл сохраняется в облачном хранилище. Событие загрузки автоматически запускает функцию.

Функция создает уменьшенную копию изображения и записывает ее обратно в хранилище.

После выполнения функция больше не потребляет вычислительные ресурсы до следующего события.

FaaS и Serverless

FaaS часто называют Serverless, но эти понятия не полностью идентичны.

Serverless — более широкая модель, при которой разработчик не занимается непосредственным управлением серверами.

FaaS является одним из способов реализации Serverless и ориентирован именно на запуск функций.

Почему Serverless не означает отсутствие серверов

Название может создавать впечатление, что серверов в такой системе вообще нет.

На самом деле код выполняется на физических или виртуальных вычислительных ресурсах провайдера.

Разница заключается в том, что клиент не создает и не администрирует эти серверы напрямую.

Облачная платформа автоматически выделяет ресурсы для выполнения функции.

FaaS и IaaS

В IaaS клиент получает виртуальную инфраструктуру и самостоятельно управляет операционной системой и приложениями.

В FaaS уровень абстракции значительно выше.

FaaS и PaaS

PaaS предоставляет готовую платформу для запуска приложений, но приложение обычно рассматривается как более крупный постоянно доступный сервис.

В FaaS система разделяется на отдельные функции, которые запускаются по событиям.

PaaS удобна для веб-приложений и API, работающих постоянно. FaaS особенно хорошо подходит для коротких событийных задач.

На практике эти модели могут использоваться совместно.

FaaS и SaaS

SaaS предоставляет конечному пользователю готовое программное обеспечение.

FaaS предназначена для разработчиков и используется как вычислительный компонент приложения.

Например, пользователь работает с SaaS-сервисом обработки документов, а внутри этого продукта отдельные операции могут выполняться через FaaS.

То есть SaaS и FaaS находятся на разных уровнях облачной архитектуры.

IaaS, PaaS, FaaS и SaaS

По мере движения от IaaS к SaaS объем инфраструктуры, которым непосредственно управляет клиент, обычно уменьшается.

Event-Driven Architecture

FaaS хорошо подходит для событийно-ориентированной архитектуры.

В такой системе компоненты реагируют на события вместо постоянного опроса других сервисов.

Например, создание заказа формирует событие. После него одна функция отправляет письмо, другая обновляет статистику, а третья запускает интеграцию со складом.

Компоненты можно масштабировать независимо.

Trigger в FaaS

Trigger — условие или событие, запускающее функцию.

Функция без триггера обычно не выполняется самостоятельно.

Триггером может стать входящий HTTP-запрос, запись в очереди, появление файла или таймер.

Правильный выбор событий позволяет создавать слабосвязанные компоненты.

FaaS для HTTP API

Функцию можно запускать по HTTP-запросу.

Например, мобильное приложение обращается к endpoint, который передает запрос FaaS-функции.

Она проверяет данные, выполняет операцию и возвращает ответ.

Таким способом можно создавать небольшие API без постоянного управления веб-сервером.

API Gateway и FaaS

Перед функциями часто располагается API Gateway.

Он принимает HTTP-запросы и направляет их нужным функциям.

Также шлюз может выполнять аутентификацию, ограничение частоты запросов и маршрутизацию.

Это позволяет отделить публичный API от внутренней логики функций.

FaaS для обработки файлов

Обработка файлов является классическим сценарием использования.

Например, пользователь загружает PDF в объектное хранилище.

Событие запускает функцию, которая извлекает метаданные или передает документ в дальнейший Data Pipeline.

При отсутствии новых файлов вычислительные ресурсы для этой функции не требуются.

FaaS для обработки изображений

После загрузки фотографии можно автоматически создавать несколько размеров изображения.

Одна функция получает событие загрузки и формирует preview.

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

Такой подход особенно удобен при непредсказуемом количестве загружаемых файлов.

FaaS и очереди сообщений

Очередь сообщений позволяет отделить источник события от обработчика.

Например, интернет-магазин помещает новые заказы в очередь.

FaaS-функция получает сообщения и выполняет определенную обработку.

Если заказов становится больше, платформа может параллельно запустить дополнительные экземпляры функции.

Асинхронная обработка

Не каждую задачу нужно выполнять во время пользовательского HTTP-запроса.

Например, генерация большого отчета может занимать несколько минут.

Приложение создает задание и отвечает пользователю, а функция выполняет работу отдельно.

Результат затем сохраняется в хранилище или отправляется пользователю.

FaaS и расписание

Функции могут запускаться по расписанию.

Например, каждый день в определенное время выполняется очистка временных данных или формирование отчета.

Это позволяет заменить небольшой постоянно работающий сервер несколькими короткими задачами.

Для сложных зависимых процессов иногда лучше использовать специализированный оркестратор.

Stateless-функции

FaaS-функцию обычно проектируют как stateless-компонент.

Она не должна рассчитывать, что данные, сохраненные в памяти или локальном файле, обязательно останутся доступными при следующем вызове.

Следующий запрос может выполняться в другой среде.

Постоянное состояние следует хранить во внешней базе данных, объектном хранилище или другом специализированном сервисе.

Почему stateless важен

Если функция не зависит от конкретного экземпляра, платформа может свободно запускать десятки ее копий.

Это значительно упрощает горизонтальное масштабирование.

Каждый экземпляр получает входные данные, выполняет задачу и завершается.

Общее состояние находится за пределами вычислительного процесса.

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

Одно из основных преимуществ FaaS — автоматическое масштабирование.

Если поступает одно событие, может выполняться один экземпляр функции.

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

Разработчику не требуется вручную создавать дополнительные виртуальные машины.

Ограничение параллелизма

Не всегда полезно запускать максимально возможное количество функций одновременно.

Например, функция обращается к базе данных, которая может обслуживать только ограниченное число соединений.

Если одновременно запустить тысячи экземпляров, downstream-система может быть перегружена.

Поэтому concurrency часто необходимо ограничивать.

Cold Start

Cold Start — задержка при запуске функции, когда платформа должна подготовить новую среду выполнения.

Если экземпляр уже подготовлен, следующий вызов может выполняться быстрее.

Cold Start особенно заметен для приложений с жесткими требованиями к latency.

Его влияние зависит от языка, размера приложения, конфигурации и особенностей платформы.

Warm Start

Warm Start означает выполнение функции в уже подготовленной среде.

В таком случае не требуется полностью инициализировать runtime с нуля.

Ответ может быть быстрее.

Однако разработчик обычно не должен полагаться на то, что конкретная среда обязательно сохранится между вызовами.

Timeout функции

FaaS обычно предполагает ограничение максимальной продолжительности одного вызова.

Поэтому модель лучше подходит для относительно коротких операций.

Если обработка занимает очень долгое время, задачу можно разделить на этапы или выбрать другой тип вычислительной инфраструктуры.

Точные ограничения зависят от конкретного провайдера.

Ограничения памяти и CPU

Функция выполняется с определенным количеством вычислительных ресурсов.

Если коду требуется очень большой объем памяти или специализированное оборудование, стандартный FaaS может не подойти.

Также характеристики CPU могут зависеть от выбранной конфигурации.

Нагрузку желательно тестировать в реальной среде.

Стоимость FaaS

Одна из особенностей FaaS — оплата, связанная с фактическими вызовами и потребленными вычислительными ресурсами.

При редких запросах такой подход может быть экономичным.

Компания не обязана постоянно оплачивать целую виртуальную машину для небольшой задачи.

При очень стабильной и высокой нагрузке экономику следует сравнивать с контейнерами, PaaS или IaaS.

Когда FaaS может экономить деньги

Представим функцию, которая вызывается только несколько раз в час и выполняется две секунды.

Содержать для нее отдельный постоянно работающий сервер может быть неэффективно.

FaaS позволяет оплачивать только реальные периоды выполнения согласно тарифной модели платформы.

Чем более нерегулярна нагрузка, тем заметнее может быть это преимущество.

Когда FaaS может быть дорогим

При постоянном большом количестве вызовов суммарная стоимость функций способна превысить стоимость постоянно работающей инфраструктуры.

Дополнительные расходы могут создавать API Gateway, очереди, журналы, базы данных и сетевой трафик.

Поэтому нельзя сравнивать архитектуры только по цене одного вызова.

Следует рассчитывать полную стоимость решения.

FaaS и FinOps

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

Например, программная ошибка создает миллионы сообщений и запускает огромное количество функций.

Полезно настраивать бюджеты, лимиты, мониторинг количества вызовов и concurrency.

Это позволяет обнаруживать аномальный рост потребления.

FaaS и микросервисы

Отдельная функция может реализовывать небольшую часть бизнес-логики.

Поэтому FaaS иногда используется в микросервисной архитектуре.

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

Границы функций лучше определять по понятным бизнес-событиям и техническим задачам.

FaaS и контейнеры

Контейнер обычно позволяет запускать более длительный процесс и дает разработчику больше контроля над окружением.

FaaS предоставляет более высокий уровень абстракции.

FaaS и Kubernetes

Kubernetes предназначен для оркестрации контейнерных приложений и дает значительно больше контроля над инфраструктурой.

FaaS скрывает большую часть этой сложности.

Если приложение состоит из постоянно работающих сервисов со сложными сетевыми требованиями, Kubernetes может оказаться подходящим вариантом.

Для небольших событийных обработчиков FaaS часто проще.

FaaS и Data Pipeline

Функции можно использовать как отдельные этапы Data Pipeline.

Например, после загрузки файла функция проверяет его формат и записывает метаданные.

Другая функция запускает преобразование или передает сообщение в очередь.

Для очень больших объемов данных тяжелую обработку обычно выполняют специализированные вычислительные системы, а FaaS используют для оркестрации и небольших операций.

FaaS и ETL

Небольшие ETL-задачи можно реализовывать с помощью функций.

Например, функция получает JSON из API, преобразует несколько полей и записывает результат в базу.

Если обработка занимает секунды и запускается нерегулярно, FaaS подходит хорошо.

Для обработки терабайтов данных лучше использовать специализированную Data Engineering-инфраструктуру.

FaaS и Machine Learning

Функция может вызывать уже обученную ML-модель или выполнять небольшую часть inference-процесса.

Например, после загрузки документа функция отправляет текст в классификатор.

Для небольшой модели этого может быть достаточно.

Большие нейросети часто требуют специализированных GPU и постоянно загруженной модели в памяти, поэтому классический FaaS подходит для них хуже.

FaaS и искусственный интеллект

FaaS удобно использовать как интеграционный слой между приложением и AI-сервисами.

Например, после поступления нового обращения функция отправляет его в LLM API и сохраняет классификацию.

При этом необходимо учитывать стоимость внешнего AI API и возможное количество параллельных вызовов.

Автоматическое масштабирование FaaS не означает, что зависимый AI-сервис способен принять неограниченный поток запросов.

FaaS и AI-агенты

Отдельные функции могут использоваться как инструменты AI-агента.

Например, одна функция получает информацию о заказе, другая создает документ, а третья отправляет уведомление.

Агент вызывает только необходимый инструмент.

Для критичных действий необходимо отдельно контролировать права доступа и подтверждение операций.

FaaS и IoT

IoT-устройства могут создавать большое количество небольших событий.

Например, датчик отправляет показание температуры.

Функция получает событие, проверяет значение и при превышении порога отправляет уведомление.

Событийная модель хорошо соответствует нерегулярному потоку данных от устройств.

FaaS для автоматизации

Функции удобны для небольших автоматических задач.

Например, создать запись после получения webhook, отправить сообщение, преобразовать файл или синхронизировать несколько полей между системами.

Для этого не требуется отдельный постоянно работающий сервер.

Поэтому FaaS часто применяется как интеграционный компонент.

Webhook и FaaS

Webhook отправляет HTTP-запрос при наступлении события во внешней системе.

FaaS-функция может принимать этот запрос и выполнять необходимое действие.

Например, платежная система сообщает об успешной оплате, после чего функция обновляет статус заказа.

Следует проверять подлинность webhook, чтобы злоумышленник не мог самостоятельно инициировать операцию.

Idempotency

В распределенных системах одно и то же событие иногда может быть доставлено несколько раз.

Функция должна быть готова к повторной обработке.

Например, повторный webhook оплаты не должен дважды зачислить деньги на внутренний баланс пользователя.

Идемпотентность является одним из наиболее важных принципов надежной FaaS-архитектуры.

Retry

Если функция временно не смогла выполнить операцию, платформа или приложение может повторить вызов.

Например, внешняя база была недоступна несколько секунд.

Retry помогает переживать кратковременные сбои.

Но функция должна учитывать, что предыдущая попытка могла частично выполнить действие.

Dead Letter Queue

Если событие не удается обработать после нескольких попыток, его можно отправить в отдельную очередь ошибок.

Такой механизм часто называют Dead Letter Queue.

Разработчик позже анализирует проблемные события и при необходимости запускает их повторно.

Это надежнее, чем просто потерять сообщение после ошибки.

Оркестрация функций

Иногда бизнес-процесс состоит из нескольких последовательных функций.

Например, получить документ, проверить его, извлечь данные, записать результат и отправить уведомление.

Связывать такую цепочку только прямыми вызовами функции из функции может быть неудобно.

Для сложных процессов используются workflow- и orchestration-механизмы.

FaaS и состояние бизнес-процесса

Поскольку отдельная функция обычно stateless, состояние длительного процесса необходимо хранить отдельно.

Например, обработка заявки проходит пять этапов в течение нескольких часов.

Текущий этап можно хранить в базе или специализированном workflow-сервисе.

Следующая функция получает состояние и продолжает выполнение.

Логирование FaaS

Разработчик не имеет постоянного доступа к конкретному серверу, поэтому централизованные логи особенно важны.

Каждый вызов желательно связывать с уникальным идентификатором.

Это помогает проследить путь запроса через несколько функций.

В логах нельзя сохранять пароли, токены и чувствительные данные без необходимости.

Мониторинг FaaS

Для Serverless-систем полезно контролировать несколько основных показателей.

• количество вызовов;
• время выполнения;
• процент ошибок;
• Cold Start;
• количество параллельных экземпляров;
• таймауты;
• повторные вызовы;
• размер очередей;
• стоимость выполнения.

Обычного мониторинга CPU одного сервера здесь часто недостаточно, потому что физических экземпляров для клиента как постоянных объектов может не быть.

Distributed Tracing

Один пользовательский запрос может последовательно пройти через API Gateway, несколько функций, очередь и базу данных.

Если ответ стал медленным, необходимо понимать, на каком этапе возникла задержка.

Distributed Tracing связывает действия разных компонентов в единую трассу.

Это особенно полезно в Serverless-архитектуре с большим количеством функций.

Безопасность FaaS

Отсутствие управления сервером не означает отсутствие задач безопасности.

Функция может иметь доступ к базам данных, очередям, хранилищам и внешним API.

Если ей выданы избыточные права, компрометация кода может привести к серьезным последствиям.

Следует использовать принцип минимально необходимых полномочий.

Secrets Management

API-ключи и пароли не следует записывать непосредственно в исходный код функции.

Для них используются секрет-хранилища или защищенные настройки окружения.

Функция получает секрет только тогда, когда он ей действительно нужен.

Также необходимо предусматривать регулярную замену ключей.

Зависимости функции

Функция редко состоит из одного небольшого файла.

Она может использовать библиотеки и дополнительные пакеты.

Чем больше размер deployment-пакета, тем дольше может занимать подготовка среды и тем сложнее управление обновлениями.

Поэтому желательно включать только необходимые зависимости.

Версионирование функций

Код функций необходимо хранить в системе контроля версий.

При выпуске новой версии полезно иметь возможность быстро вернуться к предыдущей.

Также желательно понимать, какая версия обрабатывала конкретное событие.

Это облегчает расследование ошибок.

CI/CD для FaaS

Функции хорошо подходят для автоматизированного deployment.

После изменения кода запускаются тесты и сборка.

Если проверки успешно завершены, новая версия публикуется в облачной платформе.

Для production желательно использовать управляемый процесс релиза, а не ручную загрузку кода разработчиком.

Тестирование FaaS

Небольшой размер функции не означает, что ее не нужно тестировать.

Полезно отдельно проверять бизнес-логику и интеграцию с облачными событиями.

Также необходимо тестировать повторную доставку, отсутствие данных, таймауты и недоступность внешних сервисов.

Особенно важно проверять идемпотентность.

Vendor Lock-in

FaaS-функция может зависеть от формата событий, API и сервисов конкретной облачной платформы.

Чем больше специфических интеграций используется, тем сложнее потенциальная миграция.

Однако отказ от всех специфических функций ради переносимости тоже может увеличить стоимость разработки.

Необходимо оценивать этот компромисс для каждого проекта.

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

• не требуется управлять виртуальными серверами;
• автоматическое масштабирование;
• удобная событийная модель;
• быстрый запуск небольших сервисов;
• оплата, связанная с реальным использованием;
• удобство для webhook и интеграций;
• подходит для фоновых задач;
• хорошо сочетается с очередями и облачными сервисами;
• позволяет независимо развертывать отдельные функции.

Недостатки FaaS

FaaS имеет ограничения по времени выполнения, ресурсам и среде запуска.

Cold Start может быть заметен для приложений с очень строгими требованиями к latency.

Большое количество функций усложняет наблюдаемость и локальную отладку.

Также возникает зависимость от механизмов конкретного облачного провайдера.

Основные риски FaaS

Типичные ошибки при использовании FaaS

1. Хранить постоянное состояние на локальном диске функции.
2. Считать, что одно событие всегда приходит только один раз.
3. Не обеспечивать идемпотентность.
4. Запускать слишком длинные задачи.
5. Не ограничивать параллелизм при обращении к базе.
6. Хранить секреты в коде.
7. Не настраивать логирование.
8. Разбивать монолит на слишком большое количество микрофункций.
9. Игнорировать Cold Start.
10. Не контролировать стоимость большого количества вызовов.

Как спроектировать FaaS-функцию

Шаг 1. Определить событие

Нужно четко понимать, что именно запускает функцию.

Шаг 2. Сделать задачу небольшой

Функция должна выполнять понятную и ограниченную операцию.

Шаг 3. Вынести постоянное состояние

Данные сохраняются во внешней базе или хранилище.

Шаг 4. Обеспечить идемпотентность

Повторный вызов не должен создавать некорректный результат.

Шаг 5. Настроить обработку ошибок

Определяются Retry, таймауты и работа с проблемными событиями.

Шаг 6. Ограничить права

Функция получает доступ только к необходимым ресурсам.

Шаг 7. Добавить мониторинг

Контролируются ошибки, latency, количество вызовов и стоимость.

Шаг 8. Провести нагрузочное тестирование

Необходимо проверить, как ведут себя функция и связанные системы при массовом параллельном запуске.

Практический пример

Интернет-магазин позволяет поставщикам загружать фотографии товаров.

Количество изображений непредсказуемо: иногда в течение часа не загружается ни одного файла, а иногда поставщик отправляет несколько тысяч изображений.

Создавать отдельный постоянно работающий сервер для обработки фотографий невыгодно.

Компания использует FaaS. Каждая загрузка объекта в хранилище генерирует событие.

Функция получает изображение, проверяет его формат, создает уменьшенную копию и записывает результат.

Если одновременно загружается много файлов, платформа запускает дополнительные экземпляры функции.

Количество параллельных вызовов ограничено, чтобы не перегружать сервис хранения метаданных.

Ошибочные изображения помещаются в отдельную очередь для последующего анализа.

В результате система автоматически масштабируется под фактический поток файлов, а отдельный постоянно работающий сервер для этой задачи не требуется.

Когда FaaS особенно полезен

FaaS хорошо подходит для коротких событийных операций с нерегулярной нагрузкой.

Это обработка webhook, файлов, сообщений очереди, фоновые задачи, простые API и периодические процессы.

Модель особенно удобна, если функция может быть stateless и выполняется относительно быстро.

В таких сценариях разработчик получает значительную автоматизацию инфраструктуры.

Когда FaaS может не подойти

FaaS не всегда удобен для постоянно работающих процессов, длительных вычислений или приложений со сложным локальным состоянием.

Также модель может быть неудобна при необходимости глубокого контроля операционной системы или специализированного оборудования.

Для стабильной высокой нагрузки контейнер, PaaS или IaaS иногда оказывается проще и экономичнее.

Архитектуру необходимо выбирать исходя из характера задачи, а не из популярности Serverless.

FaaS и бизнес-ценность

Главное преимущество FaaS для бизнеса заключается в возможности запускать небольшие вычислительные задачи без создания отдельной постоянно работающей инфраструктуры.

Это ускоряет разработку интеграций и автоматизаций.

Команда меньше времени тратит на обслуживание серверов и может быстрее запускать новые функции продукта.

При этом эффективность зависит от правильной архитектуры, контроля стоимости и надежной обработки повторных событий.

Связанные термины

Краткий итог

FaaS — модель облачных вычислений, при которой разработчик размещает отдельные функции, запускаемые автоматически по событиям. Облачный провайдер управляет вычислительной инфраструктурой, средой выполнения и масштабированием.

FaaS является одним из основных подходов Serverless Computing. Он особенно хорошо подходит для webhook, обработки файлов, очередей, небольших API, фоновых задач и событийных интеграций.

Ключевыми особенностями FaaS являются stateless-подход, автоматическое масштабирование, событийная модель и оплата, связанная с использованием ресурсов. При этом необходимо учитывать Cold Start, ограничения времени выполнения, повторную доставку событий и нагрузку на зависимые системы.

FaaS дает разработчику высокий уровень абстракции от инфраструктуры, но не отменяет задачи архитектуры, безопасности, мониторинга и контроля затрат. Наибольшую пользу модель приносит тогда, когда задача действительно короткая, событийная и не требует постоянно работающего сервера.