Классическая инфраструктура заставляет компанию заранее думать о серверах: сколько их нужно, какой мощности, что делать с пиками нагрузки и кто будет всё это обслуживать.
Serverless меняет точку ответственности. Команда загружает код или описывает функцию, а платформа сама решает, где её запустить и сколько ресурсов выделить.
Это не означает, что серверов больше нет. Они просто перестают быть ежедневной заботой продуктовой команды.
Какую проблему мы решаем
Во многих продуктах нагрузка неравномерна. Функция может вызываться тысячи раз в течение часа, а потом почти не использоваться. Держать отдельную инфраструктуру постоянно включённой для такого сценария бывает невыгодно.
Serverless позволяет запускать вычисления по событию и автоматически увеличивать или уменьшать количество экземпляров под текущую нагрузку.
Команда меньше занимается серверами и больше — самим бизнес-сценарием.
Что получает бизнес
Первая выгода — быстрее запускать небольшие функции, интеграции и экспериментальные сервисы без отдельного инфраструктурного проекта вокруг каждого из них.
Вторая — расходы могут лучше соответствовать фактическому использованию. Если функция почти не вызывается, компания не обязана оплачивать постоянно работающую мощность только ради готовности.
Третья — пиковая нагрузка реже требует заранее покупать большой запас инфраструктуры. Платформа берёт значительную часть масштабирования на себя.
Но экономия появляется не автоматически. При постоянной высокой нагрузке или сложной обработке serverless может оказаться дороже более предсказуемой инфраструктуры.
Что получает команда
Команда получает меньше рутинной работы вокруг серверов, развёртывания и базового масштабирования. Для небольших функций путь от кода до работающего сервиса становится короче.
Одновременно появляются ограничения среды: время выполнения, модель запуска, наблюдаемость, локальная отладка и способы хранения состояния.
Архитектуру приходится строить с учётом платформы, а не только требований приложения.
Что получает клиент
Клиент напрямую не видит serverless. Он видит скорость появления новых функций и способность продукта переживать неожиданные всплески нагрузки.
Но он может почувствовать и обратную сторону: первый вызов после простоя иногда занимает больше времени, а ограничения платформы могут влиять на сложные или длительные операции.
Чем мы за это платим
Главная цена — зависимость от возможностей конкретной платформы. Чем глубже продукт использует её сервисы и особенности, тем сложнее потом переносить систему.
Вторая цена — архитектурная фрагментация. Десятки маленьких функций легко создать, но сложнее понять, кто кого вызывает, где искать ошибку и как контролировать общую стоимость.
Поэтому serverless хорошо уменьшает инфраструктурную работу, но не отменяет архитектурную дисциплину.
Когда serverless не нужен
Если приложение работает постоянно, нагрузка предсказуема, а команда уже хорошо управляет инфраструктурой, переход может не дать заметного экономического эффекта.
Не стоит выбирать serverless только потому, что не хочется думать об инфраструктуре. Сначала важно понять, какую конкретную стоимость или задержку он убирает.
Что стоит спросить перед решением
- Нагрузка постоянная или сильно меняется во времени?
- Сколько сейчас стоит поддержка инфраструктуры вокруг этой функции?
- Насколько критична зависимость от конкретного облачного провайдера?
- Есть ли ограничения по времени выполнения и задержке первого вызова?
- Как будем видеть стоимость и связи между десятками функций?
В итоге
Serverless полезен не потому, что «серверы больше не нужны», а потому, что часть инфраструктурной ответственности можно купить как услугу.
Для бизнеса смысл простой: меньше платить за готовность там, где можно платить за фактическую работу. Но вместе с этим компания покупает и зависимость от правил платформы.