Serverless (буквально «без серверов») — это модель, где вы отдаёте облаку код, а оно само решает, где и когда его запустить. Серверы, конечно, существуют, но вы про них не думаете: не выбираете машину, не следите за загрузкой, не платите за простой. Платите только за фактические вызовы. Разберём, как это устроено в Yandex Cloud и когда подходит. Если вы ещё не выбирали, где запускать сервис, — Cloud Functions это один из четырёх вариантов оттуда, здесь мы копаем его глубже.
Cloud Functions
Cloud Functions — это функция как единица развёртывания. Вы пишете обработчик (на Python, Node.js, Go, Java и других языках), загружаете его — и всё. Ни машины, ни контейнера: облако само поднимает окружение под вызов и гасит, когда обращений нет.
Функция всегда устроена одинаково: пришло событие → функция отработала → вернула результат. Она не «крутится» постоянно, а оживает на каждый вызов. Аналог AWS Lambda.
Когда это удобно: небольшие обработчики и склейки — реакция на загруженный файл, обработчик вебхука, периодическая задача по расписанию, лёгкий API. То, что не хочется превращать в постоянно включённый сервис.
Триггеры: что запускает функцию
Функция сама по себе ничего не делает — её нужно чем-то вызвать. Это триггер. В Yandex Cloud функцию можно повесить на разные события:
- HTTP — функция вызывается по сети (напрямую или через API Gateway, о нём ниже);
- Message Queue — пришло сообщение в очередь → функция его обработала;
- Object Storage — в бакет загрузили файл → функция сработала (например, сделать превью картинки);
- Таймер — по расписанию (cron), для периодических задач;
- YDB и другие — изменения в базе и события других сервисов.
Именно триггеры делают serverless удобным для событийной обработки: вы не пишете цикл «проверь, не появилось ли новое», а просто говорите «на такое событие запусти вот эту функцию».
API Gateway
Когда функций и обработчиков становится несколько, перед ними ставят API Gateway — единую HTTP-точку входа. Вы описываете маршруты (по спецификации OpenAPI): какой путь и метод в какую функцию или контейнер направить. Gateway берёт на себя маршрутизацию, авторизацию, отдачу статики и связывает разрозненные функции в цельный API.
Типичная бессерверная связка выглядит так: API Gateway принимает запросы → направляет в Cloud Functions или Serverless Containers → те читают и пишут в YDB или Object Storage, а фоновые задачи ходят через Message Queue. Ни одной постоянно включённой машины.
Холодный старт и ограничения
За удобство serverless платят двумя особенностями, которые надо знать заранее.
Холодный старт (cold start). Если функцию давно не вызывали, окружение под неё погашено, и первый вызов ждёт, пока оно поднимется, — это лишние сотни миллисекунд, иногда больше. Последующие вызовы, пока функция «тёплая», идут быстро. Для фоновых задач это не важно, для чувствительного к задержке API — важно.
Лимиты. У функции ограничены время работы и память. Долгие тяжёлые вычисления, обработка гигабайтных файлов в памяти, процессы на часы — это не про Cloud Functions. Для такого берут контейнеры или виртуальные машины.
Ещё одно следствие модели: функция stateless — между вызовами она ничего не помнит. Любое состояние (счётчики, сессии, промежуточные данные) держат во внешнем хранилище: YDB, управляемой базе или объектном хранилище.
Где это применяется
Serverless силён там, где нагрузка нерегулярная и событийная: обработчики загрузок, вебхуки, задачи по расписанию, лёгкие API, склейки между сервисами. Платить за постоянно включённую машину ради редких вызовов невыгодно — здесь платят строго за факт.
Типичные ошибки новичков:
- тянут в функцию тяжёлую и долгую логику — упираются в лимиты времени и памяти;
- не учитывают холодный старт в API, чувствительном к задержке;
- хранят состояние в памяти функции — оно теряется между вызовами;
- делают из функций монолит — когда логика разрослась в полноценный сервис с базой и сложным жизненным циклом, это сигнал переезжать в контейнер.
Что учить дальше: где функции хранят данные — в управляемых базах и YDB; как устроен обычный (не бессерверный) способ запуска — в статье про вычисления. Та же модель есть в AWS — сравните с разбором serverless в AWS.