«Архитектуры приложений»: немного о бессерверных архитектурах

В стандарте IEEE 1471 ^[1] термин «архитектура» определен ^[2] как базовая организация системы, описывающая связи между компонентами этой системы и внешней средой, а также определяющая принципы её проектирования и развития. В одной из предыдущих статей мы уже рассматривали ^[3] несколько видов архитектур ^[4] программного обеспечения. Сегодня мы обратим свой взор на набирающие популярность бессерверные архитектуры, поскольку это достаточно «горячая» тема в сфере software-решений: уже появляется специальная литература ^[5], фреймворки ^[6], организуются конференции ^[7].

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

^[8]

/ фото John Voo ^[9] CC ^[10]

Бессерверные приложения широко используют сторонние сервисы, которые выполняют задачи, обычно решаемые серверами. Причем эти сервисы могут представлять собой целые экосистемы (например Azure и AWS) или быть самостоятельными решениями (например Parse или Firebase).

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

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

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

Несколько примеров

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

Она [система] состоит из уровня представления, логического уровня и уровня данных. Уровень представления – это компонент, с которым непосредственно взаимодействуют пользователи (веб-страница, интерфейс приложения и др.). Логический уровень содержит код для преобразования действий пользователя, производимых на первом уровне, то есть отвечает за поведение приложения. Уровень данных состоит из хранилища (куда входят базы данных, кэши, файловые системы и др.), где размещаются данные приложения.

Структура выглядит следующим образом:

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

Это достаточно упрощённый вариант, но даже здесь видно, что произошло множество изменений. Задачи аутентификации теперь решает BaaS-сервис (BaaS – Backend-as-a-Service). Через BaaS-сервис также происходит обращение к базе данных, которая хостится ^[11] «на стороне».

Часть серверной логики была перенесена к клиенту, в частности, теперь он занимается слежением за сессией пользователя, страничной навигацией, чтением из базы данных продуктов и отображением информации. А за обработку базы данных покупок теперь отвечает FaaS-функция (FaaS – Function-as-a-Service), которая хранится на сервере для безопасности.

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

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

В случае бессерверной архитектуры получается следующая схема:

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

Достоинства и недостатки бессерверного решения

Передача управления частью систем третьей стороне также порождает свои недостатки. Например, это может ^[12] вылиться в некоторую потерю контроля и, к примеру, непредвиденные апгрейды API. Также разбиение одного приложения на несколько частей со вплетенными в структуру разнообразными сервисами приводит к увеличению «числа точек перегиба», что может усложнить процедуру тестирования.

С другой стороны в силу вступает эффект экономии от масштаба, например, вы платите меньше за управление БД, поскольку вендор обслуживает еще множество таких же однотипных баз данных. Больше всего выгоду такого подхода оценят ^[13] компании, которым приходится иметь дело с нестабильными паттернами потребления трафика. При использовании бессерверных архитектур мощности сервера не будут простаивать в ожидании всплесков активности.

Также бессерверные системы гораздо проще поддерживать. Сторонние компании, предоставляющие облачные услуги, прилагают множество усилий для обеспечения их доступности и масштабируемости. Более того, любая оптимизация производительности FaaS-приложения автоматически снижает операционные издержки. Например, если выполнение какого-либо действия занимало 1 секунду, а после внесения правок стало занимать 200 мс – это приведет к уменьшению стоимости услуги на 80% без изменений в инфраструктуре.

Заключение

Большинство применений FaaS пока что представляют собой обычные приложения, завернутые в новую оболочку. Команды разработчиков «накидывают» новые решения и смотрят, как они поведут себя в контексте бессерверных платформ. Бессерверный подход маловероятно станет панацеей, и вряд ли заменит все существующие архитектуры ^[3], однако можно с уверенностью сказать, что эта область будет развиваться и толкнет вперед сферу разработки программного обеспечения.

P.S. Мы, со своей стороны, также предлагаем несколько интересных материалов из нашего блога о корпоративном IaaS ^[14]:

• Эволюция ERP-систем: отказ от on-premises-инсталляций в пользу облачных и гибридных решений ^[15]
• Зарубежное или локальное размещение данных в облаке: подводные камни ^[16]
• Переезд в облако: трансформация технологий и бизнеса ^[17]
• Первая российская BaaS-платформа Scorocode разместилась в IaaS-облаке «ИТ-ГРАД» ^[18]

Автор: ИТ-ГРАД

Источник ^[19]