Что такое serverless (бессерверные вычисления) простым языком?

Привет, коллеги и те, кто только начинает свой путь в IT! Сегодня хочу поговорить о штуке, которая вот уже несколько лет будоражит умы разработчиков и сисадминов – о serverless, или, как у нас говорят, бессерверных вычислениях. И нет, это не значит, что серверов нет совсем. Это как с Дедом Морозом: он есть, но вы его не видите и не обслуживаете. И это, поверьте моему 20-летнему опыту ковыряния в железе и софте, огромная разница.

Когда я только начинал, любой чих в приложении требовал сервера. Сначала физического, потом виртуального. Это значит: покупка, установка, настройка ОС, патчи, бекапы, мониторинг, борьба с перегревом, с дисковым пространством, с кривыми драйверами… список можно продолжать до бесконечности. Это была наша ежедневная головная боль, наша рутина, порой – наша бессонная ночь. Serverless же обещает снять с вас эту головную боль, оставив только самое приятное: написание кода, который решает задачи.

Что такое serverless: простыми словами

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

В мире IT serverless – это модель, где облачный провайдер (например, Yandex Cloud, VK Cloud, SberCloud в наших реалиях 2025 года) полностью управляет инфраструктурой. Вы пишете свой код (чаще всего это небольшие функции, отсюда и термин Functions as a Service, FaaS), загружаете его, а провайдер сам решает, где и как его запустить, когда на него придет запрос. Он сам масштабирует, сам обеспечивает отказоустойчивость, сам следит за обновлениями ОС. Вы платите только за фактическое время выполнения вашего кода и за количество запросов к нему. Когда код не работает – вы не платите ничего. Гениально, правда?

Зачем оно мне: прелести бессерверного подхода

Я, как человек, который набил шишек с тысячами серверов, вижу тут несколько очевидных плюсов:

• Экономия: Это, пожалуй, самый жирный плюс для бизнеса. Вы платите только за фактическое использование. Если ваш сервис работает час в сутки, вы платите за час, а не за 24 часа работы ВМ. У нас был кейс с внутренним отчетом, который генерировался раз в день и жрал при этом кучу ресурсов. Перевели его на Yandex Cloud Functions – и счет за эту часть инфраструктуры упал в разы. Раньше приходилось держать ВМ с запасом, а теперь – платим по факту.

• Масштабирование без головной боли: Когда на ваш сервис набегут толпы пользователей (а мы все мечтаем об этом, правда?), serverless сам всё разрулит. Было 100 запросов в минуту – запустится 100 функций. Стало 1000 – запустится 1000. Вам не нужно вручную добавлять ВМ, настраивать балансировщики. Это просто работает. В одном из наших проектов, когда мы запускали рекламную кампанию, пиковые нагрузки были непредсказуемы. Serverless вывез, а традиционный подход потребовал бы либо огромного запаса по ресурсам, либо постоянного дежурства и ручного вмешательства.

• Фокус на коде: Разработчики могут сосредоточиться на бизнес-логике, а не на том, как поднять сервер, как настроить Nginx, как обновить пакеты. Это ускоряет разработку и вывод продукта на рынок. Моя команда стала выпускать фичи быстрее, потому что им больше не нужно было ждать, пока я настрою им тестовый стенд на ВМ. Они просто заливали код и проверяли.

• Меньше операционной нагрузки: Для меня, сисадмина, это рай. Меньше серверов – меньше патчей, меньше мониторинга железа, меньше ночных звонков из-за упавшего диска. Конечно, работы всё равно хватает, но она смещается в сторону архитектуры, безопасности и оптимизации расходов, а не рутинной поддержки.

Ложка дегтя: нюансы, о которых не пишут в рекламных буклетах (особенно в наших реалиях)

Теперь о том, что не так радужно. Serverless – это не волшебная палочка, у него есть свои особенности, и некоторые из них в наших российских реалиях 2025 года ощущаются особенно остро.

Вендор-лок: привет из 2025-го

В 2025 году, когда AWS и Azure для многих стали чем-то вроде легенд из прошлого (доступ, оплата – всё это стало дикой головной болью), мы активно крутимся на отечественных платформах: Yandex Cloud, VK Cloud, SberCloud. И это прекрасно, что они развивают свои serverless-предложения. Но вот в чем фишка: у каждого провайдера свои API, свои SDK, свои ‘фишечки’ работы с функциями, свои триггеры, свои способы логирования и мониторинга.

Лайфхак: Если вы пишете на serverless, думайте о переносимости. Не завязывайтесь жестко на специфичные сервисы одного провайдера, если есть универсальные альтернативы. Например, вместо провайдер-специфичной очереди сообщений, рассмотрите использование Kafka или RabbitMQ, если это возможно, или хотя бы абстрагируйте слой взаимодействия. Переехать с Yandex Functions на VK Cloud Functions – это не просто `git push`. Это часто означает переписывание хендлеров, адаптацию к разным моделям событий, перестройку логирования. Я видел, как команды, которые не думали об этом заранее, потом тратили недели на миграцию.

Холодный старт: когда функция «просыпается»

Это, пожалуй, первое, с чем вы столкнетесь. Когда ваша функция долго не использовалась, она «засыпает». При первом запросе провайдеру нужно время, чтобы поднять контейнер с вашей функцией, инициализировать среду, загрузить код. Это называется «холодный старт» (cold start). Мой первый шок был, когда тестовая функция отвечала 5 секунд. Думаешь: что за дичь? А это она просто «прогревалась».

Нюанс: Для бэкенда, который обрабатывает редкие, но критичные по времени запросы (например, авторизация), это может быть проблемой. Пользователь ждет, а мы ‘прогреваем’ функцию. Для фоновых задач или обработки вебхуков это обычно не критично.

Лайфхак: Есть костыли: «keep-alive» – дергать функцию раз в несколько минут, чтобы она не «засыпала». Некоторые провайдеры предлагают «provisioned concurrency» (заранее выделенные ресурсы), но это, конечно, дороже. И главное – пишите легкие функции. Чем меньше зависимостей, чем быстрее инициализация, тем меньше холодный старт.

Мониторинг и отладка: найти черную кошку в черной комнате

Традиционный sysadmin привык к SSH, к `top`, к логам в `/var/log`. Здесь у тебя черный ящик. Ты не можешь зайти на сервер, посмотреть, что там происходит. Функции живут секунды, потом исчезают. Это очень сильно меняет подход к мониторингу.

Нюанс: Если у вас нет хорошо настроенного логирования и распределенного трейсинга, отладка становится адом. Я как-то неделю ловил баг в функции, которая вылетала раз в сутки. Оказалось, банальная утечка памяти, но найти ее без нормального трейсинга – это была жесть. Логи разбросаны, контекст теряется.

Лайфхак: Вложитесь в централизованное логирование (Yandex Cloud Logging, например, или ELK-стек). Используйте структурированные логи (JSON) – это облегчает парсинг. Изучите распределенный трейсинг (OpenTelemetry, Jaeger) – это позволяет отслеживать путь запроса через несколько функций и сервисов. Без этого вы будете как слепой котенок.

Стоимость: не всегда дешево, когда кажется

Да, вы платите за запросы и время выполнения, но это не значит, что всегда дешево. Однажды один разработчик «оптимизировал» функцию, которая начала дергаться по 100 000 раз в минуту из-за неправильной настройки триггера. Счет пришел такой, что волосы дыбом встали. Или функция, которая должна была работать 100 мс, из-за ошибки в коде стала работать 10 секунд. И умножьте это на миллионы вызовов.

Лайфхак: Мониторьте *все* метрики: количество вызовов, время выполнения, используемую память. Настройте бюджеты и алерты в кабинете провайдера. На Yandex Cloud есть отличные инструменты для этого, но их надо настроить. Регулярно анализируйте отчеты о расходах. И самое главное: оптимизируйте код! Чем быстрее функция отработает, тем меньше вы заплатите.

Сложность распределенных систем

Serverless – это не волшебная таблетка, которая убирает все проблемы архитектуры. Наоборот, это заставляет вас думать о контрактах между сервисами, об идемпотентности, о retry-логике, о состоянии. Моя боль: когда разработчики думают, что раз функция, то можно ее дергать как угодно, не заботясь о лимитах или таймаутах. Функции должны быть «самураями»: пришел, сделал дело, ушел, ничего не оставив после себя. Состояние храните во внешних базах данных (например, Yandex Database или PostgreSQL-as-a-service).

Мои кейсы из практики: как мы применяли serverless

За последние пару лет мы перевели на serverless довольно много всего. Вот несколько примеров:

• Автоматизация рутины: Был у нас старый скрипт на VPS, который раз в час ходил по API другого сервиса, парсил данные и что-то там обновлял. Это была постоянная головная боль: скрипт падал, VPS зависал, логи терялись. Перевел его на Yandex Cloud Functions + Yandex Cloud Scheduler (для расписания). Экономия на VPS – копейки, но головной боли с ним – ноль. Работает как часы, логи в одном месте, если что-то пошло не так – получаю уведомление. Красота!

• Telegram-бот для внутренних нужд: Делали внутренний Telegram-бот для оповещений о сбоях и статусах систем. Раньше это был бы микросервис на Кубере или отдельная ВМ, за которой надо следить. Сейчас – одна функция, которая обрабатывает вебхуки от Telegram, и вторая – для отправки сообщений. Развернуть – полчаса. Поддерживать – вообще нечего. Это идеальный кейс для serverless: редкие, но быстрые запросы, обработка событий.

• Обработка изображений: В одном из проектов нужно было ресайзить картинки после загрузки пользователями. Раньше – очередь, воркеры, куча движухи. Сейчас – S3-совместимое хранилище (например, Yandex Object Storage) триггерит функцию при загрузке. Функция ресайзит и кладет обратно. Масштабируется само, платишь только за фактическую работу. Пиковые нагрузки (например, когда много пользователей загружают фото одновременно) обрабатываются без проблем, а в простое – никаких расходов.

• API-шлюзы и бэкенды для мобильных приложений: Для некоторых мобильных приложений и внутренних API мы используем serverless-функции. Это позволяет быстро проверять гипотезы, выкатывать новые фичи, не думая о том, как развернуть и масштабировать бэкенд. Yandex API Gateway отлично интегрируется с функциями, позволяя быстро создавать полноценные API.

Пара советов напоследок

Serverless – это мощный инструмент, но он не панацея. Не пытайтесь перевести весь монолит на serverless за один присест. Начинайте с небольших, изолированных задач, которые хорошо вписываются в событийную модель. Выбирайте правильные кейсы: API-шлюзы, вебхуки, обработка файлов, чат-боты, ETL-процессы. А вот сложную ERP-систему с кучей состояний и транзакций – десять раз подумайте, прежде чем пихать ее в serverless.

Всегда анализируйте свой кейс. Serverless – это не волшебная таблетка, которая убирает все проблемы. Это просто еще один инструмент в вашем арсенале, и как любой инструмент, он хорош для одних задач и не очень подходит для других. Главное – понимать его сильные и слабые стороны и уметь применять с умом.

Удачи в ваших бессерверных приключениях! Если что, пишите, обсудим ваши кейсы. А пока – пошел я, у меня там одна функция что-то подозрительно долго выполняется, надо бы логи глянуть…

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