Бессерверные вычисления в ПО для бизнеса: экономия простоя или разоряющий тренд?

Представьте, что вы открываете новый сервис, до запуска остаётся месяц, а ваш технический директор предлагает арендовать серверные мощности. Он показывает расчёты: нужно взять с запасом, потому что после запуска нагрузка может вырасти.

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

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

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

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

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

В бессерверной модели вы платите за каждый запуск вашего кода. Нет запросов – код не работает – плата не начисляется. Поступил запрос – платформа запустила выполнение за доли секунды – вы заплатили за время этого выполнения. Закончилась обработка – код остановился – счёт остановился.

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

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

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

«Без серверов» не значит без серверов

Многие заказчики, слыша слово «бессерверный», искренне полагают, что их программное обеспечение каким-то образом работает без серверов. Код размещён в некоем абстрактном пространстве, которое не требует физической инфраструктуры, а значит, не требует и затрат на эту инфраструктуру.

На самом деле серверы никуда не исчезают: они продолжают существовать в дата-центрах облачных платформ. Их по-прежнему тысячи, они занимают целые этажи зданий, потребляют электричество, требуют охлаждения и обслуживания инженерами. Разница не в том, что серверов нет, а в том, кто отвечает за их состояние и кто оплачивает их работу в периоды простоя.

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

Заказчик получает доступ к операционной системе, сам настраивает её, устанавливает необходимое программное обеспечение, следит за обновлениями безопасности, настраивает резервное копирование, контролирует загрузку. И главное – платит за этот сервер фиксированную сумму независимо от того, насколько активно он используется, сервер работает круглосуточно.

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

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

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

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

Сценарии выгодного внедрения

Бессерверные вычисления – это не универсальное решение, подходящее для любого проекта, они наиболее эффективны в определённых условиях. Опыт показывает, что существуют категории проектов, где этот подход не просто даёт экономию, а становится ключевым фактором успеха.

Сценарий первый: проекты с неравномерной нагрузкой

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

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

Бессерверный подход решает эту проблему кардинально:

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

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

Сценарий второй: новые продукты с непредсказуемым спросом

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

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

Бессерверный подход снимает эту проблему:

• На старте затраты на инфраструктуру практически равны нулю — пользователей нет, код не выполняется, платить не за что.
• Когда первые пользователи начинают заходить в сервис, затраты растут пропорционально их количеству.
• Если пользователей становится в десять раз больше, затраты увеличиваются примерно в десять раз.
• Если пользователей не становится вовсе, затраты остаются на минимальном уровне.
• Платформа сама определяет рост нагрузки и выделяет необходимые ресурсы без участия команды разработки.

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

Сценарий третий: обработка событий и фоновые задачи

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

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

Бессерверная модель предлагает иной подход:

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

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

Сценарий четвёртый: расширение существующей системы без её усложнения

У многих компаний есть работающие программные системы, которые были спроектированы и разработаны несколько лет назад, они стабильно выполняют свои основные функции.

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

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

Бессерверный подход позволяет решить эту задачу иначе:

• Дополнительная функция выносится за пределы основной системы и реализуется как отдельный бессерверный компонент.
• Компонент взаимодействует с основной системой через программные интерфейсы, но живёт своей жизнью.
• Код компонента не смешивается с кодом ядра, не увеличивает его сложность.
• Нагрузка от компонента не влияет на производительность основного приложения.
• Если в компоненте возникает ошибка, она не приводит к падению всей системы.
• Пока функция не вызывается, код не выполняется и плата не начисляется.

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

Ловушки бессерверных вычислений

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

Задержка при первом обращении

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

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

Это критично для:

• Пользовательских интерфейсов и мобильных приложений, где пользователь ждёт ответа в реальном времени.
• Административных панелей, в которые сотрудники заходят несколько раз в день.
• Корпоративных порталов, открываемых по утрам.
• Любых систем, где каждая секунда ожидания снижает конверсию или ухудшает пользовательский опыт.

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

Можно также оптимизировать время инициализации, уменьшая объём загружаемого кода и ускоряя подключения к внешним системам, но полностью устранить задержку пробуждения невозможно – это плата за возможность не платить за простой.

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

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

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

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

Если ваш бизнес-процесс предполагает длительные вычислительные операции, можно попробовать разбиение длительной задачи на множество коротких этапов или переход к традиционной модели с выделенными серверами

Непредсказуемость и сложность счета

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

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

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

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

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

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

Как принять решение? Три вопроса на подумать

Переход на бессерверные вычисления или отказ от них – это не техническое решение, которое можно переложить на разработчиков, а стратегическое решение, которое должно приниматься совместно владельцами бизнеса и технической командой.

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

Первый вопрос звучит так: какой профиль нагрузки у нашего проекта и насколько он предсказуем? Ответ на этот вопрос во многом определяет экономическую целесообразность бессерверной модели.

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

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

Второй вопрос требует честной оценки приоритетов компании: что для нас важнее – предсказуемость бюджета или минимизация затрат на старте и гибкость при масштабировании? Здесь нет правильного или неправильного ответа, но ответ определяет, какая модель подходит лучше.

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

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

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

Третий вопрос следует задавать не себе, а подрядчику, который будет разрабатывать или сопровождать систему. Звучит он так: как вы обеспечиваете контроль затрат и что делаете для снижения зависимости от конкретного поставщика? Ответ на этот вопрос покажет, насколько подрядчик опытен в работе с бессерверными вычислениями и насколько он ориентирован на защиту интересов заказчика.

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

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

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

Разработка ПО от 66 Бит

Надеемся, что 10 минут чтения пролетели увлекательно, а в том что полезно даже не сомневаемся, плюс одна технология в копилку знаний! А если вы решились на разработку собственного сервиса или доработку существующего, советуем обратиться в 66 Бит.

Наши опытные специалисты выслушают вашу идею, проведут полный аудит бизнес-процессов и программ и спроектируют эффективное решение, которое приумножит производительность компании! Скорее переходите на наш сайт и знакомьтесь подробнее.