Serverless — одно из тех слов, которые все слышали, но половина не может объяснить толком. Звучит как «без сервера», хотя серверы никуда не делись — просто ты о них больше не думаешь. Ты пишешь функцию, деплоишь, и она работает. Сколько пользователей пришло — столько раз и запустилась. Заплатил только за реальные вызовы.

Для API это меняет многое. Не нужно держать VPS, настраивать Nginx, беспокоиться о масштабировании под нагрузку. Но есть нюансы, из-за которых serverless подходит не всегда — и об этом тоже поговорим.

Как это работает вообще

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

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

Это накладывает ограничения, но и даёт преимущества:

  • Автоматический скейлинг. Пришло 10 000 запросов одновременно — запустилось 10 000 копий функции.
  • Оплата за использование. Нет трафика — ничего не платишь.
  • Меньше DevOps. Не нужно следить за апдейтами ОС, настраивать балансировщик, думать про CPU-лимиты.

AWS Lambda: мощь с оговорками

Lambda — флагман serverless от Amazon. Появилась в 2014 году и с тех пор стала де-факто стандартом в enterprise-мире.

Как устроена

Ты пишешь функцию на одном из поддерживаемых языков: Node.js, Python, Go, Java, Ruby, .NET, и даже можешь запаковать свой runtime через Lambda Layers. Упаковываешь в ZIP или Docker-образ, деплоишь. AWS сам управляет запуском, масштабированием и завершением.

Для API чаще всего используют связку Lambda + API Gateway. API Gateway принимает HTTP-запросы и проксирует их в Lambda. Это добавляет задержку (10–30 мс) и стоимость, но даёт маршрутизацию, авторизацию, троттлинг прямо из коробки.

Альтернатива — Lambda Function URLs (появилась в 2022). Это прямой HTTPS-эндпоинт к функции без API Gateway. Проще, дешевле, но без возможностей Gateway.

Цены Lambda

Модель оплаты:

  • Запросы: первые 1 млн в месяц бесплатно, дальше $0.20 за каждый миллион.
  • Время выполнения: считается в GB-секундах. 1 млн секунд на 128 МБ памяти стоит около $2.08. Первые 400 000 GB-секунд в месяц бесплатно.

Если функция выполняется 100 мс и у тебя 10 млн запросов в месяц — это примерно $2–5 в месяц только за Lambda. API Gateway добавит ещё $3.50 за миллион запросов.

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

Холодный старт — главная боль

Когда функцию не вызывали какое-то время, контейнер «засыпает». При следующем запросе AWS должен его поднять заново — это называется cold start. Время варьируется:

  • Node.js / Python: 100–500 мс
  • Java / .NET: 1–5 секунд
  • Docker-контейнеры: до 10+ секунд

Для API это критично. Пользователь нажал кнопку и ждёт секунду, прежде чем что-то произошло — неприятно.

Как бороться:

  • Provisioned Concurrency — AWS держит N копий функции всегда прогретыми. Стоит дополнительно, но убирает холодный старт.
  • Пинговать функцию раз в несколько минут (костыль, но рабочий).
  • Выбирать лёгкие рантаймы — Node.js и Python стартуют быстрее Java.
  • Минимизировать размер бандла и число зависимостей.

Ограничения Lambda

  • Максимальное время выполнения: 15 минут. Для API это не проблема, но для тяжёлых вычислений — да.
  • Максимальный размер пакета: 50 МБ ZIP, 10 ГБ Docker.
  • Параллельные выполнения по умолчанию: 1 000 на аккаунт (можно поднять).
  • Нет постоянного файлового хранилища (только /tmp до 10 ГБ, но оно не гарантировано между вызовами).

Cloudflare Workers: скорость на первом месте

Cloudflare Workers — другой подход. Функции запускаются не в изолированных контейнерах, а в V8 Isolates — той же технологии, которая лежит в основе Chrome и Node.js. Это принципиально меняет картину.

Почему Workers быстрее

V8 Isolate запускается за 0–5 миллисекунд. Холодного старта практически нет. Это не преувеличение маркетинга — реальное техническое преимущество. Контейнер поднять дорого, а V8 Isolate — почти бесплатно по времени.

Второе преимущество — глобальная сеть. Cloudflare имеет точки присутствия в 300+ городах. Функция выполняется на ближайшем к пользователю сервере. Запрос из Москвы обработает московская точка, а не дата-центр в Вирджинии.

Для API это значит реально низкую задержку — 10–50 мс до первого байта из любой точки мира.

Что умеют Workers

Workers поддерживают JavaScript и TypeScript нативно, плюс любой язык через WebAssembly: Rust, C, Python (через Pyodide), Go и другие.

Встроенные возможности:

  • KV — key-value хранилище с глобальной репликацией (eventual consistency).
  • Durable Objects — хранилище с сильной консистентностью, подходит для чатов, игр, коллаборативных приложений.
  • R2 — объектное хранилище, совместимое с S3 API, без платы за исходящий трафик.
  • D1 — SQLite-база данных прямо в Workers.
  • Queues — очереди сообщений.

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

Цены Workers

  • Free plan: 100 000 запросов в день. Для небольших проектов — бесплатно.
  • Paid ($5/мес): 10 млн запросов включено, дальше $0.30 за миллион. Плюс CPU-время: $0.02 за 1 млн ms CPU.

KV: первые 10 млн операций чтения в месяц бесплатно на платном плане. D1: первые 5 млн строк чтения в день бесплатно.

Для большинства API-проектов $5/мес покрывает реальные нужды с запасом.

Ограничения Workers

  • Время выполнения: 30 секунд на HTTP-запрос, до 15 минут для Cron-задач.
  • CPU-время на запрос: до 30 секунд на платном плане.
  • Нет доступа к файловой системе (только встроенные хранилища).
  • Нет Node.js API в полном объёме — Workers запускаются не в Node, а в V8 runtime с ограниченным API. Многие npm-пакеты не работают без полифиллов.
  • Память: 128 МБ на Worker.

Lambda vs Workers: когда что брать

Эти два инструмента не конкуренты в полном смысле — они хорошо решают разные задачи.

Бери AWS Lambda если:

  • Уже используешь AWS-стек (S3, RDS, SQS, SNS) — интеграция нативная.
  • Нужен Python с тяжёлыми библиотеками (pandas, numpy, ML-фреймворки).
  • Долгие операции — обработка файлов, видео, тяжёлые вычисления.
  • Нужен Java или .NET.
  • Требуется доступ к ресурсам внутри VPC (базы данных, внутренние сервисы).

Бери Cloudflare Workers если:

  • Критична низкая задержка — edge-вычисления рядом с пользователем.
  • API на TypeScript/JavaScript.
  • Нужна простота — один инструмент вместо Lambda + API Gateway + IAM.
  • Глобальная аудитория: пользователи из разных стран.
  • Прокси, трансформация запросов, A/B тесты на уровне CDN.

Практический пример: REST API для приложения

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

На Workers + D1:

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    
    if (url.pathname === '/api/products' && request.method === 'GET') {
      const { results } = await env.DB.prepare(
        'SELECT id, name, price FROM products WHERE active = 1 LIMIT 50'
      ).all();
      
      return Response.json(results);
    }
    
    return new Response('Not found', { status: 404 });
  }
};

Деплой: wrangler deploy. Всё. Никаких API Gateway, никаких IAM-политик, никаких VPC.

На Lambda (Node.js):

export const handler = async (event) => {
  const path = event.rawPath;
  
  if (path === '/api/products' && event.requestContext.http.method === 'GET') {
    // подключение к RDS или DynamoDB
    const products = await db.query(
      'SELECT id, name, price FROM products WHERE active = 1 LIMIT 50'
    );
    
    return {
      statusCode: 200,
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(products)
    };
  }
  
  return { statusCode: 404, body: 'Not found' };
};

Нужно ещё: настроить Lambda Function URL или API Gateway, IAM-роли, переменные окружения, VPC если база в AWS. Больше шагов, но и больше возможностей.

Типичные ошибки при переходе на serverless

Хранить состояние в памяти. Классика. Кладёшь что-то в глобальную переменную, а следующий запрос попадает в другой инстанс. Состояние — только во внешнем хранилище: Redis, DynamoDB, KV, D1.

Не думать о холодном старте. Добавил 30 npm-пакетов — получил 2 секунды инициализации. Следи за размером бандла, используй tree shaking, не тащи всё подряд.

Забыть про таймауты на внешние запросы. В serverless-функции нет смысла ждать 30 секунд ответа от базы — запрос пользователя давно упал по таймауту. Ставь агрессивные таймауты на все внешние вызовы.

Не учитывать стоимость при росте. Serverless дёшево стартует, но при высокой нагрузке может обойтись дороже выделенного сервера. Считай заранее при проектировании.

Игнорировать observability. В serverless нет логов сервера по умолчанию. Настраивай CloudWatch для Lambda или Workers Logpush для Cloudflare сразу, иначе отладка превратится в угадайку.

Когда serverless не нужен

Serverless — не серебряная пуля. Есть задачи, где он проигрывает:

  • WebSocket-соединения. Lambda не держит постоянное соединение, хотя AWS API Gateway WebSocket это костылит. Workers с Durable Objects справляются лучше.
  • Тяжёлые вычисления с GPU. Lambda поддерживает только CPU. Для ML-инференса нужны другие сервисы.
  • Очень высокочастотные запросы с постоянной нагрузкой. Если у тебя 10 000 req/s 24/7 — посчитай стоимость serverless против зарезервированных инстансов.
  • Сложная оркестрация. Если функция должна вызывать 10 других функций в определённом порядке — это можно сделать через Step Functions, но сложность растёт быстро.

Как вписать serverless в реальный проект

Не обязательно переписывать всё сразу. Serverless хорошо заходит как дополнение к существующей архитектуре:

  • Вебхуки от платёжных систем — идеальный кейс. Приходит редко, нагрузка непредсказуема.
  • Генерация отчётов по расписанию.
  • Ресайз изображений при загрузке.
  • Прокси для трансформации данных между сервисами.

Такой подход «по кусочкам» снижает риски и позволяет нащупать, где serverless реально даёт преимущество именно в твоём случае.

В REEXY при разработке интеграций и API мы нередко предлагаем клиентам serverless-решения — особенно когда нагрузка нерегулярная или нужен быстрый старт. Это снижает стоимость владения и убирает операционную нагрузку. Подробнее об интеграции сервисов можно посмотреть на r3xy.ru.

Быстрый старт без боли

Если хочешь попробовать Workers прямо сейчас:

npm install -g wrangler
wrangler login
wrangler init my-api
cd my-api
wrangler dev  # локальная разработка
wrangler deploy  # деплой

За 10 минут получишь рабочий API на глобальной инфраструктуре.

Для Lambda через AWS SAM:

npm install -g aws-sam-cli
sam init --runtime nodejs20.x
sam local start-api  # локально
sam deploy --guided  # деплой

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

Serverless API в 2026 году — это зрелая технология, не эксперимент. Cloudflare Workers и AWS Lambda закрывают большинство задач, с которыми приходит типичный продуктовый проект. Ключ — понять, где у тебя нагрузка, какой стек уже используешь и насколько критична задержка. С этим пониманием выбор между ними делается быстро.