Что такое Serverless (FaaS): когда он выгоднее контейнеров и виртуальных машин

Термины и теория: что такое Serverless и FaaS

Приветствую, дорогой читатель!

Сегодня на повестке дня FaaS, виртуальные машины (VM) и контейнеры. Разберёмся, что из этого когда уместнее, где вы выигрываете по деньгам и скорости, а где — по контролю и предсказуемости.

Чтобы снизить порог вхождения, начнём с короткой “истории эволюции”. Когда-то всё было просто: чтобы работал сайт или приложение, нужен был физический сервер — реальное железо в стойке, которое кто-то покупал, подключал, обслуживал и берег как зеницу ока. Один сервер — одна среда. Если проект рос, приходилось докупать железо, переносить данные, переживать миграции и просто надеяться, что пик нагрузки не случится в самый неудобный момент.

Потом мир стал практичнее и появились виртуальные машины (VM). Логика здесь такая: у вас есть мощный физический сервер, и вы “делите” его на несколько изолированных виртуальных. Каждая VM ведёт себя почти как отдельный компьютер: у неё своя операционная система, свои настройки, свои ресурсы (CPU, память, диск). Это удобно — можно запускать разные приложения рядом, не мешая друг другу, и быстрее масштабироваться, не покупая новое железо под каждый чих.

Дальше появились контейнеры. Их можно представить как более лёгкую упаковку для приложения: контейнеры делят ядро ОС между собой, стартуют быстрее, плотнее “укладываются” на железо и обычно проще масштабируются в кластере. Если VM — это отдельные квартиры в доме (каждая со своей кухней и санузлом), то контейнеры — это комнаты в большом апарт-отеле: изоляция есть, но “инфраструктуры внутри” меньше.

И вот на этом фоне возникает Serverless.

Serverless — это подход, где вы говорите облаку не “дай мне сервер”, а “вот мой код — запусти его, когда понадобится”. Без выбора инстанса, без настройки ОС, без постоянного “живого” сервера, который простаивает, пока никто не заходит на сайт. У вас остаётся бизнес-логика, а всё, что связано с железом, операционками, патчами, базовой отказоустойчивостью и рутиной эксплуатации, прячется под капотом платформы.

Теперь важный момент: почему рядом всегда всплывает аббревиатура FaaS?

FaaS (Function as a Service) — это самый популярный и понятный “кусок” serverless-модели. По-человечески это выглядит так: вы загружаете функцию (не в академическом смысле, а просто небольшой фрагмент кода), и она запускается по событию. Например: пришёл HTTP-запрос, загрузили файл в хранилище, в очереди появилось сообщение, сработал таймер, прилетел вебхук от платёжной системы — и в этот момент платформа поднимает выполнение вашего кода.

Если упростить до бытового примера: если вам доводилось интегрировать сервисы через вебхуки, вы уже интуитивно понимаете FaaS. Событие произошло — платформа “дёрнула” ваш обработчик. Условно: создали задачу в Jira — прилетело сообщение в мессенджер. Только вместо “скрипта на сервере, который всё время ждёт” у вас функция, которая запускается ровно в момент события и выполняет работу.

Из-за этого часто говорят “Serverless = FaaS”, но строго говоря это не одно и то же:

• Serverless — понятие шире. Это про модель потребления инфраструктуры “как сервис”, где вы меньше занимаетесь эксплуатацией.
  
• FaaS — конкретный формат, где единицей работы становится функция, которая выполняется по вызову.

FaaS меняет саму точку зрения: вместо “где это будет жить” вы начинаете думать “когда это должно сработать”. У вас есть функция и есть событие, которое её вызывает — всё остальное платформа берёт на себя. Дальше, логично, заглянуть под капот и разобрать как оно работает от и до.

Как работает архитектура FaaS

Триггеры, масштабирование и cold start

Начнём с базы: триггер — это сигнал, по которому функция должна запуститься. В serverless-мире код не “дежурит” постоянно. Он просыпается ровно тогда, когда произошло нужное событие — и на этом вся магия, если говорить максимально простыми словами.

Какие события чаще всего выступают триггерами?

• HTTP-запрос (через API gateway или встроенный endpoint): пришёл запрос — функция отработала — вернула ответ.
  
• Сообщение в очереди / pub-sub: появилось событие — функция обработала его асинхронно (например, отправила письмо или пересчитала данные).
  
• Событие из объектного хранилища: загрузили файл — функция запускается и делает обработку (например, сжимает изображение или достаёт метаданные).
  
• Расписание (cron / scheduler): нужно что-то выполнять раз в час/день — функция стартует по таймеру.
  
• События из managed-сервисов: мониторинг, логи, стриминг данных и другие источники событий.

Смысл в том, что триггер задаёт момент запуска, а не постоянное “ожидание” на заранее поднятом сервере.

Теперь про масштабирование. В FaaS оно обычно устроено проще, чем кажется: если событие одно — выполняется один запуск. Если одновременно прилетает много событий, платформа поднимает больше параллельных выполнений, чтобы обработать очередь быстрее. Это можно сравнить с тем когда у вас подвис компьютер и вы 10 раз нажали на ярлык браузера. По итогу у вас откроется 10 отдельных окон.

Смысл тот же: платформа видит, что событий стало больше, и запускает больше параллельных “экземпляров” выполнения. Только в отличие от браузера тут важны правила — сколько таких запусков можно поднять одновременно и как именно платформа решает, когда добавлять новые.

Но “само” не значит “бесконечно”. Всегда есть лимиты: на параллельность, на скорость создания новых выполнений, на количество одновременных подключений к базе, на внешние API. Поэтому при всплесках иногда упирается не функция, а соседний компонент — например база данных, которая внезапно получает сотни одновременных запросов. И получается типичная ситуация: FaaS масштабировался, а остальная система оказалась не готова к такому параллелизму. 

И наконец — cold start. Это задержка, которая возникает, когда платформе нужно поднять окружение выполнения “с нуля”. Если функцию давно не вызывали, платформа держит её в холоде, чтобы не тратить ресурсы. Когда приходит новый триггер, ей требуется время, чтобы подготовить среду, загрузить код и зависимости, поднять runtime — и только после этого выполнить ваш код. На “тёплых” вызовах (когда окружение уже поднято) обычно всё происходит быстрее.

Оплата и платформенные ограничения

Теперь у нас вторая половина serverless-истории — та самая, из-за которой FaaS либо любят, либо ругают: как считается оплата и какие ограничения диктует платформа.

Начнём с оплаты. В классическом подходе вы обычно платите за “постоянно включённую мощность”: сервер или контейнер работает 24/7 — значит, деньги капают 24/7, даже если ночью трафика ноль. В FaaS модель другая: чаще всего вы платите за фактическое выполнение. Условно: сколько раз функцию вызвали и сколько времени она реально работала (плюс объём выделенных ресурсов, вроде памяти). Поэтому на бумаге это выглядит как мечта: нет вызовов — нет счёта.

Но есть нюанс: “платишь за выполнение” выгодно не всегда. Если функция вызывается очень часто и работает долго, счёт начинает расти заметно быстрее, чем ожидалось. Особенно если вы не оптимизировали код, тянете тяжёлые зависимости или делаете внутри функции много “ожиданий” (например, медленно ходите в базу или во внешние API).

Отсюда практическое правило: FaaS обычно выигрывает там, где нагрузка неровная или событийная, и проигрывает там, где у вас стабильный поток запросов 24/7 и функция постоянно занята работой.

Теперь про платформенные ограничения. Они есть всегда, просто о них редко думают на старте — до первой “а почему оно не запускается”.

Самые частые ограничения выглядят так:

• Ограничение по времени выполнения. Функция — не бесконечный процесс. Если задача должна крутиться часами, FaaS обычно не лучший формат.
  
• Ограничения на ресурсы. Память, CPU, размер пакета с кодом/зависимостями — всё это имеет потолок.
  
• Ограничения на параллельность. Да, платформа масштабируется, но до определённого предела. А дальше либо очередь копится, либо нужно поднимать лимиты и менять архитектуру.
  
• Ограничения на сеть и подключения. Если каждая параллельная функция открывает соединение к базе, можно быстро упереться в лимит соединений — и уже база начнёт “ложиться”, даже если сама функция масштабируется идеально.
  
• Ограничения по окружению. В serverless вы не всегда можете сделать “как привыкли на сервере”: что-то нельзя установить, где-то нельзя держать локальный state, где-то файловая система временная и живёт недолго.

И вот тут становится понятна главная идея: FaaS даёт удобство, но вы платите за него не только деньгами, а ещё и рамками платформы. Если вы укладываетесь в эти рамки — получается быстро, дёшево и красиво. Если не укладываетесь — начинаются костыли, усложнение и неожиданно дорогие счета.

Отличия FaaS от контейнеров и VM

Теперь давайте разложим всё по полочкам. В начале мы познакомились с VM, контейнерами и FaaS на уровне “что это вообще такое”. А здесь сравним их так, чтобы стало ясно: в чём практическая разница, и почему иногда “по учебнику” правильно одно, а в реальной жизни удобнее другое.

Начнём с главного: у этих подходов разная единица мышления.

• В VM вы думаете “у меня есть машина”. Даже если она виртуальная, она ведёт себя как полноценный компьютер: ОС, апдейты, агенты, настройки, мониторинг, доступы. Это даёт максимум свободы — и максимум ответственности.
  
• В контейнерах вы думаете “у меня есть приложение в упаковке”. Оно легче переносится, быстрее стартует и проще тиражируется. Но за сценой всё равно существует “место, где контейнеры живут”: кластер, сеть, балансировка, политика деплоев, наблюдаемость. То есть контроль высокий, но распределён по большему количеству деталей.
  
• В FaaS вы думаете “у меня есть действие”. Не сервис, который должен постоянно быть включённым, а кусок логики, который запускается по событию и исчезает. И вот это переключение мышления меняет почти всё: жизненный цикл, стоимость, масштабирование и даже стиль разработки.

Чтобы было проще сравнивать, вот таблица “в лоб” — по тем параметрам, которые чаще всего влияют на выбор:

Теперь — несколько моментов, которые часто всплывают уже в бою, а не в теории.

Например, многие думают, что FaaS — это “просто дешевле”, потому что “платишь только когда работает”. На практике дешевизна появляется не из воздуха, а из конкретного поведения нагрузки. Если у вас приложение живёт ровной жизнью 24/7, FaaS может оказаться не выгоднее, потому что вы платите за огромное количество вызовов и суммарное время выполнения. Зато если нагрузка “ступеньками”, есть пики, паузы, сезонность, редкие фоновые задачи — вот тут serverless действительно ощущается как “платишь по факту”.

Другой неочевидный момент — масштабирование может стать проблемой именно потому, что оно слишком хорошее. Платформа способна поднять много параллельных запусков, но дальше вопрос: куда эти запуски идут. Если каждая функция лезет в базу и открывает соединение, то “бутылочным горлышком” становится база — и вы получаете ситуацию, когда FaaS отработал честно, а система всё равно деградирует. Поэтому в serverless-архитектуре очень часто рядом живут очереди, батчинг, rate limiting и пуллинг соединений — не потому что так “красивее”, а потому что иначе параллелизм превращается в DDoS по собственным компонентам.

Есть и психологический аспект, который обычно замечают уже опытные команды: контейнеры дают ощущение контроля, потому что “мы сами управляем средой”. А FaaS даёт ощущение скорости, потому что “мы вообще не трогаем инфраструктуру”. И иногда решение принимают именно по этому ощущению: если команда устала от ops-рутины, FaaS становится облегчением. Если команда боится ограничений и хочет предсказуемости, контейнеры/VM кажутся спокойнее.

Наконец, важная практическая разница — как вы проектируете приложение. В VM/контейнерах люди часто строят “долго живущий сервис”: подняли процесс, он держит кэш, держит соединения, обслуживает запросы. В FaaS вы почти вынуждены думать иначе: функция должна быть готова стартовать в пустой среде, быстро сделать работу и закончить. Это дисциплинирует и делает архитектуру более событийной — но иногда и усложняет жизнь, если ваша задача по природе своей “долгоиграющая”.

Если обобщить: VM и контейнеры — это про управляемую среду, а FaaS — про управляемое выполнение. И дальше вопрос не “что лучше вообще”, а “что лучше под ваш тип нагрузки и ваш сценарий”.

На этом сравнение можно считать завершённым. Мы разобрали, чем FaaS отличается от контейнеров и VM не в теории, а по реальным “болям”: кто за что отвечает, как ведёт себя масштабирование, где прячутся лимиты и почему модель оплаты иногда радует, а иногда пугает. Настало время подвести итоги и собрать картину в голове.

Заключение. Так где же выгода?

Serverless в формате FaaS — это модель, где вы запускаете код по событию, а не держите постоянно работающий сервер или сервис. Платформа сама поднимает выполнение, масштабирует параллельные запуски и берёт на себя большую часть инфраструктурной рутины — вы фактически платите за “работу функции”, а не за “включённую мощность”.

Когда FaaS выгоднее контейнеров и виртуальных машин:

• Когда нагрузка неровная: есть пики и провалы, сезонность, “то пусто, то густо”;
  
• Когда у вас много событийных задач: вебхуки, очереди, обработка файлов, фоновые джобы, расписание;
  
• Когда важны скорость запуска и минимум эксплуатации: нужно быстро собрать интеграцию или MVP и не тратить недели на инфраструктуру.

Когда контейнеры или VM обычно лучше:

• Когда сервис работает постоянно и стабильно 24/7 (вы платите за вызовы и время выполнения, и это может стать дороже);
  
• Когда нужны долгие процессы, тонкая настройка среды или специфические системные зависимости;
  
• Когда критична предсказуемая задержка (cold start и платформенные лимиты могут неприятно выстрелить).

Если свести всё к одной мысли: FaaS выигрывает там, где приложение можно разложить на короткие действия и запускать их по событию, а контейнеры и VM чаще выигрывают там, где нужен постоянно живущий сервис с максимальным контролем и предсказуемостью.