Что такое serverless? Бессерверные вычисления простыми словами

Serverless — это способ запускать код, при котором вам не нужно создавать и обслуживать серверы. Вы передаёте код облачному провайдеру, и он выполняет его только тогда, когда что-то его запускает: веб-запрос, загруженный файл, уведомление об оплате. Затем всё останавливается. Как правило, вы платите за время, в течение которого код действительно работает, а не за машину, которая простаивает.

Почему serverless важен при создании приложений с ИИ

Когда вы создаёте приложение с ИИ и смотрите варианты хостинга или код, вам встретятся «serverless-функции», «edge-функции» или «облачные функции». Многие хостинговые платформы их предлагают, а некоторые ИИ-конструкторы развёртывают бэкенд именно так. Понимание модели помогает с тремя практическими вопросами:

• Стоимость. Будет ли приложение стоить денег, когда им никто не пользуется?
• Скорость. Почему первый запрос после тихого периода медленнее?
• Ограничения. Почему долгая задача — генерация большого отчёта, обработка видео — прервалась по таймауту?

Полезно также понимать, чем serverless не является: это не отсутствие бэкенда. У вас по-прежнему есть серверный код; просто машины запускает кто-то другой. Основы см. в статье что такое сервер.

Бытовая аналогия

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

Serverless похож на вызов такси. Вы платите только за поездки, которые совершили, и если сто человек одновременно захотят ехать, приедут сто машин. Но машину иногда приходится подождать (это и есть холодный старт), у каждой поездки есть максимальная длина, а водитель не помнит вас с прошлой поездки (функции без состояния).

Как работают serverless-функции

В самой распространённой форме, которая называется functions as a service (функции как сервис):

1. Вы пишете функцию — небольшой фрагмент кода, который обрабатывает один тип события, например «обработать POST на /api/bookings».
2. Вы разворачиваете её. Провайдер сохраняет её и связывает с триггером: URL, расписанием, новым файлом в хранилище, сообщением в очереди.
3. Приходит событие. Провайдер запускает копию вашей функции (или использует уже «прогретую»), выполняет её и возвращает результат.
4. Она масштабируется сама. Если одновременно приходит тысяча запросов, провайдер запускает множество копий параллельно, в пределах лимитов вашего аккаунта.
5. Она простаивает. Когда трафик прекращается, копии выключаются. Если ничего не работает, вы не платите за вычисления.

Крошечная serverless-функция на JavaScript может выглядеть так:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

Здесь нет кода, который запускает сервер, открывает порт или держит процесс запущенным. Всё это делает платформа.

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

Термины

Пример: небольшой сайт записи в студию йоги

Сайт студии йоги получает всплеск посещений каждое воскресенье вечером, когда выкладывается новое расписание, и почти ничего в остальные дни недели.

• На сервере, который работает всё время, студия платит за машину 24/7, рассчитанную на пик воскресного вечера, и в остальное время она почти простаивает.
• С serverless-функциями GET /api/classes и POST /api/bookings — это функции. Воскресный наплыв автоматически запускает много копий; в тихий вторник утром почти ничего не работает, и счёт близок к нулю.

Компромиссы тоже есть. Первый человек, который открывает сайт во вторник утром, может подождать чуть дольше из-за холодного старта. База данных должна выдерживать много коротких подключений от многих копий функций, и может понадобиться пул подключений. А если студия потом захочет задачу «сформировать годовой PDF с посещаемостью для всех», она может превысить таймаут функции и потребовать запуска в другом месте.

Когда serverless подходит, а когда нет

Распространённые заблуждения

• «Serverless означает отсутствие бэкенда». Это значит, что не нужно управлять серверами. Бэкенд-код вы всё равно пишете и защищаете.
• «Serverless всегда дешевле». При небольшом объёме дёшево, но оплата за запрос может накопиться при большом постоянном объёме.
• «Serverless масштабируется бесконечно». У платформ есть ограничения на параллельность, и узким местом может стать база данных задолго до функций.
• «Файлы, сохранённые в функции, будут там при следующем запуске». Локальное хранилище временное. Используйте базу данных или файловое хранилище.
• «Масштабирование до нуля — то же, что serverless». Связано, но не идентично. Некоторые платформы запускают ваше приложение как обычный сервер, который засыпает в простое и просыпается при следующем запросе: экономия похожая и задержка первого запроса похожая, но без ограничений по времени для каждого запроса, как у функций.

Что спросить у ИИ-конструктора

• «Этот бэкенд будет работать как serverless-функции или как сервер, который работает всё время или засыпает? Что это значит для стоимости?»
• «Не превысит ли какая-то задача лимит времени платформы? Если да, как с ней работать?»
• «Храни всё, что должно сохраняться, в базе данных или файловом хранилище, а не в памяти или локальных файлах.»
• «Как управлять подключениями к базе данных, если одновременно работает много копий?»
• «Какая задержка будет у первого запроса после простоя приложения?»

Как Mythex размещает приложения

Mythex не описывает свой хостинг как serverless-функции. При публикации ваше приложение работает как обычное веб-приложение или контейнер, которым управляет Mythex; настраивать хостинг не нужно. Это масштабирование до нуля: опубликованные приложения и их базы данных засыпают в простое и просыпаются при следующем визите, спящее приложение не тратит ресурсы на вычисления, а дополнительные машины запускаются только при сильном трафике (на Pro — до 3 на сервис). Подключённая база Postgres тоже засыпает после 5 минут простоя и оплачивается за время, пока работала. Так вы получаете большую часть выгоды «платите за то, что используете», с той же задержкой первого запроса после тихого периода. Подробнее см. лимиты хостинга в документации, а также наши статьи о веб-хостинге и снижении расходов на хостинг.

Вопросы