Serverless снимает с разработчика управление серверами: нет инстансов, которые надо патчить и масштабировать, — платишь только за выполнение. Но это не «бесплатная магия»: у модели свои ограничения и свои случаи, где она проигрывает. Вычисления дали место Lambda среди вариантов; здесь — как serverless устроен и когда его берут.

Событийная модель

Lambda — функция, которая запускается в ответ на событие и живёт только время обработки. Источников события много: HTTP-запрос (через API Gateway), сообщение в очереди (SQS), запись в DynamoDB Streams, файл в S3, расписание, событие шины (EventBridge). Это и есть суть serverless: не «сервис, который ждёт», а «код, который вызывается, когда есть что обработать».

Отсюда сильная сторона — масштабирование от нуля до тысяч параллельных вызовов автоматически, без ASG и балансировщиков, и оплата строго за выполнение. Спайковая и событийная нагрузка — родная стихия Lambda.

Cold start

Главное ограничение, про которое всегда спрашивают. Когда вызовов нет, среда выполнения «остывает»; следующий вызов требует поднять её заново — скачать код, запустить рантайм, выполнить инициализацию. Эта задержка — cold start — добавляется к первому запросу.

Как снижают:

  • Provisioned concurrency — держать заданное число «тёплых» сред наготове (за это платят).
  • Меньше пакет и зависимости — быстрее загрузка.
  • Лёгкий рантайм — у тяжёлых рантаймов cold start особенно заметен (старт самого рантайма плюс инициализация контекста), поэтому для latency-критичных API на них serverless выбирают осторожнее — граница тяжёлых рантаймов разобрана отдельно.

Cold start терпим для фоновой/событийной обработки и неприятен для синхронных API с жёстким SLA — это и есть один из критериев выбора.

API Gateway и Step Functions

Две части, дополняющие Lambda:

  • API Gateway — управляемый HTTP-фасад перед Lambda: маршрутизация, аутентификация, ограничение частоты, версии. Превращает функции в полноценный API без своего веб-сервера.
  • Step Functions — оркестрация многошаговых процессов: последовательность/ветвление/повторы/ожидание между несколькими Lambda как машина состояний. Когда процесс — это «шаг 1 → шаг 2 → при ошибке откат», Step Functions держат логику явной и наблюдаемой, вместо самодельной цепочки вызовов.

Когда serverless, а когда нет

Граница, ради которой статья:

  • Оправдан — событийная и спайковая нагрузка, нерегулярные задачи, склейка сервисов, фон; когда «платить за простой» обидно, а масштаб непредсказуем.
  • Не оправдан — постоянная высокая нагрузка (дешевле и предсказуемее контейнеры/инстансы), долгие задачи (есть лимит времени выполнения), жёсткие требования к задержке первого запроса на тяжёлом рантайме, сложное локальное состояние.

Serverless — инструмент под класс задач, не замена всему. «Всё на Lambda» так же ошибочно, как «ничего на Lambda».

Где это в UCP

Serverless добавляет к вычислениям AWS событийную модель с оплатой за выполнение и авто-масштабированием от нуля — ценой cold start и лимитов. Для backend-разработчика практический вывод: serverless берут под событийное и спайковое, а постоянную нагрузку и latency-критичное оставляют инстансам/контейнерам; выбор делают осознанно, по характеру нагрузки. Это та же логика «инструмент под задачу», что и выбор хранилища или уровня зрелости — и ею замыкается раздел про AWS.