Монолиты слишком раскритикованы

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

Если вы новичок в бекенд-разработке, напомню: монолит – это серверная система, работающая как одно целое. То есть, это одна-единственная программа, которая запускается, обслуживает некоторое количество сетевых запросов и после этого завершается. Альтернативы монолиту – это, в частности, сервис-ориентированные архитектуры (SOA), микросервисы, бессерверные функции – пожалуй, этим список не исчерпывается. Каждому из этих подходов есть свое время и место, поэтому можно только приветствовать любые обоснованные решения, при которых новая система создается в соответствии с одним или другим из этих паттернов. Я считаю, что значительное количество веб-приложений и сервисов вполне можно обслужить при помощи монолита… немного его усовершенствовав.

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

Паттерны, альтернативные монолиту, очень разумно обоснованы. Распределяя работу между несколькими разными сущностями, можно добиться, чтобы целостная система выполняла больше работы. Но хорошо известно, что при таком подходе сложность системы возрастает, на ее поддержку требуется больше усилий, что зачастую выливается в дополнительные человеко-часы и стоит дороже. Единственное исключение из этого правила, которое я вижу – это бессерверные функции, которые действительно многое упрощают. Но у них есть и свои недостатки – такие функции сложнее тестировать, они зависят от вендора, а для работы с ними может понадобиться инструментарий, которого не найти в продаже. Если все сделать правильно, то эти дополнительные усилия оправдаются и позволят создать очень удобную систему, которая блещет достоинствами. Классический пример – Netflix, они очень хорошо обустроились.

Находим компромиссный вариант

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

Знакомьтесь: паттерн проектирования SUFA

Прежде, чем объяснить по существу, что же такое SUFA, упомяну, что это не абсолютно новая концепция. Уже давно существуют такие вещи как паттерн «актор», парадигма «неомонолит» и другие, в рамках которых были постулированы схожие идеи, а SUFA – это просто одна из возможностей, позволяющих скомбинировать несколько концепций в простой и понятный паттерн проектирования. Итак, что же это?
S(Простые), U(Унифицированные), F(функциональные) A(Приложения).
Разберем каждый компонент:

Простые (Simple)

Система, спроектированная по паттерну SUFA может работать с применением простейших сценариев развертывания. Уже давно известны группы автомасштабирования, а с появлением систем оркестрации контейнеров создавать такие группы стало даже проще. Для работы системы SUFA достаточно всего одной группы автомасштабирования (ASG), или ее можно расширить при помощи сетки сервисов, которая позволит создать функционально отличающиеся группы (это тема для отдельного поста).

Унифицированные (Unified)

Система SUFA использует не множественные сервисы, каждый из которых существует как самостоятельная развертываемая единица, а представляет собой единый развертываемый файл. Это может быть образ Docker, или AMI, или какой-нибудь другой артефакт, но, в любом случае, нам требуется построить всего одну штуку. Строить ее нужно методом непрерывной интеграции и доставки (CI/CD) в рамках непрерывной или размеченной каденции релизов, а предоставлять через реестр артефактов – например, реестр Docker или корзину S3.

На основе функций (Function-based)

Пожалуй, в любом стандартном монолите есть уровень обработчиков, отвечающий за прием запросов API и выполнение вызовов, адресованных бизнес-логике (которая и обрабатывает эти запросы) или хранилищу данных. Напротив, системы SUFA при обработке запросов сцепляют серии функций, каждая из которых совершенно независима от других и даже не знает об их существовании. Функции должны ожидать определенный ввод, выполнять некоторые операции и производить вывод, который будет по эстафетному принципу передаваться другим функциям в цепочке. Функции должны без труда тестироваться и переиспользоваться в разных сценариях (например, при различных запросах к API). Также системы SUFA должны проектироваться с расчетом на потребление и порождение событийно-основанного трафика, так как события будут в них основным коммуникационным средством.

Приложения (Applications)

На первый взгляд, этот пункт очевиден, но в рамках SUFA «приложение» понимается в очень специфическом смысле. Система SUFA должна обслуживать одно-единственное приложение, то есть, охватывать все возможности, предусматриваемые в полностью сформированном продукте. Здесь есть некоторое пространство для интерпретаций (например, должно ли в компании быть одно SUFA-приложение для всего бизнеса, даже если она производит продукт для разных областей), но суть в том, чтобы не умножать сущности, обслуживающие одно и то же приложение. Если функционал необходимо разделить между несколькими приложениями, то те функции, что входят в состав SUFA-системы, должны легко поддаваться переиспользованию и компоновке для достижения разных целей.

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

SUFA в большом масштабе

Критически важный фактор, обеспечивающий масштабирование SUFA-системы, заключается в том, что она состоит из независимых функций. SUFA-системы должны опираться на базовый каркас, который отвечает за оркестрацию выполнения всех функций с расчетом на их эффективное масштабирование. Пользуясь пускателем функций или планировщиком заданий для работы с нужными функциями, SUFA-фреймворк абстрагирует конкретные детали выполнения функций; автор кода должен лишь указать, какие функции выполнять и в каком порядке.
Дополнительная масштабируемость обеспечивается при помощи групп возможностей и создания сетей данных (meshing).

Suborbital Atmo

Паттерн SUFA был спроектирован в расчете на работу с Atmo – это универсальный фреймворк, на основе которого особенно удобно строить SUFA-системы. Atmo использует файл под названием «Directive», в котором описываются все аспекты вашего приложения, в том числе, как сцеплять функции для обработки запросов. Функции, которые смогут работать поверх Atmo, могут быть написаны на разных языках. Фреймворк использует модули WebAssembly как вычислительные единицы. Atmo автоматически масштабируется горизонтально, чтобы обрабатывать нагрузку, поступающую в ваше приложение, содержит всевозможные инструменты и реализует наилучшие практики, обеспечивая высокий уровень производительности и безопасности и не требуя от вас писать ни строчки шаблонного кода.
Потрясающие возможности WebAssembly и продуманный дизайн SUFA можно попробовать на свободной платформе Suborbital Development Platform, чтобы по-новому подойти к созданию веб-приложений. На волне новых технологий и практик, таких, как JAMStack и пограничные вычисления, мы можем взять лучшее от новых и старых парадигм, чтобы делать невероятные вещи.