Serverless: эволюция контроля

Когда «бессерверность» — отличный выбор, а когда — дорогая ошибка. Разбираем архитектурный компромисс для разработчиков и архитекторов.

История современных облаков — это последовательная упаковка сложности. Каждый уровень абстракции убирает один класс задач из зоны ответственности разработчика и одновременно сужает контроль над инфраструктурой.

Если представить эту историю как линию времени, она выглядит так. В 2006 году Amazon запускает EC2 — по сути, аренду виртуальных машин через API. Никакой магии: просто чужое железо, которое можно арендовать программно. Локальные диски были эфемерными и могли терять данные, autoscaling и IAM появились позже. Но именно здесь сформировался ключевой паттерн, который живёт до сих пор: сервисы должны быть stateless и переживать сбои независимо от инфраструктуры.

В период с 2008 по 2013 год появляются Docker и Kubernetes, набирает обороты движение DevOps — конференции Velocity, DevOpsDays. Инфраструктура становится кодом: reproducible builds, immutable deployments. Разработчики получают контейнеры — предсказуемую упаковку для приложений.

В 2014 году Amazon запускает Lambda и убирает последний слой. Теперь можно деплоить код, вообще не думая о серверах. Биллинг по миллисекундам, scale-to-zero из коробки.

В 2018 году появляется Knative — попытка запустить модель serverless поверх собственного Kubernetes-кластера, не привязываясь к конкретному провайдеру.

Чтобы понять, где serverless находится среди других подходов, представьте шкалу от левого края к правому. Слева — максимум контроля, справа — максимум удобства и зависимости.

На левом краю стоит собственный дата центр: вы управляете всем, от железа до операционной системы. Чуть правее — IaaS, то есть инфраструктура как сервис: Amazon EC2 или Google Compute Engine берут на себя железо, вы управляете операционной системой и всем, что выше. Ещё правее — PaaS, платформа как сервис: Heroku и подобные решения берут на себя и ОС, и окружение, вам остаётся код и конфиг. Затем CaaS — контейнеры как сервис: Kubernetes, где вы упаковываете приложение в контейнер, платформа запускает его. Почти у правого края — FaaS, функции как сервис: AWS Lambda. Вы пишете функцию, провайдер делает всё остальное. На самом правом краю — SaaS, готовый продукт вроде Gmail: вы вообще ничем не управляете, просто пользуетесь.

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

У serverless три главных достоинства и три главных ограничения.

Достоинства. Первое — event-driven: код выполняется только по событию, нет события — нет расхода ресурсов и денег. Второе — scale-to-zero: нет нагрузки, нет инстансов, автомасштабирование прозрачно и мгновенно, провайдер делает это за вас. Третье — pay-per-execution: вы платите за фактическое время выполнения в миллисекундах, а не за uptime сервера, что выгодно при нерегулярной нагрузке.

Ограничения. Первое — cold start: первый вызов после простоя инициализирует контейнер заново, задержка составляет от десятков миллисекунд до нескольких секунд для JVM-сервисов. Второе — лимиты времени: AWS Lambda позволяет выполнять функцию максимум 15 минут, долгие вычисления и ML операции на больших данных не подходят. Третье — vendor lock-in: у каждого провайдера свой runtime, свои интеграции, свой IAM, миграция с Lambda на Cloud Functions требует переписывания.

Важно понять главное: serverless — это не «больше возможностей», а меньше контроля. Это нужно принять до выбора архитектуры, а не после.

Когда vendor lock-in и фиксированные ограничения Lambda начинают болеть, появляется Knative. Идея простая: взять модель serverless — event-driven выполнение, scale-to-zero, автомасштабирование — и запустить её поверх собственного Kubernetes-кластера.

Это даёт три вещи. Настраиваемый runtime: любой язык, любая версия, нет ограничений провайдера, можно запустить сервис, которому нужен GPU. Инфраструктура под контролем: данные не покидают ваш кластер, полный контроль над сетью, хранилищем и конфигурацией. И никакого vendor lock-in.

Но за это приходится платить. Обновления Kubernetes, TLS-сертификаты, операторы Knative — всё это теперь ваша ответственность, а не провайдера.

Можно описать это так: Knative — это когда просишь маму купить Lambda, но мама говорит, что Lambda есть дома. Только забывает добавить, что её придётся чинить, обновлять и следить за сертификатами самому.

Basecamp и проблема стоимости. Команда Basecamp описала свой опыт в статье «Why we're leaving the cloud» (basecamp.com/cloud-exit). Логика простая: облако отлично работает на старте и при нестабильном трафике. Но при стабильной предсказуемой нагрузке оно превращается в дорогую аренду с маржой провайдера. После перехода на собственное железо Basecamp экономит около 3,2 миллиона долларов в год. Облако — это аренда с маржой, а не магия.

Unkey и проблема latency. Unkey — сервис валидации API-ключей, который находится в критическом пути тысяч приложений. Требование простое: отвечать быстро. Анализ (infoq.com/news/2025/12/unkey-serverless) показал, что p99 latency на serverless составляет около 30 миллисекунд при цели менее 10 миллисекунд. Причины — сетевой overhead, cold start, дополнительные прослойки инфраструктуры. Вывод: serverless плохо подходит для систем, где критична задержка.

Capital One поделились опытом эксплуатации serverless в продакшне (infoq.com/presentations/serverless-best-practices). Вот что реально работает.

Первое — минимизируйте cold start. Используйте lazy initialization зависимостей, держите размер пакета минимальным, переиспользуйте соединения с базой данных между вызовами — connection pool нужно создавать вне обработчика.

Второе — проектируйте событийную архитектуру. Избегайте длинных синхронных цепочек функций и используйте очереди вроде SQS или Kafka. Синхронный вызов Lambda из Lambda увеличивает связность и задержку.

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

Четвёртое — transform, not transport. Функция должна преобразовывать данные, а не просто передавать их дальше. Чистое проксирование — это накладные расходы без ценности.

Чтобы понять, подходит ли serverless для вашего случая, удобно смотреть на несколько параметров одновременно.

По типу нагрузки: serverless выигрывает при нерегулярной нагрузке и burst-трафике, контейнеры и виртуальные машины — при стабильном high-load.

По требованиям к latency: serverless плохо подходит для latency-критичных путей, контейнеры дают предсказуемую p99.

По длительности задач: serverless не подходит для задач дольше 15 минут, контейнеры работают без ограничений по времени.

По скорости разработки: serverless выигрывает, потому что нет инфра-задач, контейнеры требуют DevOps-компетенций.

По стоимости: serverless дешевле при burst-трафике, контейнеры дешевле при стабильной высокой нагрузке.

По контролю: serverless предоставляет минимальный контроль, контейнеры — полный.

Вся эволюция облаков — это не движение вперёд по одной дороге. Это движение по оси между двумя полюсами: контролем и удобством. Чем левее — тем больше вы управляете, тем больше инвестируете в инфраструктуру. Чем правее — тем быстрее вы начинаете, тем больше зависите.

Свой дата центр — крайний левый полюс. SaaS — крайний правый. Serverless стоит почти у правого края. Knative — попытка чуть сдвинуться влево, не теряя модели.

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

Как обычно в инженерии: выигрывает не технология, а правильно выбранный компромисс.

Источники

Amazon EC2 Beta (2006) — aws.amazon.com/ru/blogs/aws/amazon_ec2_beta/

AWS Lambda turns ten — aws.amazon.com/ru/blogs/aws/aws-lambda-turns-ten-the-first-decade-of-serverless-innovation/

Why we're leaving the cloud — Basecamp — basecamp.com/cloud-exit

Unkey migrating from serverless — InfoQ — infoq.com/news/2025/12/unkey-serverless/

Serverless best practices — Capital One — infoq.com/presentations/serverless-best-practices/

Open-source serverless platforms comparison — arxiv.org/pdf/1911.07449

Карен Шахназарян, Go Developer