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

Azure Functions

Azure Functions — функция как единица развёртывания. Вы пишете обработчик (на C#, Java, Python, Node.js и др.), загружаете — и всё. Ни машины, ни контейнера: облако поднимает окружение под вызов и гасит, когда обращений нет.

Функция всегда устроена одинаково: пришло событие → функция отработала → вернула результат. Она не «крутится» постоянно, а оживает на каждый вызов. Аналог AWS Lambda.

Когда удобно: небольшие обработчики и склейки — реакция на загруженный файл, обработчик вебхука, периодическая задача, лёгкий API. То, что не хочется превращать в постоянно включённый сервис.

Триггеры: что запускает функцию

Функцию нужно чем-то вызвать — это триггер. В Azure функцию можно повесить на разные события:

  • HTTP — вызов по сети (напрямую или через API Management);
  • Queue Storage / Service Bus — пришло сообщение в очередь → функция его обработала;
  • Blob Storage — в хранилище загрузили файл → функция сработала;
  • Timer — по расписанию (cron);
  • Event Grid / Event Hubs — реакция на события платформы и потоки данных.

Триггеры делают serverless удобным для событийной обработки: вы не пишете цикл «проверь, не появилось ли новое», а говорите «на такое событие запусти вот эту функцию». Рядом есть привязки (bindings) — декларативный способ получить вход и записать выход (например, «прочитать из очереди, записать в таблицу») без ручного кода подключения.

Durable Functions

Обычная функция коротка и без состояния. Когда нужен процесс из нескольких шагов с ожиданием и состоянием — оформление заказа, цепочка обработки, — есть Durable Functions: расширение, которое позволяет описывать оркестрацию (последовательности, ветвления, ожидания) в коде, а состояние между шагами Azure хранит за вас. Это ответ на задачи, где иначе пришлось бы вручную городить машину состояний.

API Management

Когда функций и сервисов много, перед ними ставят API Management — единый шлюз: маршрутизация, авторизация, ограничение частоты запросов, версионирование API, единая точка для внешних потребителей. Типичная бессерверная связка: API Management принимает запросы → направляет в Azure Functions или Container Apps → те читают и пишут в Cosmos DB или Blob Storage, а фоновые задачи идут через Service Bus.

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

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

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

Лимиты. У функции ограничены время работы и память. Долгие тяжёлые вычисления — не про Functions; для такого берут контейнеры или машины. И функция stateless: любое состояние держат во внешнем хранилище — Cosmos DB, управляемой базе или Blob Storage.

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

Serverless силён там, где нагрузка нерегулярная и событийная: обработчики загрузок, вебхуки, задачи по расписанию, лёгкие API, склейки между сервисами. Платить за постоянно включённую машину ради редких вызовов невыгодно — здесь платят строго за факт.

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

  • тянут в функцию тяжёлую и долгую логику — упираются в лимиты;
  • не учитывают холодный старт в чувствительном к задержке API;
  • хранят состояние в памяти функции — оно теряется между вызовами;
  • делают из функций монолит — разросшуюся логику пора переносить в контейнер.

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