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

Ключевые слова: микросервис, монолит, аналитическая иерархия для взвешенных решений, критерии оценки, предварительная модель.

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

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

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

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

Технические ограничения, к которым можно отнести навыки команды и поддержание legacy-системы[1], являются не менее значимым фактором, который влияет на успех внедрения новой технологии. В последнее время довольно распространенной практикой считается поддержание работоспособности устаревших систем, так как они остаются частью инфраструктуры компании. Большинство ключевых бизнес-функций завязаны на данных, интегрированных в монолитные системы, а их модернизация и распределение на микросервисы потребует значительных затрат. Бесконечная поддержка legacy-систем нельзя назвать оптимальным решением проблемы, так как постоянное развитие технологий и растущие объемы данных требуют адаптации, что со временем становится сложнее. Помимо этого, современные меры безопасности не поддерживаются legacy-системами, что повышает риск уязвимости для кибератак.

Экономические факторы перехода с монолитной архитектуры на микросервисную имеют значительный вес при принятии решения. Несмотря на технические преимущества микросервисной архитектуры, ее внедрение часто блокируется из-за неочевидности экономической целесообразности. При переходе на микросервисную архитектуру компании сталкиваются с дилеммой: необходимость высоких начальных инвестиций (CAPEX) противостоит ожидаемой долгосрочной выгоде (снижение TCO, гибкость масштабирования). Сложность заключается в оценке временного горизонта окупаемости инвестиций. Для монолитной архитектуры эта дилемма менее выражена (низкие стартовые затраты, но ограниченная гибкость в долгосрочной перспективе)

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

Для решения обозначенной проблемы предлагается разработка многофакторной модели определения степени зрелости компании и необходимости перехода на микросервисную архитектуру. В качестве метода решения предлагается использование аналитической иерархии для взвешенных решений. Этот метод был разработан в начале 1970-х годов математиком Томасом Саати и называется Analytic hierarchy process (AHP) [1]. В основу метода заложена линейная свертка, но оценки альтернатив и веса критериев получают специальным образом.

В качестве критериев оценки текущей модели определим показатели трех групп:

— экономические: показатели расходов бизнеса CAPEX/OPEX, стоимость владения продуктом TCO, рентабельность инвестиций ROI;

— технические: масштабируемость, отказоустойчивость, производительность;

— организационные: команда, скорость разработки, готовность к DevOps;

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

Пример вводных данных

Средняя стартап-компания с растущей клиентской базой. Текущая монолитная система испытывает проблемы с масштабируемостью, но имеет стабильную legacy-инфраструктуру. Необходимо определить готовность компании к смене архитектуры (зрелость).

Представим расчет модели аналитической иерархии для взвешенных решений следующим образом.

Уровень 0. Цель — определить архитектуру (монолит или микросервис) для корпоративной системы по критериям.

Уровень 1. Критерии.

Уровень 2. Экономические.

Показатели расходов бизнеса CAPEX/OPEX в текущей ситуации для компании необходимо минимизировать. Монолит требует в пять раз меньше первоначальных инвестиций, чем микросервисы в краткосрочной перспективе (1–2 года). Хотя микросервисная архитектура обеспечивает меньшую совокупную стоимость владения (TCO) в долгосрочной перспективе (3–5 лет), ее внедрение требует значительных первоначальных инвестиций. Рентабельность инвестиций (ROI) в микросервисную архитектуру оказывается выше благодаря скорости разработки, гибкости обновлений и снижению рисков.

Таблица 1

Анализ по экономическим критериям

Результат расчета по экономическим критериям: монолитная архитектура более выгодна, чем микросервисная (77 % против 23 %).

Уровень 2. Технические.

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

— отсутствию накладных расходов на межсервисные вызовы;

— локальности данных (все в одном процессе);

— минимальной задержке при внутренних взаимодействиях.

Таблица 2

Анализ по техническим критериям

Результат расчета по техническим критериям: микросервисная архитектура более выгодна, чем монолитная (60 % против 40 %).

Уровень 2. Организационные.

Уровень профессионализма и универсальности команды при монолитной архитектуре высок, что делает ее более готовой к обучению. В команде, которая уже достигла высокой эффективности работы с legacy-монолитом (глубокое понимание архитектуры, отлаженные процессы), скорость разработки может быть выше, чем при микросервисном подходе, в соотношении 5:1. Наличие CI/CD-практик в команде существенно упрощает переход на микросервисную архитектуру.

Таблица 3

Анализ по организационным критериям

Результат расчета по организационным критериям: монолитная архитектура более выгодна, чем микросервисная (61 % против 39 %).

Таблица 4

Сводный анализ по критериям

В таблице 4 представлен результат расчета на основе аналитической иерархии для взвешенных решений.

Таким образом, несмотря на то что монолитная архитектура получила перевес (59 % против 41 %), разница с микросервисной архитектурой крайне незначительна. Это говорит о том, что текущие условия компании не требуют срочного и полного перехода на микросервисы, но уже сейчас необходимо начинать подготовку к постепенной трансформации.

В качестве первых шагов миграции можно попробовать постепенно внедрять микросервисные практики, используя гибридный подход на основе паттернов, приступить к подготовке команды к DevOps-культуре и облачным технологиям, создать пилотные микросервисы для нефункциональных компонентов (логирование и аутентификация). Однако для снижения рисков нужно сохранить legacy-ядро в монолите до стабилизации новых сервисов.

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

Литература:

1. Саати Т. Принятие решений. Метод анализа иерархий / пер. с английского Р. Г. Вачнадзе. — Москва : Радио и связь, 1993. — 278 с.

2. Шитько А. М. Проектирование микросервисной архитектуры программного обеспечения // Труды БГТУ. Серия 3: Физико-математические науки и информатика. 2017. № 9 (200). URL: https://cyberleninka.ru/article/n/proektirovanie-mikroservisnoy-arhitektury-programmnogo-obespecheniya (дата обращения: 15.04.2025).

3. Фаулер М. Архитектура корпоративных программных приложений — Текст: электронный. — URL: http://www.ooart.ru/uploads/book/arhitektura_korporativnyh_programmnyh_prilozhenij_fauler_m.pdf (дата обращения: 26.04.2025).

[1] Legacy-системы (от англ. legacy — «наследие») — это устаревшие программные системы, приложения или код, которые продолжают использоваться.