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