Как serverless-архитектура влияет на модернизацию инфраструктуры

Serverless-архитектура всё увереннее набирает обороты — и неудивительно. Речь о том, что можно просто бросить код в облако, а масштабирование, обновления и даже «железо» доверить провайдеру. Вы спросите: «Никаких бессонных ночей из-за аптайма, никакого счёта за простаивающие мощности?» — платишь только за то, что реально отработало.

Всё радужно и светло, пока не задумаешься о платформах вроде AWS Lambda или Azure Functions. Они действительно решают проблемы, но логичный вопрос — можно ли полагаться на них на все 100%? А что, если резко вырастет трафик? Выдержит ли система, или проект «ляжет» в самый неудобный момент? Попробуем найти ответы и разобрать влияние serverless-архитектуры, её плюсы, недостатки и ключевые технологии. Все под кат!

Торопитесь? Просто кликните по нужному разделу:
→ Что такое serverless-архитектура ^[1]
→ Как serverless меняет подход к построению инфраструктуры ^[2]
→ Преимущества serverless: бизнес-выгоды и новые возможности ^[3]
→ Вызовы и ограничения serverless ^[4]
→ Что стоит учесть при переходе? ^[5]
→ Serverless в кейсах ^[6]
→ Заключение ^[7]

Что такое serverless-архитектура

Serverless-архитектура (бессерверные вычисления) — модель облачных вычислений, где разработчики не управляют серверами напрямую. В её рамках инфраструктуру предоставляют облачные провайдеры, которые автоматически управляют выделением ресурсов и масштабированием приложений. Подход позволяет разработчикам сосредоточиться на написании кода и реализации бизнес-логики, не беспокоясь о серверной инфраструктуре.

Serverless часто называют гибридом микросервисов и облачной инфраструктуры, но это не совсем так. Скорее, это эволюция микросервисного подхода. Если микросервисы требуют самостоятельного управления кластерами и балансировкой (например, через Kubernetes), то в serverless всё это скрыто за абстракцией облака. Ваши функции — это те же микросервисы, но упакованные в формат, который провайдер умеет автоматически масштабировать и запускать по запросу. Например, функция для обработки платежа может быть вызвана тысячу раз в час без вашего участия, а в периоды простоя — вообще не расходовать ресурсы.

Пример — Joot’s Serverless Architecture. На изображении — структура для обработки изображений. Инструменты: Amazon Cognito — управление пользователями, AWS Amplify — библиотека для веб-приложений, AWS Lambda — аутентификация. Изображение ^[8]

FaaS: Функции как услуга — ваш код в облаке без хлопот

Представьте, что можете написать кусочек кода — например, для отправки email или обработки данных — и просто бросить его в облако. Система сама запустит его тогда, когда это понадобится: когда пользователь нажмёт кнопку на сайте, когда в базу добавят новую запись или когда придёт сообщение в чат. Это и есть FaaS (Функции как услуга) — основа serverless-архитектуры.

Как это работает

Вы создаёте функцию — небольшой скрипт, который решает одну задачу. Например, функция «Оформить заказ» берёт данные из формы на сайте, сохраняет их в базе и отправляет клиенту письмо с подтверждением. Эту функцию вы «привязываете» к событию — например, к клику на кнопку «Купить». Как только событие происходит, облачный провайдер моментально запускает ваш код, выделяет ему ресурсы и выключает, когда задача выполнена. Платите только за миллисекунды работы функции — никаких серверов, никаких переплат за простой.

Хочется больше контроля и самостоятельного выбора технологий? Можно собрать свою среду с архитектурой, напоминающей serverless, при этом размещённую на собственном VPS ^[9]. Виртуальные серверы ^[10] отлично подходят для развёртывания решений на базе OpenFaaS, Apache OpenWhisk или других FaaS-фреймворков. Подход позволяет настроить систему под себя, адаптировать под бизнес и сохранить экономичность serverless-модели при оплате за ресурсы.

Почему это удобно?

• Экономия времени и денег. Без аренды «на всякий случай» и настройки инфраструктуры. Если ваш интернет-магазин получит 10 000 заказов за минуту, облако запустит 10 000 копий функции — и справится с нагрузкой.
• Масштаб без усилий. Функции живут в контейнерах, которые исчезают после выполнения задачи. Это как одноразовые рабочие: они приходят, делают дело и уходят, не оставляя следов.
• Фокус на логике, а не на железе. Пишете только «что делать», а провайдер решает, «как это сделать».

А что с большими данными?

Функции, что обрабатывают файлы — будь то картинки, видео или документы, — просто живут в облаке. Забрали нужный объект из S3, сделали свою работу и вернули результат обратно. Зачем вообще думать про сервера, диски и бэкапы, если это всё подхватывает облачный провайдер?

Но не всё так гладко. Помните про «холодный старт» — когда функция после простоя думает пару секунд перед первым вызовом. Для real-time задач это может быть фатально. Обычно прогревают функции заранее или запускают на AWS Graviton2, чтобы эта пауза была незаметной.

А ещё отладка превращается в маленький квест: логи разлетаются по паре десятков сервисов, и баг, который проявляется только в облаке, приходится искать по крупицам. Инструменты вроде AWS SAM CLI и X-Ray помогают, но без пары «танцев с бубном» тут не обойтись…

Как serverless меняет подход к построению инфраструктуры

Переход на бессерверную модель заставляет пересмотреть всё: от архитектуры до оперативных процессов. Упростить процессы, открыть новые возможности для бизнеса и команд разработки.

Ключевые преимущества serverless-компьютинга. Изображение ^[11]

Преимущества serverless: бизнес-выгоды и новые возможности

Компании, получают сразу несколько преимуществ. По оценкам отраслевых исследований Forrester ^[12], такие фичи позволяют сократить время вывода продуктов на рынок на 23%. Внутри команд это проявляется так: разработчик пушит изменения в репозиторий — и буквально через пару минут всё уже готово к тестированию, а затем к продакшену. Нет больше рутинных правок серверных конфигураций и бесконечной возни с инстансами.

Финансово тоже приятно: платишь только за то, что реально использовал, компании снижают ^[13] операционные расходы на 30%. Snapchat, например, урезал инфраструктурные расходы на 40%, просто выкинув постоянные серверы и перейдя на модель «вызвал — заплатил».

Адаптация к нагрузке? Пушка. Когда юзеры прут — ресурсы масштабируются автоматически, когда затишье — сворачиваются. AWS ^[14] пишет, что производительность в таких случаях вырастает на 35–50%. И да, больше никакого перегрева на пиках.

Развёртывание стало проще. CI/CD-конвейеры + декларативные шаблоны = «накатить» стало почти как открыть pull request. Цикл «код → тест → прод» ускорился в разы. Это особенно кайф для стартапов, где каждый день может решить судьбу фичи.

▍ Прогнозы и исследования

Исследования ^[11] говорят о том, что больше 70% компаний, которые начали использовать serverless, заметили, что время разработки стало меньше, а качество приложений — лучше. Это действительно бросается в глаза, и теперь serverless становится основным выбором для компаний, которые хотят расти и развиваться.

Отчёт о мировом рынке serverless-архитектуры. Изображение ^[15]

Цифры тоже говорят сами за себя. Рынок ^[15] serverless растёт быстро — с $11,77 млрд в 2023 году до $33,36 млрд в 2028 году. Это примерно 23% роста каждый год. Такие темпы — одни из самых высоких в IT.

Вызовы и ограничения serverless

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

▍ Проблемы с безопасностью и контроль над инфраструктурой

Один из главных рисков — это неправильный контроль доступа. Если функция получает больше прав, чем ей нужно, злоумышленник может воспользоваться этим и проникнуть в систему. Например, если функция, которая должна только читать данные, вдруг получает доступ для записи. Чтобы этого избежать ^[16], нужно давать минимум прав: функция делает только то, что ей положено, и всё.

Сравнение классической и serverless-архитектуры. Изображение ^[17]

С ростом числа функций сложнее отслеживать ключи шифрования и правильность настроек. Это может привести к тому, что забытые пароли или неправильные права доступа окажутся в руках не тех людей.

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

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

▍ Рекомендации

Централизованное логирование. Используйте инструменты ^[18] для агрегирования логов в одном месте, например, ELK Stack (Elasticsearch, Logstash, Kibana), Splunk. Упростит анализ и управление данными.

Автоматические оповещения. Установите пороги для ключевых метрик — время выполнения функций, число ошибок или задержки — платформа пришлёт сигнал, как только что-то пойдёт не так. Так вы сможете мгновенно отреагировать на аномалию или просадку производительности, не дожидаясь, пока проблема разрастётся в серьёзный инцидент.

▍ Пределы масштабируемости и производительности

Хотя serverless-архитектура предлагает высокую степень масштабируемости, она не является универсальным решением. У разных облачных провайдеров существуют ограничения по времени выполнения функций, объёму памяти и другим ресурсам, «потолки» которые не перепрыгнуть. Рассмотрим основные лимиты.

Холодные старты. Как уже говорили в начале, функция долго не используется, из-под неё освобождаются выделенные ресурсы. При следующем запросе функция заново инициализируется, что приводит к задержке. Критично для задач с большими зависимостями или требующими детальной настройки ^[19].

Ограничения по времени выполнения. Например, AWS Lambda ограничивает работу функции 15 минутами. Этого может быть недостаточно для сложных вычислительных задач или обработки больших объёмов данных (вендор-локирование).

Зависимость от провайдера. API и инструменты разных облачных платформ могут отличаться, что усложняет миграцию serverless-приложений.

Что стоит учесть при переходе?

Рекомендации помогут вам успешно перейти на serverless-архитектуру и использовать её преимущества максимально эффективно.

Оцените влияние холодных стартов на производительность вашего приложения. Пример: оптимизируйте время холодного старта, используя легковесные языки программирования. Для этих целей подойдут Go или Node.js. Поддерживайте активные экземпляры функций.

Убедитесь, что выбранный вами облачный провайдер поддерживает необходимые языки программирования и функции. Например, проверьте поддержку библиотек и фреймворков для Python на AWS Lambda или Azure Functions, а также наличие инструментов для мониторинга.
Обратите внимание на лучшие практики безопасности при проектировании serverless-приложений. 

Позаботьтесь о том, чтобы приложение росло вместе с нагрузкой: когда трафик прыгает, «домножьте» сервисы — запускайте дополнительные инстансы и направляйте запросы через балансировщик.

Не ждите, а сразу вооружитесь нагрузочным тестированием: прогоняйте симуляции пиков, следите за метриками в реальном времени и реагируйте на первые сигналы «застревающих» запросов и падения throughput. Так вы не только поймаете узкие места, но и убедитесь, что в случае реального наплыва пользователей ваша система выдержит любую ситуацию.

Serverless в кейсах

Это не тренд, а инструмент лидеров рынка — Netflix и Coca-Cola уже перестроили процессы, сократив затраты на инфраструктуру на 30-40% и ускорив запуск продуктов в 2 раза. Переходим к кейсам.

▍ Netflix

Использование 

Netflix использует Amazon Web Services (AWS) для вычислений, хранения данных и баз данных, аналитики и транскодирования видео. Более 100 000 серверных инстансов на AWS поддерживают работу Netflix ^[20], что позволяет компании эффективно обрабатывать миллионы запросов пользователей по всему миру.

Влияние на бизнес

Serverless обеспечивает стабильную производительность даже в пиковые часы. По данным iFellow, Netflix избегает избыточных затрат на поддержание пропускной способности в периоды низкой активности.

Ещё одна сфера, где Netflix накопила большой опыт — машинное обучение.

▍ Coca-Cola

Использование

Coca-Cola внедрила умные торговые автоматы Freestyle ^[21], которые позволяют клиентам создавать собственные напитки. Они используют serverless-архитектуру для обработки транзакций. 

Изображение ^[21]

Влияние на бизнес

Coca-Cola держала шесть серверов EC2 T2.Medium чтобы управлять вендинговыми машинами. Это обходилось в $12,864 в год. После миграции годовые расходы снизились до $4,490, что составило экономию около 65%. При этом нагрузка выросла с 30 до 80 миллионов запросов в месяц, без последствий.

▍ Airbnb

Использование 

Airbnb разработала StreamAlert ^[22] — serverless -фреймворк для анализа данных в реальном времени. Он справляется с терабайтами логов ежедневно, не требуя серверов или кластеров. При срабатывании любого правила он сразу же отправляет уведомление или триггерит дальнейшие обработчики.

Влияние на бизнес

StreamAlert позволяет оперативно реагировать на изменения в данных и улучшать пользовательский опыт.

▍ Uber

Использование

Разработал Catalyst, для упрощения взаимодействия между разработчиками и инфраструктурой.
И внедрил serverless для обработки данных о поездках и управления сервисами.

Влияние на бизнес

Снизились операционные расходы за счёт уменьшения необходимости в постоянной поддержке серверной инфраструктуры. Система стала плавно обрабатывает миллионы событий в секунду в часы пик, автоматически расширяя или сворачивая ресурсы по требованию.

▍ Major League Baseball (MLB)

Использование

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

Влияние на бизнес

Бесперебойная работа во время плей-офф, без дополнительного управления серверами. Снизились затраты на инфраструктуру по сравнению с кластерами. Скорость обработки и анализа данных теперь измеряется миллисекундами, что даёт конкурентное преимущество аналитическим отделам клубов и ускоряет внедрение функций на сайте MLB.com и в приложениях.

▍ Статистика и полезные данные

Почти каждый второй инженер уже ощутил ^[23] выгоду от serverless: 43 % говорят, что в разы сократили время на поддержку инфраструктуры, а 49 % вообще отметили, что управление серверами отошло на второй план. Одновременно рынок serverless-решений стремительно растёт: от 12,7 млрд $ в 2023-м до ожидаемых 58,2 млрд к 2032 году.

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

Заключение

Serverless-архитектура перестала быть экспериментом — это мейнстрим, который в 2025 году затронет около 95 % новых цифровых сервисов.

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

Но важно помнить, что всё это работает только тогда, когда внутри команды меняется подход к разработке: не «как мы настроили сервера», а «какую ценность мы приносим людям». Именно такие компании — которые грамотно вписывают serverless в свои процессы, меняют культуру DevOps и ставят приоритет на автоматизацию — получают конкурентное преимущество.

Делитесь мнением в комментариях!

© 2025 ООО «МТ ФИНАНС»