Вы когда-нибудь платили за сервер, который простаивал ночью, потому что пользователи спали? Или настраивали масштабирование, чтобы выдержать чёрную пятницу, а потом месяц убирали лишние мощности? Это боль традиционной серверной модели.
Serverless (бессерверные вычисления) — это модель, где вы не думаете о серверах вообще. Вы пишете функцию (например, на Python или Node.js), загружаете её в облако, а провайдер сам запускает её при вызове, сам масштабирует под нагрузку и сам выключает, когда она не нужна. Платите только за время выполнения функции.
В 2026 году serverless стал мейнстримом. AWS Lambda обрабатывает миллиарды запросов в день. Облачные провайдеры предлагают свои аналоги. Появились даже open-source решения для своих серверов.
Но serverless — не панацея. Он отлично подходит для одних задач и категорически не подходит для других. Давайте разбираться.
Часть 1: Как работает serverless за минуту
Вы пишете небольшую функцию. Например, на Python:
Загружаете её в облачный сервис (AWS Lambda, Yandex Cloud Functions, Google Cloud Functions). Указываете триггер: например, HTTP-запрос по определённому URL.
Всё. Дальше провайдер сам:
- Запускает контейнер с вашим кодом при первом вызове.
- Маршрутизирует запросы.
- Масштабирует количество экземпляров под нагрузку.
- Останавливает, когда вызовов нет.
- Платите вы только за время работы функции (обычно до миллисекунды) и количество вызовов.
Никаких серверов, никакого Kubernetes, никаких ночных дежурств.
Часть 2: Главные плюсы и минусы serverless
Плюсы
- Экономия: не платите за простой.
- Автоматическое масштабирование: от 0 до тысяч параллельных вызовов.
- Никакого администрирования: не нужно обновлять ОС, настраивать балансировщики, следить за дисками.
- Быстрый старт: написали функцию — задеплоили — работает.
Минусы
- Холодный старт (cold start): если функция долго не вызывалась, при первом вызове может быть задержка (от десятков миллисекунд до нескольких секунд).
- Ограничения по времени: большинство сервисов ограничивают время выполнения (обычно 5-15 минут).
- Ограничения по памяти и CPU: нельзя запустить тяжёлое приложение.
- Сложность отладки: трудно тестировать локально и отлаживать распределённые вызовы.
- Привязка к провайдеру: ваш код завязан на API конкретного облака.
Часть 3: Основные провайдеры 2026
AWS Lambda (Самый популярный)
Первый и самый зрелый serverless-сервис. Поддерживает множество языков (Node.js, Python, Go, Java, .NET, Rust). Огромная экосистема интеграций с другими сервисами AWS (S3, DynamoDB, API Gateway, SQS).
Плюсы: лидер рынка, максимум документации и примеров.
Минусы: сложная настройка IAM прав, привязка к AWS.
Идеален для: крупных проектов в AWS, сложных интеграций.
Google Cloud Functions (Второй по популярности)
Интегрирован с экосистемой Google (Cloud Storage, Firestore, Pub/Sub). Поддерживает Node.js, Python, Go, Java, .NET, Ruby, PHP. Вторая версия на основе Cloud Run даёт больше контроля.
Плюсы: простой интерфейс, хорошая документация.
Минусы: комьюнити меньше, чем у AWS.
Идеален для: проектов, уже использующих Google Cloud.
Yandex Cloud Functions (Российский лидер)
Популярен в России и СНГ. Интегрирован с Yandex Cloud (S3-совместимое хранилище, API Gateway, YMQ). Поддерживает Node.js, Python, Go, PHP, Bash, Java, .NET, Rust. Есть бесплатный тариф.
Плюсы: низкие цены, простота, хорошая документация на русском.
Минусы: меньше возможностей, чем у AWS Lambda.
Идеален для: российских проектов, которым нужно соблюдение 152-ФЗ.
Azure Functions (Экосистема Microsoft)
Сильная интеграция с .NET и экосистемой Azure. Поддерживает C#, F#, Node.js, Python, Java, PowerShell, TypeScript. Хорош для Windows-ориентированных проектов.
Плюсы: отличная интеграция с Visual Studio, поддержка durable функций (долгие процессы).
Минусы: сложнее в настройке, чем у конкурентов.
Идеален для: проектов на .NET и Azure.
OpenFaaS (Open source для своих серверов)
Позволяет запускать serverless-функции на своём Kubernetes-кластере. Не зависит от облачного проваридера. Поддерживает любой язык (через Docker). Есть интеграция с Prometheus, Grafana.
Плюсы: полный контроль, no vendor lock-in, работает даже на Raspberry Pi.
Минусы: нужно самим администрировать Kubernetes.
Идеален для: компаний, которые не могут использовать публичное облако (регуляторика, безопасность) или хотят единую платформу для on-premise и облака.
Часть 4: Карта выбора (когда переходить на serverless)
Идеальные сценарии для serverless
- API с неравномерной нагрузкой. Приложение, которое почти не используют ночью, но днём бывают пики. Serverless сэкономит деньги.
- Обработка событий и файлов. Пользователь загрузил аватар → триггер на S3/облачное хранилище → запускается функция, которая ресайзит картинку.
- Периодические задачи. Каждые 5 минут дергать API, что-то проверять, отправлять уведомления (через cron-триггер).
- Партиментная обработка данных. Нужно обработать 10 000 файлов в S3. Serverless запустит 1000 параллельных функций и сделает это за минуты.
- Прототипы и MVP. Быстро проверить идею без разворачивания серверов.
Когда serverless не подходит
- Долгие задачи (более 10-15 минут). Обработка видео, миграция данных. Лучше использовать обычные серверы или Kubernetes.
- Постоянно высокая нагрузка. Если у вас 24/7 идёт 1000 запросов в секунду, свои серверы или Kubernetes будут дешевле.
- Приложения с низкой задержкой (менее 10 мс). Холодный старт может убить latency.
- Тяжёлые приложения (нужно много CPU/RAM). Machine learning inference, большие вычисления.
- WebSocket-серверы с постоянным соединением. Serverless не для этого.
Часть 5: Тренды 2026
- Cold start становится меньше. AWS Lambda теперь держит функции в «тёплом» состоянии после вызовов. Google Cloud Functions (2 gen) на основе Cloud Run запускается быстрее.
- Долгие функции (до часа). Некоторые провайдеры увеличивают лимиты.
- Serverless-базы данных (Aurora Serverless, DynamoDB, FaunaDB). Базы, которые сами масштабируются под нагрузку.
- Serverless на грани сети (Edge). Cloudflare Workers, Lambda@Edge — запуск кода ближе к пользователю.
- OpenFaaS и Knative становятся стандартом для on-premise serverless.
Часть 6: Пример сценария
Вы делаете сервис для ресайза аватарок. Пользователь загружает фото в облачное хранилище. Настроен триггер: при создании объекта запускается serverless-функция (на Node.js или Python), которая читает фото, ресайзит его, сохраняет обратно. Пользователь получает готовую аватарку. Вы платите копейки за каждую обработку, не держите ни одного сервера, а при 10 000 одновременных загрузок функция сама отмасштабируется.
Serverless — это не замена серверам, а дополнительный инструмент. Используйте его для задач, которые хорошо ложатся на модель коротких, событийно-управляемых функций. Для остального оставляйте Kubernetes или виртуальные машины.
Начинайте с малого: переведите на serverless одну функцию (например, ресайз картинок или отправку email). Оцените затраты и скорость разработки. Потом решите, расширять или нет.
А вы используете serverless?
Поделитесь в комментариях:
- Какую платформу выбрали и почему?
- Сталкивались ли с проблемой холодного старта?
- Как думаете, serverless когда-нибудь полностью заменит традиционные серверы?
Подписывайтесь на «Навигатор по миру IT». Следующая статья — WebAssembly 2026: где он уже работает и зачем он нужен, если у вас не браузерная игра.