Выражение «монолитная архитектура» сразу ассоциируется со словом «монолит». А
монолитом еще с давних пор называют большой единый блок из камня или бетона.
Монолит — это что-то большое и единое, имеющее общую и мощную структуру.
Монолит — это сила и на века.
В программировании «монолитная архитектура» также подразумевает наличие
общей и единой платформы, где сконцентрированы все компоненты одной
программы. Сколько бы не насчитывалось подобных компонентов, но все они
унифицированы и при этом управляются из одного места. В этом и определяется
сила «монолитных» приложений.
Монолитная архитектура
Многие современные стартапы выбирают именно монолитную архитектуру
приложения, потому что она комфортна при работе небольшими группами
разработчиков. При ее использовании все компоненты программы
взаимосвязываются и взаимозаменяются — это помогает развивать программу
автономной и самодостаточной. Монолитная архитектура считается традиционной и
проверенной при разработке приложений, но в то же время, многие разработчики
считают такой подход в реализации приложений старомодным и уже никуда не
годным.
Чтобы понимать, подойдет ли вам такой способ разработки или нет, нужно
рассмотреть достоинства и недостатки монолитной архитектуры.
Достоинства монолитной архитектуры
- Простая разработка и простой запуск программы. Из-за того , что вся
разработка сконцентрирована в одном месте, легче интегрировать
инструменты для облегченной разработки, те же каталоги или библиотеки.
Плюс, при необходимости изменить элементы программы не нужно вносить
изменения по отдельности в разных местах – все делается в одном месте. - Сквозные проблемы практически отсутствуют. Большое количество
приложений имеют зависимость от задач, которые совершаются между
компонентами программы: логи, ограничения скорости, контрольные журналы
и т. д. При монолитной архитектуре эти проблемы практически отсутствуют,
так как все сконцентрировано в одном коде и все работает в одном
приложении. - Улучшенная производительность. Если учитывать, что приложения были
собраны правильно, то одно и то же приложение при монолитной архитектуре будет работать более производительно, чем при микросервисах. Это опять же обеспечивается единым кодом программы и работы из «одного» места.
Недостатки монолитной архитектуры
- Большой объем кода. Если разрабатываемый продукт довольно большой и
постоянно масштабируется, то со временем его код разрастается до огромных
размеров. Это утяжеляет его понимание и дальнейшее обслуживание. Плюс,
может наступить момент, когда код будет «перегружен» и потеряет от этого
свое качество. - Сложно модернизируется. Иногда нужно добавить в приложение какую-то
новую «фишку». При монолитной архитектуре можно столкнуться со
множеством препятствий, чтобы это реализовать. Потому что, в некоторых
случаях, добавить какую-то «фишку» означает переписать полностью
приложение. А это долго и дорого. - Гибкость ограничена. Из второго пункта следует, что внедрение чего-то нового
— это целая история и очень часто это означает повторное развертывание
приложения, так как вносить изменения нужно в весь код. Эта же ситуация
касается и исправления багов и добавления обновлений. Обновление =
переписанное заново приложение. Поэтому при монолитной архитектуре
довольно сложно адаптировать уже работающее приложение под свои нужды,
то есть гибкость «хромает». - Зависимость между компонентами. С одной стороны это является
достоинством, так как увеличивает производительность. Но с другой стороны,
если в каком-то компоненте программы будет ошибка, то это замедлит или
вообще остановит работу всего приложения, а не одного компонента.
Заключение
Монолитная архитектура, хоть и «старая» по своему происхождению, но до сих пор
актуальная и используется многими компаниями. Такая архитектура идеально
подходит для стартапов и разработок:
- когда нужно быстро развернуть небольшое приложение;
- если в команде разработчиков не большое количество людей (2-5), которые смогут работать совместно, а также смогут вместе поддерживать приложение в дальнейшем;
- когда создается непроверенный продукт и нужно его быстро создать, чтобы протестировать;
- когда просто нет опыта работы с микросервисами;
- если изначально известно, что приложение не будет разрастаться до колоссальных масштабов;
- если в приоритете разработки программного обеспечения находится именно скорость его работы и производительность.
В целом, небольшие «монолитные» приложения легко масштабируются до
определенного момента. Можно представить их процесс масштабирования с
клубком ниток. Когда он небольшой, его легко держать в руках и наматывать на него
другую нитку разных цветов и разного состава — все происходит легко и быстро. Но
настает такой момент, когда клубок в руках уже не удержать и тем более не
посчитать сколько в нем нитки и каких она цветов. И чтобы с этим всем как-то
разобраться, придется клубок перематывать и при этом делить его на более мелкие
клубки по цветам нитки.
Возможно вам будет интересно почитать статью “Port 60/64 emulation что это такое?”
Поэтому перед использованием монолитной архитектуры, нужно все тщательно
взвесить. Иногда продумывают такой ход: запуск приложения осуществляют при
использовании монолитной архитектуры, а чуть позже, если оно «зашло»
пользователю, дробят приложения на микро сервисы для удобного
масштабирования, тем самым меняя его архитектуру.
