Ещё лет десять назад запуск любого веб-проекта начинался одинаково: аренда машины, настройка окружения, ночи с мониторингом и обновлениями. Сегодня всё больше команд пишут код, вообще не касаясь железа. Такой подход называют серверлесс — модель, при которой инфраструктуру целиком забирает на себя облачный провайдер, а разработчик отвечает только за логику. Разбираемся, что такое serverless на практике, почему его хвалят и за какие грехи ругают.
При чём тут слово «бессерверный», если серверы всё равно существуют
Серверы никуда не делись — просто о них перестал думать тот, кто пишет приложение. Ядро подхода — FaaS (Function as a Service, «функция как услуга»): код нарезается на небольшие функции, которые облако запускает по событию — входящему запросу, сообщению в очереди, загрузке файла в хранилище. Рядом обычно работают BaaS-сервисы (Backend as a Service) — готовые облачные блоки: базы данных, аутентификация, отправка писем.
Оплата тоже непривычная. Не за арендованную мощность, а за фактические вызовы и миллисекунды работы кода. Нет трафика — нет счёта. Отсюда главное обещание бессерверных вычислений: инфраструктура масштабируется сама, от нуля до тысяч одновременных запросов, без единого действия со стороны команды.
Сильные стороны: зачем команды переходят на облачные функции
- Ноль администрирования. Патчи операционной системы, резервное копирование, деградация дисков — всё это становится головной болью провайдера, а не дежурного инженера.
- Автоматическое масштабирование. Всплеск трафика после упоминания продукта в СМИ перестаёт быть чрезвычайным происшествием — облако само размножит функции под нагрузкой.
- Оплата по факту. Для проектов с рваной нагрузкой стоимость serverless часто оказывается заметно ниже, чем содержание виртуалок, которые простаивают ночами.
- Скорость релизов. Мелкая функция деплоится за секунды, откат занимает столько же — экспериментировать становится дёшево.
- Меньше операционных рисков. Нечего «уронить» перезагрузкой: нет своей машины — нет и упавшего сервера в три часа ночи.
Плюсы и минусы серверлесс всегда смотрят в паре, поэтому переходим к обратной стороне.
Слабые места, о которых молчат презентации
Холодный старт
Холодный старт — это задержка при первом запуске функции, когда облаку нужно поднять окружение с нуля. Сотни миллисекунд, а для тяжёлых рантаймов вроде Java — и секунды. Пользователь админки этого не заметит, а вот API с жёсткими требованиями к отклику почувствует сразу. Провайдеры борются с проблемой прогревом и «тёплыми» инстансами, но полностью магия задержку не убирает.
Привязка к конкретному облаку
Вендор-лок — жёсткая зависимость от услуг одного провайдера — здесь проявляется жёстче, чем где-либо. Функции обрастают специфичными триггерами, интеграциями и конфигурациями, и переезд превращается не в миграцию, а в переписывание. Гибридный код с абстракциями спасает частично, но усложняет разработку.
Лимиты, отладка и наблюдаемость
Ограничения по времени выполнения, объёму памяти и размеру пакета — данность любой FaaS-платформы. Длинные вычисления туда просто не помещаются. Хуже другое: система из десятков мелких функций превращается в распределённую сеть, где трассировка (отслеживание пути запроса через все сервисы) требует отдельных инструментов, а локально воспроизвести боевой сценарий почти невозможно. Логи размазаны по облаку, и без настроенного мониторинга поиск ошибки напоминает археологию.
Где serverless раскрывается, а где буксует
Облачные функции отлично себя чувствуют в событийных сценариях — там, где работа приходит порциями, а не льётся постоянным потоком:
- обработка изображений и файлов после загрузки;
- API с редкими или сильно пиковыми запросами — сайты мероприятий, промо-страницы, уведомления;
- чаты-боты, рассылки, ночные пакетные задачи по расписанию;
- склейка микросервисов через очереди и потоки данных.
Обратные примеры не менее показательны. Приложения с постоянным высоким трафиком на бессерверной модели нередко стоят дороже выделенных машин — почасовая аренда выигрывает у поминутной оплаты при равномерной загрузке. Состояние — ещё одна заноза: функции по природе stateless, то есть не хранят данные между вызовами, и всё приходится выносить во внешние базы, что добавляет латентность и точки отказа. Системы с жёсткими требованиями к предсказуемому отклику тоже чувствуют себя неуютно рядом с холодными стартами.
На практике зрелые команды редко бросаются в омут с головой: новый функционал выносится в serverless-блок, а ядро с чувствительной логикой остаётся на привычных контейнерах. Начать с одной функции — обработчика уведомлений или генератора отчётов — дешевле любого эксперимента: за пару спринтов станет ясно, как облако ведёт себя под реальной нагрузкой и сколько действительно приходит счёт.