Serverless (буквально «без серверов») — модель, где вы отдаёте облаку код или контейнер, а оно само решает, где и когда его запустить. Серверы существуют, но вы про них не думаете: не выбираете машину, не следите за загрузкой, не платите за простой. Платите за фактические вызовы. У GCP serverless особенно силён — разберём, как он устроен. Если вы ещё не выбирали, где запускать сервис, — Cloud Run и Cloud Functions это варианты оттуда, здесь мы копаем их глубже.

Cloud Run

Cloud Run — визитная карточка serverless в GCP: вы отдаёте контейнер (или даже просто код, который Cloud Run сам соберёт в образ), а облако запускает его по запросу и масштабирует, вплоть до нуля при отсутствии обращений. Кластер держать не нужно.

Ключевое отличие от «функций»: Cloud Run запускает обычный веб-сервис в контейнере — то есть вы пишете привычное приложение (например, на Spring Boot), которое слушает HTTP-порт, а не специальную функцию-обработчик. Это делает Cloud Run естественным выбором для большинства сервисов: минимум ограничений, знакомая модель, оплата по факту.

Cloud Functions

Cloud Functions — код без сервера в виде функции: вы пишете обработчик, загружаете — и всё. Функция оживает на каждое событие: пришло событие → функция отработала → вернула результат. Аналог AWS Lambda.

Когда что: Cloud Functions удобны для маленьких событийных обработчиков (реакция на файл, вебхук, задача по расписанию); Cloud Run — когда это уже полноценный сервис или нужен свой контейнер и окружение. Граница размыта, и на практике многие делают всё на Cloud Run.

Триггеры и Eventarc

Функцию или сервис нужно чем-то вызвать — это триггер:

  • HTTP — вызов по сети (напрямую или через API Gateway);
  • Pub/Sub — пришло сообщение в тему → сработал обработчик;
  • Cloud Storage — в бакет загрузили файл → сработал обработчик;
  • Cloud Scheduler — по расписанию (cron).

Отдельно стоит Eventarc — единая система маршрутизации событий: она доставляет в Cloud Run и Cloud Functions события от множества сервисов Google по стандартному формату. Это позволяет строить событийные системы, где сервисы реагируют на изменения в облаке, не опрашивая его вручную.

API Gateway

Когда сервисов и функций много, перед ними ставят API Gateway — единую HTTP-точку входа: маршрутизация, авторизация, ограничение частоты запросов, версионирование API. Типичная бессерверная связка: API Gateway принимает запросы → направляет в Cloud Run или Cloud Functions → те читают и пишут в Firestore или Cloud Storage, а фоновые задачи идут через Pub/Sub.

Холодный старт и ограничения

За удобство serverless платят двумя особенностями.

Холодный старт (cold start). Если сервис давно не вызывали и он масштабировался до нуля, первый вызов ждёт, пока поднимется экземпляр, — лишние сотни миллисекунд. Последующие «тёплые» вызовы быстры. Для фоновых задач не важно, для чувствительного к задержке API — важно (тогда задают минимальное число всегда готовых экземпляров).

Лимиты и stateless. У Cloud Functions ограничены время работы и память (у Cloud Run лимиты мягче); любое состояние держат во внешнем хранилище — Firestore, управляемой базе или Cloud Storage, потому что экземпляр в любой момент могут погасить и поднять заново.

Где это применяется

Serverless в GCP силён широтой: от простых обработчиков (Cloud Functions) до полноценных сервисов в контейнерах (Cloud Run) — всё масштабируется до нуля и тарифицируется по факту. Это делает Cloud Run разумным выбором по умолчанию для большинства backend-сервисов, а не только для «событийной склейки».

Типичные ошибки новичков:

  • тянут в Cloud Functions тяжёлую и долгую логику — упираются в лимиты (для такого — Cloud Run или машина);
  • не учитывают холодный старт в чувствительном к задержке API;
  • хранят состояние в памяти экземпляра — оно теряется между вызовами;
  • поднимают GKE там, где хватило бы Cloud Run — лишняя эксплуатация.

Что учить дальше: где сервисы хранят данные — в управляемых данных и Firestore; обычные способы запуска — в статье про вычисления. Та же модель в AWS — serverless в AWS.