В стандарте IEEE 1471 термин «архитектура» определен как базовая организация системы, описывающая связи между компонентами этой системы и внешней средой, а также определяющая принципы её проектирования и развития. В одной из предыдущих статей мы уже рассматривали несколько видов архитектур программного обеспечения. Сегодня мы обратим свой взор на набирающие популярность бессерверные архитектуры, поскольку это достаточно «горячая» тема в сфере software-решений: уже появляется специальная литература, фреймворки, организуются конференции.
Бессерверная архитектура означает, что разработчикам больше не нужно настраивать и администрировать серверы, на которых запущены управляющие программы всей системы. И здесь дело не в том, что нет совершенно никаких серверов, просто вся инфраструктура поддерживается сторонними провайдерами, а необходимая функциональность предлагается в форме сервисов, отвечающих за процессы аутентификации, передачи сообщений и так далее.
/ фото John Voo CC
Бессерверные приложения широко используют сторонние сервисы, которые выполняют задачи, обычно решаемые серверами. Причем эти сервисы могут представлять собой целые экосистемы (например Azure и AWS) или быть самостоятельными решениями (например Parse или Firebase).
Одной из главных задач серверных веб-приложений является контроль цикла запросов и ответов. Контроллеры на стороне сервера обрабатывают входные запросы, запускают необходимые приложения и выстраивают ответы. В случае бессерверной архитектуры контроллеры на стороне сервера заменяются процессами генерации динамического контента.
Еще одной значимой частью серверных веб-приложений является бизнес-логика, когда на сервере располагается код, выполняющий обработку запросов на протяжении всего времени работы приложения.
В бессерверных приложениях специальные программные компоненты активизируются только тогда, когда поступает запрос. После обработки запроса компонент «засыпает». Этот код часто располагается в управляемой среде, которая заботится о масштабируемости кода и следит за жизненным циклом.
Представим классическую трехуровневую клиентоориентированную систему с серверной логикой. Это популярный шаблон для приложений, взаимодействующих с пользователями (хорошим примером может служить типичное ecommerce-приложение).
Она [система] состоит из уровня представления, логического уровня и уровня данных. Уровень представления – это компонент, с которым непосредственно взаимодействуют пользователи (веб-страница, интерфейс приложения и др.). Логический уровень содержит код для преобразования действий пользователя, производимых на первом уровне, то есть отвечает за поведение приложения. Уровень данных состоит из хранилища (куда входят базы данных, кэши, файловые системы и др.), где размещаются данные приложения.
Структура выглядит следующим образом:
В этом случае вся логика расположена на сервере (аутентификация, навигация, поиск), потому клиентская часть может оставаться «глупой». А вот один из вариантов структуры того же приложения при переходе на бессерверную архитектуру:
Это достаточно упрощённый вариант, но даже здесь видно, что произошло множество изменений. Задачи аутентификации теперь решает BaaS-сервис (BaaS – Backend-as-a-Service). Через BaaS-сервис также происходит обращение к базе данных, которая хостится «на стороне».
Часть серверной логики была перенесена к клиенту, в частности, теперь он занимается слежением за сессией пользователя, страничной навигацией, чтением из базы данных продуктов и отображением информации. А за обработку базы данных покупок теперь отвечает FaaS-функция (FaaS – Function-as-a-Service), которая хранится на сервере для безопасности.
Рассмотрим другой пример. Предположим, что пользователь кликает на рекламный баннер. В этом случае вам нужно быстро перенаправить клиента на целевой сайт, одновременно сохранив информацию о совершенном переходе, чтобы выставить счет рекламодателю.
В этом случае традиционная архитектура может выглядеть следующим образом: сервер рекламы грузит страницу для пользователя, одновременно отсылая сообщение в канал, который асинхронно обрабатывается сервисом переходов, обновляющим базы данных.
В случае бессерверной архитектуры получается следующая схема:
Здесь пользовательское приложение заменяется FaaS-функцией, которая работает внутри управляемого событиями контекста, предоставляемого вендором. При этом среда FaaS может обрабатывать несколько кликов пользователей параллельно, создавая копии кода функции.
Передача управления частью систем третьей стороне также порождает свои недостатки. Например, это может вылиться в некоторую потерю контроля и, к примеру, непредвиденные апгрейды API. Также разбиение одного приложения на несколько частей со вплетенными в структуру разнообразными сервисами приводит к увеличению «числа точек перегиба», что может усложнить процедуру тестирования.
С другой стороны в силу вступает эффект экономии от масштаба, например, вы платите меньше за управление БД, поскольку вендор обслуживает еще множество таких же однотипных баз данных. Больше всего выгоду такого подхода оценят компании, которым приходится иметь дело с нестабильными паттернами потребления трафика. При использовании бессерверных архитектур мощности сервера не будут простаивать в ожидании всплесков активности.
Также бессерверные системы гораздо проще поддерживать. Сторонние компании, предоставляющие облачные услуги, прилагают множество усилий для обеспечения их доступности и масштабируемости. Более того, любая оптимизация производительности FaaS-приложения автоматически снижает операционные издержки. Например, если выполнение какого-либо действия занимало 1 секунду, а после внесения правок стало занимать 200 мс – это приведет к уменьшению стоимости услуги на 80% без изменений в инфраструктуре.
Большинство применений FaaS пока что представляют собой обычные приложения, завернутые в новую оболочку. Команды разработчиков «накидывают» новые решения и смотрят, как они поведут себя в контексте бессерверных платформ. Бессерверный подход маловероятно станет панацеей, и вряд ли заменит все существующие архитектуры, однако можно с уверенностью сказать, что эта область будет развиваться и толкнет вперед сферу разработки программного обеспечения.
P.S. Мы, со своей стороны, также предлагаем несколько интересных материалов из нашего блога о корпоративном IaaS:
Бессерверная архитектура означает, что разработчикам больше не нужно настраивать и администрировать серверы, на которых запущены управляющие программы всей системы. И здесь дело не в том, что нет совершенно никаких серверов, просто вся инфраструктура поддерживается сторонними провайдерами, а необходимая функциональность предлагается в форме сервисов, отвечающих за процессы аутентификации, передачи сообщений и так далее.
/ фото John Voo CC
Бессерверные приложения широко используют сторонние сервисы, которые выполняют задачи, обычно решаемые серверами. Причем эти сервисы могут представлять собой целые экосистемы (например Azure и AWS) или быть самостоятельными решениями (например Parse или Firebase).
Одной из главных задач серверных веб-приложений является контроль цикла запросов и ответов. Контроллеры на стороне сервера обрабатывают входные запросы, запускают необходимые приложения и выстраивают ответы. В случае бессерверной архитектуры контроллеры на стороне сервера заменяются процессами генерации динамического контента.
Еще одной значимой частью серверных веб-приложений является бизнес-логика, когда на сервере располагается код, выполняющий обработку запросов на протяжении всего времени работы приложения.
В бессерверных приложениях специальные программные компоненты активизируются только тогда, когда поступает запрос. После обработки запроса компонент «засыпает». Этот код часто располагается в управляемой среде, которая заботится о масштабируемости кода и следит за жизненным циклом.
Несколько примеров
Представим классическую трехуровневую клиентоориентированную систему с серверной логикой. Это популярный шаблон для приложений, взаимодействующих с пользователями (хорошим примером может служить типичное ecommerce-приложение).
Она [система] состоит из уровня представления, логического уровня и уровня данных. Уровень представления – это компонент, с которым непосредственно взаимодействуют пользователи (веб-страница, интерфейс приложения и др.). Логический уровень содержит код для преобразования действий пользователя, производимых на первом уровне, то есть отвечает за поведение приложения. Уровень данных состоит из хранилища (куда входят базы данных, кэши, файловые системы и др.), где размещаются данные приложения.
Структура выглядит следующим образом:
В этом случае вся логика расположена на сервере (аутентификация, навигация, поиск), потому клиентская часть может оставаться «глупой». А вот один из вариантов структуры того же приложения при переходе на бессерверную архитектуру:
Это достаточно упрощённый вариант, но даже здесь видно, что произошло множество изменений. Задачи аутентификации теперь решает BaaS-сервис (BaaS – Backend-as-a-Service). Через BaaS-сервис также происходит обращение к базе данных, которая хостится «на стороне».
Часть серверной логики была перенесена к клиенту, в частности, теперь он занимается слежением за сессией пользователя, страничной навигацией, чтением из базы данных продуктов и отображением информации. А за обработку базы данных покупок теперь отвечает FaaS-функция (FaaS – Function-as-a-Service), которая хранится на сервере для безопасности.
Рассмотрим другой пример. Предположим, что пользователь кликает на рекламный баннер. В этом случае вам нужно быстро перенаправить клиента на целевой сайт, одновременно сохранив информацию о совершенном переходе, чтобы выставить счет рекламодателю.
В этом случае традиционная архитектура может выглядеть следующим образом: сервер рекламы грузит страницу для пользователя, одновременно отсылая сообщение в канал, который асинхронно обрабатывается сервисом переходов, обновляющим базы данных.
В случае бессерверной архитектуры получается следующая схема:
Здесь пользовательское приложение заменяется FaaS-функцией, которая работает внутри управляемого событиями контекста, предоставляемого вендором. При этом среда FaaS может обрабатывать несколько кликов пользователей параллельно, создавая копии кода функции.
Достоинства и недостатки бессерверного решения
Передача управления частью систем третьей стороне также порождает свои недостатки. Например, это может вылиться в некоторую потерю контроля и, к примеру, непредвиденные апгрейды API. Также разбиение одного приложения на несколько частей со вплетенными в структуру разнообразными сервисами приводит к увеличению «числа точек перегиба», что может усложнить процедуру тестирования.
С другой стороны в силу вступает эффект экономии от масштаба, например, вы платите меньше за управление БД, поскольку вендор обслуживает еще множество таких же однотипных баз данных. Больше всего выгоду такого подхода оценят компании, которым приходится иметь дело с нестабильными паттернами потребления трафика. При использовании бессерверных архитектур мощности сервера не будут простаивать в ожидании всплесков активности.
Также бессерверные системы гораздо проще поддерживать. Сторонние компании, предоставляющие облачные услуги, прилагают множество усилий для обеспечения их доступности и масштабируемости. Более того, любая оптимизация производительности FaaS-приложения автоматически снижает операционные издержки. Например, если выполнение какого-либо действия занимало 1 секунду, а после внесения правок стало занимать 200 мс – это приведет к уменьшению стоимости услуги на 80% без изменений в инфраструктуре.
Заключение
Большинство применений FaaS пока что представляют собой обычные приложения, завернутые в новую оболочку. Команды разработчиков «накидывают» новые решения и смотрят, как они поведут себя в контексте бессерверных платформ. Бессерверный подход маловероятно станет панацеей, и вряд ли заменит все существующие архитектуры, однако можно с уверенностью сказать, что эта область будет развиваться и толкнет вперед сферу разработки программного обеспечения.
P.S. Мы, со своей стороны, также предлагаем несколько интересных материалов из нашего блога о корпоративном IaaS:
