Serverless: где такой подход работает, а где нет

Еще несколько лет назад слово serverless звучало почти как маркетинговая уловка. Многие даже поняли его слишком буквально и действительно подумали, что в будущем серверы исчезнут. На деле же такой подход означает, что работа над сервером переходит от команды проекта облачной платформе.

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

Звучит удобно. Во многих задачах так и есть. Только вот serverless — не универсальный молоток. Иногда он отлично экономит время и деньги, а иногда превращает проект в клубок ограничений, который сложно поддерживать. Разберем спокойно и без фанатизма, где модель работает хорошо, а где начинаются компромиссы.

Что вообще называют serverless

Чаще всего речь идет о модели Function as a Service — FaaS. По ней разработчик загружает небольшой кусок кода, а облачная платформа запускает его по событию.

Событием может быть что угодно:

• HTTP-запрос к API;

• загрузка файла;

• сообщение из очереди;

• действие пользователя;

• запуск по расписанию.

Например, интернет-магазин получил новый заказ. Срабатывает serverless-функция: отправляет письмо клиенту, обновляет склад, создает задачу в CRM. Все это без отдельного сервера, который нужно держать включенным круглосуточно.

Где serverless показывает себя отлично

Есть несколько направлений, где такой подход станет настоящим спасением для команды.

Событийная обработка

Это почти идеальный сценарий. Есть событие — функция запускается. Нет событий — ничего не работает и деньги не тратятся.

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

Фоновые задачи и автоматизация

Многие компании держат отдельные сервисы только ради периодических задач. Например, для очистки кэша, генерации отчетов или синхронизации данных между системами. То есть все те рутинные задачи, которые живут где-то на фоне.

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

API и микросервисы

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

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

Особенно удобно на ранних этапах проекта. Когда продукт еще ищет аудиторию, не хочется тратить недели на инфраструктуру.

Нерегулярная нагрузка

Есть системы, которые большую часть времени почти простаивают, а потом внезапно получают всплеск запросов.

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

Serverless умеет быстро масштабироваться под такие скачки. И платить приходится только за фактическое выполнение функций, а не за простаивающие серверы.

Для сезонных проектов это часто очень выгодно.

В каких случаях подход может не сработать

У serverless есть не только преимущество, но и недостатки. Рассмотрим основные сценарии, при которых подход не работает.

Холодный старт

Если функция долго не использовалась, платформа может «усыпить» ее экземпляр. При новом запросе потребуется время на запуск среды выполнения. Это называют cold start — холодный старт.

Иногда задержка составляет сотни миллисекунд. Но иногда ожидание может увеличиться до нескольких секунд.

Звучит не очень страшно, но представьте кнопку «Оплатить», которая зависает перед ответом. Пользователь начинает нервничать, нажимает снова, появляются дубли операций. Такие вещи быстро портят впечатление от сервиса.

Ограничения по времени

Serverless-функции не рассчитаны на долгую работу. У каждой платформы есть лимиты: пять минут, пятнадцать, иногда меньше.

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

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

Сложная отладка

Serverless-приложения часто состоят из множества маленьких функций, очередей, триггеров и сервисов. Проследить весь путь запроса становится непросто.

Логи разбросаны по разным системам. Повторить проблему локально бывает тяжело. А если ошибка появляется только под нагрузкой, то поиск бага становится еще труднее.

Зависимость от платформы

Каждый облачный провайдер предлагает свои инструменты, ограничения и особенности.

Функция для AWS Lambda не всегда легко переносится в Azure Functions или Google Cloud Functions. Формально код можно переписать. На практике появляются десятки мелких различий: авторизация, события, настройки сети, лимиты, логирование.

Пока проект маленький, проблема почти незаметна. Когда сервис вырастает и появляется желание сменить платформу или распределить нагрузку между облаками, начинается дорогая миграция.

А что с ценой

Вот здесь serverless часто вызывает путаницу. На маленьких нагрузках модель может быть очень доступной. Так как запросов мало, то и расходов почти нет. Для стартапов и внутренних сервисов это выглядит отлично.

Но при стабильной высокой нагрузке картина меняется. Тысячи и миллионы вызовов функций начинают стоить заметно дороже обычных виртуальных серверов или контейнеров.

Есть еще одна неприятная деталь: расходы сложнее прогнозировать.

Сегодня сервис получил сто тысяч запросов — все нормально. Завтра неожиданно пришел миллион из-за рекламной кампании или ошибки клиента — счет резко вырос. И да, такие истории случаются регулярно.

Поэтому serverless требует внимательного мониторинга затрат. Иначе можно получить неприятный сюрприз в конце месяца.

Не стоит воспринимать serverless как универсальное решение для всего

Иногда вокруг serverless создают ощущение, будто инфраструктура перестала быть проблемой. На практике проблемы просто смещаются в другую сторону.

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

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

Главное — не пытаться строить на serverless вообще всё подряд. Это хороший инструмент, когда его используют по назначению. И очень упрямый инструмент, если пытаться заставить его работать там, где ему тесно.