Комбинируем безсерверные комбинаторы

Безсерверная (serverless) архитектура — весьма парадоксальная на первый взгляд концепция, если судить по названию. Что имеется в виду под «без серверов»?

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

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

Подобные сервисы существуют как минимум лет десять, правда, в основном в специализированных сферах, прежде всего в разработке игр. Самый известный, наверное — это Photon, для скоростного создания многопользовательских игр (на C#, C++, JS, Lua…). Сегодня аналогичные услуги предлагает амазон уже всему мэйнстриму. В частности, был выпущен API Gateway, который позволяет вызывать Lambda через HTTP.

Код выполняется в зависимости от срабатывания триггеров (например, при изменении в базе данных), и денежки берутся за количество триггеров и каждые 0,1 секунды выполнения кода. Система за счёт триггерной концепции полностью асинхронна.

Исполняемый код в serverless архитектуре иногда называют микросервисом, и это правильно, но лишь отчасти. Корректнее всего всё же и считать, и проектировать, каждый «микросервис» как автономную функцию (лямбду). Крайне важно, что сами эти функции не имеют состояния — они stateless!

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

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

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

3. Независимость каждой функции от других, что нередко воспринимается проектировщиками классических монолитных систем как отсутствие «целостности» всей системы. Однако с точки зрения функциональных архитектур эта фишка — мощнейший плюс! «Проигрывая» немного из-за необычности архитектуры и необходимости изменения парадигмы мышления, мы выигрываем на порядки больше за счёт автономности всех модулей системы. На самом деле сложность системы снижается: мы вообще не заботимся об инфраструктуре — её больше нету! Более того, и о масштабировании больше не надо заботиться вообще.
Программисты просто пишут чистый код! А оплата берётся только за реально проработанное кодом время. Когда ваша система в idle, деньги не снимаются.
При этом система крайне устойчива: любые баги в ней изолируются на уровне элементарной лямбды, и не распространяются за её пределы.

См. например этот прикладной цикл по созданию самых современных архитектур, включая и stateless.

Отмечу, что схожие архитектуры сегодня также активно развивают Microsoft и Netflix.

Ну и конечно аналогичное решение предлагает Google — т.н. Cloud Functions. Тут правда есть большое «но»: если Amazon предоставляет возможность кодирования лямбд на Python, Java, C# и JavaScript, что покрывает 99% потребностей мэйнстрима, то Гугль пока ограничивается лишь JavaScript (Node.js).

Но сам подход смотрится очень мощным, поэтому, как говорится, учитесь «экспозить API из элементарных запчастей» — пишите комбинаторы на амазоновской лямбде и комбинируйте их!

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *