Привет, Хабр! Как менеджер продукта и один из амбассадоров serverless я регулярно рассказываю о преимуществах этого подхода и показываю, как с помощью бессерверных вычислений повысить эффективность затрат на инфраструктуру. Но как и у любого подхода, у serverless есть свои ограничения, которые важно учесть в своей IT‑стратегии.

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

Что говорят айтишники: state of serverless 2023

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

Сценарии и задачи. В 2023 году чаще всего бессерверные решения используют для:

• загрузки и хранения данных (41%),

• оптимизации работы поиска в приложениях, а также обработки файлов с использованием контейнеров (по 24%),

• для проведения вычислений, создания и хранения API сервисов, хранения и управления ключами, доступами и секретами (по 23%).

Если рассматривать укрупнённо, то наиболее популярными сценариями в этом году стали:

• аналитика данных (48%),

• сбор и поставка данных в системы хранения (44%),

• управление облачной инфраструктурой (34%).

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

• нарушения взаимосвязей и основ интеграции между разными сервисами,

• возникновение ошибок в коде,

• сбои в конфигурациях разных сервисов.

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

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

Техническая изнанка проблем

При создании бессерверных приложений важна событийно ориентированная архитектура (event-driven architecture, EDA). Напомню, что это архитектурный паттерн, построенный из децентрализованных сервисов, которые публикуют, обрабатывают или маршрутизируют события — сообщения, отправляемые между сервисами. Такой подход облегчает масштабирование, обновление и независимый деплой различных компонентов системы. 

Приложения, построенные на базе происходящих в системе событий, можно встретить не только в serverless-мире. Но при бессерверном подходе это довольно принципиальный момент.

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

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

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

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

1. Сервисы, с помощью которых исполняется бизнес‑логика задач.

   • Облачные функции (Cloud Functions) — сервис для запуска кода в виде функции.

   • Бессерверные контейнеры (Serverless Containers) — про такой сервис мы уже рассказывали подробнее в прошлый раз.

2. Сервисы для работы с данными.

   • База данных в режиме serverless.

   • Сервис для управления потоками данных (Data Streams).

   • Сервис очередей (Message Queue).

   • Объектное хранилище (Object Storage).

3. Интеграционные сервисы, которые являются точками входа для обработки нагрузки. 

   • Сервис для создания API-шлюзов (API Gateway).

Типовые сценарии для serverless-архитектуры 

Обратимся к конкретным задачам, которые решаются при бессерверном подходе. 

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

• авторизация пользователя; 

• просмотр каталога кино; 

• выставление оценок понравившейся кинокартине; 

• добавление фильма в каталог. 

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

• статические объекты находятся в объектном хранилище; 

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

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

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

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

Выделенный микросервис. Но мы не всегда хотим строить тотальный serverless. Поэтому бессерверные вычисления можно интегрировать в инфраструктуру и отдельными микросервисами — какой архитектура будет в этом случае?

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

Для загрузки видеозаписей используем объектное хранилище, что позволит недорого хранить довольно объёмные файлы. При этом конвертация видеофайлов может потребовать аппаратных ресурсов (ASIC‑/FPGA‑чипы или GPU), так что эту логику удобно оставить в существующем контуре виртуальных машин или нод Kubernetes‑кластера.

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

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

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

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

• принять эти данные;

• трансформировать;

• сохранить;

• прочитать.

Для приёма данных из разных источников по HTTP мы можем использовать связку:

API‑шлюз → управление потоками данных → облачные функции / Data Transfer.

Это позволит нам в потоковом режиме принимать, трансформировать и сохранять данные в управляемом ClickHouse и объектном хранилище, из которых удобно визуализировать данные на дашбордах или анализировать их с помощью сервиса для выполнения потоковых запросов.

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