Бессерверные вычисления: почему некоторые разработчики упускают главное?

На эту тему перевели для вас интересные и достаточному простые мысли дата-инженера Анны Аннисени.

Недавно я посмотрела видеоролик замечательного разработчика и ютубера Бена Авада (Ben Awad), в котором он высказал мнение, что бессерверные технологии лишены смысла. Ролик мне смотреть было интересно – но я не могу сказать, что полностью разделяю отношение автора к бессерверным технологиям. Своим мнением я хотела бы поделиться в этой статье.

В начале ролика автор шутит:

Ничего не могу сказать об отношениях Бена с девушками, – но прав ли он, когда речь заходит о бессерверных вычислениях? Давайте рассмотрим приведенные им критические доводы и обсудим возможные контраргументы. Спойлер: Я считаю, что в бессерверных технологиях ЕСТЬ смысл, – если знать, КОГДА и КАК их использовать.

Основной аргумент, упомянутый в этом несколько спорном YouTube-ролике – это недостаточно высокая скорость выполнения кода. Если говорить конкретнее, основной недостаток бессерверных приложений с позиций автора – это (общеизвестная) проблема «холодного запуска» . Она связана с появлением дополнительной задержки, при которой код может не начать выполняться до тех пор, пока облачная инфраструктура не выделит необходимые вычислительные ресурсы, не подтянет программный код или образ контейнера, не установит дополнительные пакеты и не настроит среду выполнения.

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

Если скорость выполнения кода настолько важна для вас, что лишние 200 мс задержки (по оценкам AWS задержка может достигать 1 сек) не приемлемы для ваших рабочих нагрузок, в таком случае бессерверные технологии и в самом деле не вариант, и это абсолютно нормальная ситуация. Однако не стоит заходить слишком далеко и утверждать, что такая задержка сводит на нет всю пользу бессерверных технологий. Каждый должен сам для себя решить, какая задержка приемлема в конкретном сценарии.

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

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

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

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

Если вы готовы заплатить чуть больше, есть много способов смягчить проблему холодных запусков, например, при помощи предварительно прогретых виртуальных машин (механизм Provisioned Concurrency). Еще можно намеренно генерировать больше запросов (так называемые фейковые запросы), чтобы ваша операционная среда не успевала остыть. Используя платформу мониторинга, например, Dashbird, очень легко настроить уведомления о любом холодном запуске и оптимизировать нагрузку на бессерверные ресурсы. На картинке ниже видно, что на 29 выполненных вызовов пришелся всего один холодный запуск, что добавило примерно 180 миллисекунд задержки к общему времени выполнения.

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

Вы можете уменьшить задержку выполнения функций при бессерверных вычислениях, если правильно настроите повторное использование контекста. AWS замораживает и сохраняет контекст выполнения функции AWS Lambda – то есть все, что происходит за пределами функции-обработчика. Если в течение последующих 15 минут такая же функция будет запущена еще раз, «замороженная» среда выполнения будет использована повторно. Это означает, что производительность будет существенно выше, если вынести затратные по времени операции, например, подключение к реляционной базе данных, за пределы обработчика в функции AWS Lambda. В данной статье эта тема разъяснена очень подробно.

Существует масса прекрасных статей, в которых рассказывается, как уменьшить или даже полностью устранить проблемы, связанные с холодным запуском: например, эта и эта. Более того, в Dashbird есть открытая библиотека Python под названием xlambda, которая не даст остыть функциям AWS Lambda, написанным на языке Python.

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

Наконец, такие платформы, как бессерверный сервис Kubernetes от AWS (также известный под названием "EKS на Fargate") позволяет объединить бессерверный и серверный уровни данных на одном кластере Kubernetes. Такое сочетание позволяет запускать критически важные рабочие нагрузки, требующие низкой задержки, на серверном уровне данных на базе Amazon EC2, а другие виды рабочей нагрузки (например, пакетную обработку данных) – на бессерверном уровне данных, – и получить лучшее из двух подходов. Подробнее об этом можно узнать в этой статье.

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

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

Представьте себе, что вы только что основали стартап. В начале вам может и не понадобиться большой кластер ресурсов, да и разработчик, вероятно, всего один. Концепция бессерверных вычислений позволяет вам начать с малого и автоматически масштабировать свои ресурсы по мере роста стартапа, используя принцип оплаты по мере использования («pay-as-you-go»).

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

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

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

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

Если бессерверная технология оперативно предоставляет доступ к самым первым версиям вашего приложения всем заинтересованным лицам и ускоряет итерации в цикле разработки (одновременно снижая затраты), – может быть, иногда можно пережить задержку в несколько миллисекунд при эпизодических холодных запусках?

По примеру AWS все бессерверные сервисы интегрировались с CloudWatch – для поддержки логирования, с IAM – для управления правами доступа, с CloudTrail – для сбора метрик и трассировки, а также со многими другими системами. Помимо этого, бессерверные платформы обычно предоставляют базовые конструктивные блоки для создания более крупных слабо связанных микросервисных архитектур, включая интеграцию с бессерверной очередью сообщений (SQS), бессерверной шиной сообщений «publish-subscribe» (SNS), бессерверным хранилищем данных NoSQL (DynamoDB), а также объектным хранилищем данных (S3).

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

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

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

Я считаю, что мы не должны говорить о бессерверных вычислениях (впрочем, как и о каких-либо других информационных технологиях) в контексте какого-то одного аспекта, игнорируя другие, не менее важные, – особенно те, для которых эта технология исходно разрабатывалась. В этом ключе в бессерверных технологиях ЕСТЬ смысл, если знать, КОГДА и КАК их использовать.

Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

Другие истории, которые активно читают наши подписчики:

#yandexcloud #облачные_сервисы #serverless #разработка