Монолит vs микросервисы: какую архитектуру выбрать?

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

В этой статье мы сравниваем обе архитектуры, их преимущества и недостатки, и объясняем, когда подходит каждая.

Что такое монолитная архитектура

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

Что такое микросервисы

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

Ключевые различия

Вот факторы, в которых разница между двумя подходами заметнее всего:

• Сложность: монолит прост; microservices сложны в эксплуатации.
• Масштабирование: монолит масштабируется целиком; microservices — по частям.
• Начальная скорость: монолит позволяет двигаться быстрее на старте.
• Команды: microservices лучше подходят для множества крупных команд.
• Развёртывание: одно против множества согласованных.
• Операционные затраты: ниже в монолите, выше в microservices.

Когда выбирать каждый вариант

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

Скрытая цена микросервисов

Стоит осознавать, что микросервисы переносят сложность из кода в эксплуатацию, и эту цену почти всегда недооценивают. То, что в монолите — простой вызов между функциями, в микросервисах — сетевое взаимодействие, которое может сбоить, иметь задержку и требовать повторов. К этому добавляется необходимость оркестровать развёртывания, мониторить десятки сервисов, управлять распределёнными данными и поддерживать куда более изощрённую инфраструктуру. Для организации без зрелых команд и инструментов эксплуатации эта сложность способна съесть больше времени, чем экономит, вплоть до того, что многие компании, мигрировавшие на микросервисы без нужды, в итоге вернулись к более простому дизайну. Это не недостаток микросервисов, а признак того, что они окупаются лишь тогда, когда проблема их действительно оправдывает.

Модульный монолит: лучшее из двух миров

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

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