# Монолит {% hint style="info" %} **Монолитная архитектура** – это традиционный способ организации приложений, в котором все компоненты продукта находятся внутри одной монолитной кодовой базы и управляются как единое целое. {% endhint %}

Схематичное изображение монолитного приложения

## Преимущества монолитной архитектуры * **Простота разработки и тестирования** Монолитная архитектура проста в разработке, развертывании и обслуживании. Поскольку все компоненты являются частью единой кодовой базы, процесс разработки упрощается, и приложение можно развернуть как единое целое. Поскольку все приложение интегрировано, может быть проще выполнить сквозное тестирование для полной проверки функциональности системы. * **Меньшие накладные расходы** Запуск и обслуживание таких приложений часто дешевле, чем микросервисов, так как не требуется управление большим числом независимых сервисов. * **Производительность** Внутри монолита обмен данными между компонентами может быть более эффективным, чем в микросервисной архитектуре. Это связано с тем, что данные передаются в пределах одного процесса. ## Недостатки монолитной архитектуры * **Масштабируемость** Чаще всего такие приложения масштабируются вертикально, что означает увеличение ресурсов на одном сервере. Это может быть ограничивающим фактором при необходимости горизонтального масштабирования, особенно в случае резкого роста нагрузки. * **Сложность поддержки и обновлений (Низкий time-to-market новых релизов)** При внесении каких-либо изменений монолитному приложению необходимо пересобирать и перезапускать всю систему, что может вызвать простои и сложности в управлении обновлениями. * **Зависимость от технологий** В монолитной архитектуре труднее всего внедрять новые технологии, так как все части приложения связаны между собой, и изменение одной части может потребовать изменения всей системы. * **Сложность отладки и тестирования** Поиск и устранение ошибок может быть сложным из-за тесной интеграции всех компонентов в одной кодовой базе. * **Повышенный риск сбоя** По мере увеличения сложности монолитного приложения возрастает и риск сбоя. Единственная ошибка или проблема в одной части системы может иметь каскадные последствия, потенциально приводящие к общесистемному сбою. ## **Ситуации, когда лучше подойдет монолитное приложение** 1. У вас маленькое и относительно простое приложение, которое разрабатывается одной командой. Вообще, любое приложение, которое развивается итерационно с небольшого набора функций, на мой взгляд, должно начинаться как монолитное, а отдельные микросервисы из него выделяться по мере появления необходимости. 2. Все функции системы взаимодействуют с единой сильно связанной моделью данных. Разработчики не смогут независимо друг от друга менять модель данных (так как это повиляет на всех), а значит пресловутой "автономности команд" не добиться и мы получим в ряде случаев монолит, который деплоится двумя кусками; как говорится, сделаем из одной проблемы две. 3. Обмен данными между функциональными модулями имеет настолько высокие требования к скорости, что передача их по сети будет слишком медленной; в этом случае они (данные) должны быть расположены в памяти одного приложения. Источники: * * Тоже самое, но другими словами: * *