Они рассматривают архитектуру ПО с одной точки зрения. И это опасно.

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

В начале видео автор пошутил: «В этом мире есть две вещи, которых я не понимаю, –девушки и бессерверность».

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

---

Критика бессерверных решений

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

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

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

Что упускают некоторые инженеры? Истинные преимущества бессерверной архитектуры

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

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

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

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

Холодный старт – это вопрос комплектации и бюджета

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

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


Возможности наблюдения Dashbird помогают выявлять и предотвращать холодные запуски

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


Настройка алерта при холодном старте в Dashbird

Способы уменьшения задержки ваших лямбда-функций

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

Есть очень много крутых статей, в которых обсуждается, как смягчить последствия проблем с холодным запуском или даже полностью устранить эти проблемы, вот первая, а вот вторая. Dashbird имеет опенсорс-библиотеку на Python под названием xlambda, которая поможет вам сохранить лямбда-функции на основе Python в тепле. Джереми Дейл также опубликовал открытый исходный код похожего пакета пакета Lambda Warmer для JavaScript. Наконец, бессерверная структура также включает плагин, который предлагает ту же функциональность.

Какая задержка приемлема для ваших рабочих нагрузок?

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

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

Бессерверные решения – это о «NoOps» и масштабируемости

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

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

Кейсы, которые сильно выигрывают благодаря бессерверным решениям

Представьте, что вы только что основали стартап. Сначала вам может не понадобиться большой кластер ресурсов и у вас может быть только один разработчик. Бессерверная парадигма позволяет вам начинать с малого и автоматически масштабировать ресурсы по мере роста вашего стартапа с помощью модели затрат pay-as-you-go.

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

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

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

Скорость кода vs. скорость циклов разработки

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

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

Полная интеграция с другими облачными сервисами

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

Недостатки бессерверных решений

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

• Несмотря на то что для многих случаев использования, бессерверные решения кажутся раем, с точки зрения затрат, масштабируемости и обслуживания, всё же это не лучшая альтернатива для каждого варианта использования.
• Вендоры облачных услуг делают свои услуги настолько удобными и экономичными, что вы неизбежно рискуете быть привязанными к их конкретной платформе.
• Если сравнивать бессерверные и автономные ресурсы, у вас в определённой степени меньше контроля над вычислительными ресурсами. Например, вы не можете подключиться по SSH к базовым вычислительным экземплярам для выполнения некоторой конфигурации вручную, а также у вас меньше свободы в отношении типа экземпляра. Например, вы не можете запускать свои бессерверные функции или контейнеры на вычислительных экземплярах с графическими процессорами (пока).
• Если у вас есть какие-то особые требования соответствия, которые не позволяют вам обрабатывать ваши данные на общем клиенте в облаке, то бессерверный вариант может быть для вас невозможен.
• Несмотря на то что разделение вашей IT-инфраструктуры на автономные микросервисы помогает управлять зависимостями и позволяет сократить циклы релизов, это создаёт еще одну проблему, касающуюся управления всеми подвижными частями. Хотя решения для мониторинга, такие как Dashbird, в значительной степени решают эту конкретную проблему, вам необходимо знать о компромиссах.

Выводы

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

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

---

• Курс по DevOps
• Профессия Data Scientist
• Профессия Data Analyst