TeamLead
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Монолит

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

Достоинства монолитной архитектуры

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

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

Улучшенная производительность.
Если учитывать, что приложения были собраны правильно, то одно и то же приложение при монолитной архитектуре будет работать более производительно, чем при микросервисах. Это, опять же, обеспечивается единым кодом программы и работой из «одного» места.

Недостатки монолитной архитектуры

Большой объем кода.
Если разрабатываемый продукт довольно большой и постоянно масштабируется, то со временем его код разрастается до огромных размеров. Это утяжеляет его понимание и дальнейшее обслуживание. Плюс может наступить момент, когда код будет «перегружен» и потеряет от этого свое качество.

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

Гибкость ограничена.
Из второго пункта следует, что внедрение чего-то нового — это целая история, и очень часто это означает повторное развертывание приложения, так как вносить изменения нужно в весь код. Эта же ситуация касается и исправления багов, добавления обновлений. Обновление = переписанное заново приложение. Поэтому при монолитной архитектуре довольно сложно адаптировать уже работающее приложение под свои нужды, то есть гибкость «хромает».

Зависимость между компонентами.
С одной стороны, это является достоинством, так как увеличивает производительность. Но с другой стороны, если в каком-то компоненте программы будет ошибка, то это замедлит или вообще остановит работу всего приложения, а не одного компонента.

Использование

Такая архитектура идеально подходит для:

  • когда нужно быстро развернуть небольшое приложение;
  • если в команде разработчиков небольшое количество людей (2-5), которые смогут работать совместно, а также смогут вместе поддерживать приложение в дальнейшем;
  • когда создается непроверенный продукт и нужно его быстро создать, чтобы протестировать;
  • когда просто нет опыта работы с микросервисами;
  • если изначально известно, что приложение не будет разрастаться до колоссальных масштабов;
  • если в приоритете разработки программного обеспечения находятся именно скорость его работы и производительность.

Поэтому перед использованием монолитной архитектуры нужно все тщательно взвесить. Иногда продумывают такой ход: запуск приложения осуществляют при использовании монолитной архитектуры, а чуть позже, если оно «зашло» пользователю, дробят приложения на микросервисы для удобного масштабирования, тем самым меняя его архитектуру.

Темы для изучения