Serverless не означает «без серверов». Серверы остаются, но вы перестаёте их арендовать помесячно и платите за фактические миллисекунды работы кода. Модель FaaS (Function as a Service) появилась с AWS Lambda в конце 2014 года, в прошлом году к ней добавились Azure Functions и Google Cloud Functions, а в феврале 2017-го выкатили IBM OpenWhisk с открытым кодом. Для бизнеса вопрос простой: когда функции реально дешевле постоянно работающего сервера, а когда вы платите за это скрытую цену.

Как считаются деньги

Классическая виртуалка стоит одинаково – что под нагрузкой, что простаивая ночью. FaaS тарифицирует две вещи: число вызовов и время выполнения, округлённое до 100 мс, помноженное на выделенную память. У Lambda первый миллион вызовов в месяц бесплатен, дальше – 0,20 доллара за миллион плюс плата за GB-секунды.

Считайте так. Сервис обрабатывает 200 тысяч запросов в сутки, каждый отрабатывает 150 мс при 256 МБ памяти. Это около 6 миллионов вызовов в месяц и порядка 230 тысяч GB-секунд. Итоговый счёт – единицы долларов в месяц против десятков за самую скромную постоянно включённую виртуалку. Экономика ломается в обратную сторону при ровной высокой нагрузке: если процессор занят круглосуточно, выделенный сервер обходится дешевле, потому что вы не доплачиваете за гибкость, которая вам не нужна.

Вывод: FaaS выигрывает на рваной, непредсказуемой и редкой нагрузке. Фоновая обработка событий, обработчики веб-хуков, конвейеры предиктивной аналитики и ML, где модель дёргают пакетами раз в час, – здесь функции дешевле серверов в разы.

Где это работает в наших проектах

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

Второй сценарий – реакция на события инфраструктуры. Функция перекладывает данные между хранилищами, чистит логи, рассылает уведомления по расписанию. Третий – лёгкие API через API Gateway, где трафик скачет от нуля до пиков и обратно.

При проектировании инфраструктуры на облачных платформах функции почти никогда не живут в одиночку. Их связывают очереди, хранилища объектов и управляемые базы и это меняет картину рисков.

Чем за это платят

Бесплатных решений не бывает, есть удобные. У serverless три постоянных издержки.

Холодный старт. Если функцию давно не вызывали, провайдер поднимает контейнер с нуля – добавляются сотни миллисекунд, иногда секунды. Для фоновой задачи это незаметно, для пользовательского API под SLA – уже проблема, которую держат прогревом.

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

Зависимость от платформы. Февральский сбой AWS S3 показал, насколько глубоко serverless-сервисы переплетены между собой; мы разбирали выводы в материале про устойчивость к отказам облака. Функция бесполезна, если хранилище, из которого она читает, недоступно.

Вывод

Serverless – не замена серверам, а инструмент под конкретный профиль нагрузки. Берите FaaS там, где нагрузка рваная и событийная, держите выделенные мощности под ровный поток, считайте полную стоимость с учётом холодного старта и привязки к провайдеру. Тогда «функции дешевле серверов» – не лозунг, а строчка в счёте.