Нужно ли готовиться к бессерверному будущему?
Что нужно знать о 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 пока имеет некоторые незакрытые пробелы. Например, то, что инфраструктура становится для разработчика “черным ящиком”, ограничивает возможности дебаггинга кода и мониторинга исполнения функции на уровне сервера. Это само по себе нельзя назвать недостатком технологии; скорее это означает, что при разработке нужно учесть очень много тонкостей.
Как реализованы FaaS-сервисы на централизованных и распределенных облачных платформах
В случае с централизованным облачным сервис-провайдером FaaS-сервис содержится в крупном региональном датацентре или сети региональных ЦОДов, где также предоставляются множество других IaaS- и PaaS-сервисов. Плюсы такого решения - в более низкой цене за счёт консолидации ресурсов. Но есть и минусы, в частности, — это ограниченное количество точек присутствия и более длинные маршруты от них до пользователей.
В противоположность этому, в случае с распределенным облачным провайдером FaaS-решение реализовано на инфраструктуре с множеством точек присутствия. В сравнении с реализацией FaaS внутри облачного сервис-провайдера с консолидированными ЦОДами, реализация FaaS на распределенной платформе имеет преимущество в части снижения задержки - запросы обрабатываются максимально близко к пользователю.
Перед переходом на FaaS осталось определить, что важнее, и здесь нужно учесть несколько факторов, которые индивидуальны для каждого заказчика в зависимости от его бизнес-задач: емкость сети, охват, снижение нагрузки на серверы оригинации, возможности масштабирования, число и точки размещения узлов и так далее.
Как начать жить с FaaS/Serverless
- Начать с самых подходящих сценариев использования для FaaS — это обычно приложения, склонные к всплескам нагрузки, в которых триггером для вызова функции является определенное событие - например, HTTP-запрос пользователя веб-сайта, у которого могут быть всплески посещаемости. Это поможет извлечь максимальную выгоду из доступных биллинговых моделей и протестировать возможности быстрого масштабирования сервиса.
- При переходе в serverless-среду нужно учитывать, какие облачные сервисы уже предоставляет текущий облачный провайдер. Но это не отменяет необходимости проводить тщательные PoC-исследования для понимания масштабируемости и производительности приложения, а также стоимости владения сервисом.
- Понять структуру расходов в зависимости от бизнес-задач и выбрать более подходящую модель. Биллинг FaaS у провайдера централизованной облачной платформы обычно основан на количестве вызовов функций (наиболее частый вариант вызова – по запросу со стороны пользователя) с ограничением доступных ресурсов и времени исполнения функции. В случае с FaaS в рамках распределенной облачной платформы бизнес-модель схожа, и провайдер услуги может быть также склонен формировать биллинг только на основе количества обрабатываемых запросов, ограничивая доступный объем хранилища или доступное время исполнения функции на инфраструктуре - что можно объяснить более высокой стоимостью владения распределенной инфраструктурой в сравнении с централизованной. Однако, если в приоритете скорость и время отклика, это делает справедливым выбор в сторону FaaS в распределенном облаке в этом случае.
Осталось выяснить, каковы самые очевидные и многообещающие сценарии использования FaaS - но об этом, наверное, уже в следующий раз.
NGENIX, серьёзно?