Альтернатива AWS Lambda: serverless на контейнерах

AWS Lambda доказала, что serverless — правильный дефолт для огромного класса бэкенд-работы: не надо патчить серверы, платишь за запуск, масштабируешься до нуля. Если вы ищете альтернативу AWS Lambda, то обычно не потому, что сама идея неверна, — а потому, что модель упаковки и эксплуатации вокруг Lambda начала мешать. Эта статья — честный взгляд на то, что толкает команды искать другое, что меняет альтернатива на контейнерах и — не менее важно — чего она не меняет.

Что на самом деле отправляет людей искать альтернативу Lambda

Редко это модель оплаты. Это трение:

• Танцы с упаковкой. Нативные зависимости означают zip-файлы, слои и классику «работает у меня, Error: cannot find module в облаке». Слои Lambda помогают, но приходят со своими лимитами (250 МБ распакованного суммарно по слоям) и своим билд-тулингом.
• Потолок рантайма. Всё, что требует системную библиотеку, headless-браузер, ONNX-модель или бинарник, который вы дёргаете, воюет с моделью деплой-пакета.
• Каждый кусок — отдельный сервис. Функция — это Lambda, HTTP-фронт — API Gateway, очередь — SQS, расписание — EventBridge, логи — CloudWatch, права — IAM. Связать пять сервисов с правильными ролями ради одного эндпоинта — много возни для «запусти этот код, когда придёт запрос».
• Дрейф local-to-prod. Воспроизвести окружение Lambda локально — отдельная индустрия.

Ничто из этого не значит, что Lambda плоха. Это значит, что для многих команд побочная сложность перевешивает существенную работу, и они начинают искать что-то с меньшей церемонией.

Что меняет альтернатива на контейнерах

Inquir сохраняет идею serverless — задеплой функцию, получи HTTP-эндпоинт, масштабируйся автоматически, — но запускает каждую функцию в своём контейнере, а не в песочнице zip-пакета. Это одно изменение убирает большую часть трения выше:

• Нативные зависимости просто работают. Поскольку это настоящий контейнер с полным рантаймом языка, вы используете нативные модули, системные библиотеки и тяжёлые пакеты без ритуала упаковки слоёв. Общие зависимости подключаются слоями для Node, Python или Go и разрешаются во время вызова, а не перезаливаются под каждую функцию.
• Шлюз, секреты, расписания и наблюдаемость — одна платформа. Авторизация на уровне маршрута (API-ключи или bearer), секреты на функцию как переменные окружения, cron-триггеры, фоновые задачи и трассы исполнения — часть одного продукта, а не пять сервисов, связанных через IAM.
• Три настоящих рантайма, смешиваемых. Node.js 22, Python 3.12 и Go 1.22 за одним шлюзом; выбирайте под функцию, смешивайте свободно.
• Деплой из браузера. Правьте и выкатывайте функцию из веб-IDE — удобно для быстрой правки без полного локального тулчейна, наряду с CLI и CI/CD.

Ментальная модель сжимается с «свяжи Lambda + API Gateway + SQS + EventBridge + CloudWatch + IAM» до «задеплой функцию, дай ей маршрут, читай её секреты, смотри её трассы».

Честно о лимитах, которые она не убирает

Альтернатива, перечисляющая только плюсы, — маркетинг, а не инженерия. Две вещи стоит сказать прямо, потому что они одинаковы на любой ответственной serverless-платформе:

• Холодные старты не нулевые. Функции на контейнерах скрывают холодные старты горячими/тёплыми пулами (тёплый пул на функцию, min 1 до 8, так что устойчивый трафик остаётся тёплым), но первый вызов после деплоя или после простоя всё равно платит холодный путь. Если конкретный эндпоинт критичен по задержке — держите его тёплым, не ждите магии.
• Есть лимит времени на вызов. У каждой функции или шага есть таймаут (5 с по умолчанию, до 15 минут максимум). «Serverless без таймаута» — нигде не реальность. Правильный паттерн для долгой работы тот же, каким он должен был быть на Lambda: быстро подтвердить, затем выполнить долгую часть устойчивой фоновой задачей с ретраями и dead-letter, а не держать один запрос открытым час.

Если вашей нагрузке действительно нужен один процесс, работающий часами с постоянным сокетом, — это не форма serverless-функции ни на одной платформе, это сервис, и запускать его надо как сервис.

Когда Lambda всё ещё правильный ответ

Хорошая альтернатива говорит, когда не стоит переходить:

• Вы глубоко в экосистеме AWS, и ваши функции — склейка между сервисами AWS (стримы DynamoDB, события S3, Step Functions). Гравитация «остаться там, где уже живут ваши данные и события» реальна и заслуживает уважения.
• Вам нужна конкретная интеграция AWS — источник триггера или граница комплаенса, которую даёт только нативный сервис.
• Весь тулчейн команды уже AWS-нативный, и побочную сложность вы уже оплатили.

Смена платформы стоит денег. Делайте это, когда трение, от которого вы бежите, больше миграции.

Как выглядит миграция на практике

Хорошая новость: хендлер Lambda и хендлер Inquir — близкие родственники. Шлюз передаёт событие в стиле API Gateway (httpMethod, path, headers, queryStringParameters, body строкой), а вы возвращаете { statusCode, body } или голый JSON:

export async function handler(event) {
  const body = JSON.parse(event.body ?? '{}');
  // ваша существующая логика, почти без изменений
  return { statusCode: 200, body: JSON.stringify({ ok: true }) };
}

Большая часть миграции — это удаление: скриптов сборки слоёв, JSON с IAM-ролями, обвязки API Gateway, boilerplate консьюмера SQS. Логика хендлера в основном выживает; пламбинг вокруг неё заменяется возможностями платформы.

Итог

Причина хотеть альтернативу AWS Lambda почти никогда не «serverless был ошибкой». Она в том, что модель упаковки, потолок рантайма и налог «пять сервисов ради одного эндпоинта» сложились. Платформа на контейнерах сохраняет то, что было правильно, — задеплой функцию, получи эндпоинт, масштабируйся автоматически, — и убирает церемонию: нативные зависимости без танцев со слоями, одна платформа вместо шести сервисов, три рантайма за одним шлюзом.

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