3.0 KiB
| aliases | tags | date | zero-link | parents | linked | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
Монолитный ад появляется, когда команда монолита и кодовая база разрастается. Приложение становится настолько большим, что одному разработчику его невозможно понять.
Усугубляет проблему то, что сложность, и так чрезмерная, обычно повышается экспоненциально. Если кодовая база плохо поддается пониманию, разработчик не сможет внести изменения подходящим образом. Каждое изменение усложняет код и делает его еще менее понятным. В итоге вы получаете Большой комок грязи.
Медленная разработка. Сборка кода занимает много времени. Из-за размеров приложения оно долго запускается. В итоге затягивается цикл написания - сборки - запуска - тестирования.
Медленные и сложные релизы. Над проектом работает множество команд, а кодовая база у них одна. В итоге если даже монолит разбит на отдельные модули, ваша команда не сможет выпустить релиз, пока другие команды не закончат свои работы.
Трудности с масштабированием. Разные программные модули конфликтуют/соревнуются за ресурсы сервера. Например, модуль обработки изображений сильно нагружает ЦПУ, и это может сказаться на стабильности работы других модулей.
Сложно добиться надежности и стабильности работы. Утечка памяти в одном модуле приводит к отказу всего решения.
Постепенное устаревание стека технологий. Сложно переходить на новые фреймворки и подходы в монолитном приложении, посколько это чаще всего невозможно сделать точечно. Нельзя сказать, что модуль оплаты мы разрабатываем на спринге, а модуль пользователей на кваркусе.