Нужно ли готовиться к бессерверному будущему?

Что нужно знать о FaaS и serverless-архитектурах

В прошлый раз я рассказывал о том, как модель FaaS помогает максимально автоматизировать функцию DevOps’ов и снизить их вовлечение в само развертывание кода на инфраструктуре. Парадигма, при которой разработчики могут напрямую взаимодействовать с облачной платформой, минуя devops-инженеров, — это совершенно новый уровень абстракции и автоматизации, с которым предстоит сжиться разработчикам. В этой статье в подробностях изложено, что из себя представляют serverless-среды, какое место в них занимает FaaS, а также об их плюсах и минусах.

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

Как и всякая новая парадигма, serverless-подход имеет свои плюсы и минусы. Начнем с хорошего - с позитивных аспектов бессерверных архитектур.

• Простота эксплуатации

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

• Встроенные (и практически неограниченные!) возможности масштабирования

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

• Экономическая эффективность

Биллинговая модель в облачных serverless-инфраструктурах устроена так, что платить за вычислительные ресурсы можно по модели pay as you go - то есть, только за фактически используемые ресурсы.

• Эффективность ресурсов и сокращение time-to-market

Нет ничего более логичного, чем сконцентрировать усилия разработчиков на том, что у них получается лучше всего - а именно на поставке качественного кода. Абстрагирование разработчиков от аспектов инфраструктуры исполнения кода возможно благодаря усилию DevOps’ов - дорогих, высоковостребованных, но немасштабируемых специалистов, понимающих, как должным образом развернуть код на инфраструктуре. Развертывание кода в бессерверной среде помогает значительно сократить время выхода сервиса или приложения - часть функций DevOps’а берет на себя платформа, позволяя не только улучшить TTM, но и сэкономить на ФОТе DevOps-инженеров.

Есть и минусы:

• Архитектурные ограничения

Да, они есть - как в виде “врожденных” особенностей, так и искусственно созданных ограничений. Для serverless-сред, например, характерна задержка за счет инициализации при холодном старте, а также ограничения среды исполнения функции. Из-за отсутствия поддержки состояний (stateless) на стороне сервера бессерверная среда накладывает некоторые ограничения на возможные сценарии использования.

• Сложности с программированием логики приложений

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

• Недостаток нужных навыков разработки

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

• Недостаток контроля

Модель управляемого сервиса дает разработчикам множество преимуществ в плане ускорения разработки и “аутсорсинга” части функций DevOps, но многих из них может отпугнуть то, что исполнение кода нужно доверить облачной инфраструктуре, которая в их глазах играет роль “черного ящика”. С другой стороны, этот минус частично нивелируется тем, что у крупных облачных провайдеров безопасности и изоляции обычно уделяется намного больше внимания и ресурсов, нежели может себе позволить типичная небольшая ИТ-компания.

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

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

В случае с централизованным облачным сервис-провайдером FaaS-сервис содержится в крупном региональном датацентре или сети региональных ЦОДов, где также предоставляются множество других IaaS- и PaaS-сервисов. Плюсы такого решения - в более низкой цене за счёт консолидации ресурсов. Но есть и минусы, в частности, — это ограниченное количество точек присутствия и более длинные маршруты от них до пользователей.

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

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

• Начать с самых подходящих сценариев использования для FaaS — это обычно приложения, склонные к всплескам нагрузки, в которых триггером для вызова функции является определенное событие - например, HTTP-запрос пользователя веб-сайта, у которого могут быть всплески посещаемости. Это поможет извлечь максимальную выгоду из доступных биллинговых моделей и протестировать возможности быстрого масштабирования сервиса.
• При переходе в serverless-среду нужно учитывать, какие облачные сервисы уже предоставляет текущий облачный провайдер. Но это не отменяет необходимости проводить тщательные PoC-исследования для понимания масштабируемости и производительности приложения, а также стоимости владения сервисом.

• Понять структуру расходов в зависимости от бизнес-задач и выбрать более подходящую модель. Биллинг FaaS у провайдера централизованной облачной платформы обычно основан на количестве вызовов функций (наиболее частый вариант вызова – по запросу со стороны пользователя) с ограничением доступных ресурсов и времени исполнения функции. В случае с FaaS в рамках распределенной облачной платформы бизнес-модель схожа, и провайдер услуги может быть также склонен формировать биллинг только на основе количества обрабатываемых запросов, ограничивая доступный объем хранилища или доступное время исполнения функции на инфраструктуре - что можно объяснить более высокой стоимостью владения распределенной инфраструктурой в сравнении с централизованной. Однако, если в приоритете скорость и время отклика, это делает справедливым выбор в сторону FaaS в распределенном облаке в этом случае.

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