28 lines
3.0 KiB
Markdown
28 lines
3.0 KiB
Markdown
---
|
||
aliases:
|
||
- монолитном аду
|
||
tags:
|
||
- зрелость/🌱
|
||
date:
|
||
- - 2024-04-04
|
||
zero-link:
|
||
- "[[00 Архитектура ПО]]"
|
||
parents:
|
||
linked:
|
||
- "[[Монолитная архитектура]]"
|
||
---
|
||
Монолитный ад появляется, когда команда монолита и кодовая база разрастается. Приложение становится настолько большим, что одному разработчику его невозможно понять.
|
||
|
||
|
||
|
||
Усугубляет проблему то, что сложность, и так чрезмерная, обычно повышается экспоненциально. Если кодовая база плохо поддается пониманию, разработчик не сможет внести изменения подходящим образом. Каждое изменение усложняет код и делает его еще менее понятным. В итоге вы получаете [Большой комок грязи](Большой%20комок%20грязи.md).
|
||
|
||
**Медленная разработка.** Сборка кода занимает много времени. Из-за размеров приложения оно долго запускается. В итоге затягивается цикл написания - сборки - запуска - тестирования.
|
||
|
||
**Медленные и сложные релизы.** Над проектом работает множество команд, а кодовая база у них одна. В итоге если даже монолит разбит на отдельные модули, ваша команда не сможет выпустить релиз, пока другие команды не закончат свои работы.
|
||
|
||
**Трудности с масштабированием.** Разные программные модули конфликтуют/соревнуются за ресурсы сервера. Например, модуль обработки изображений сильно нагружает ЦПУ, и это может сказаться на стабильности работы других модулей.
|
||
|
||
**Сложно добиться надежности и стабильности работы.** Утечка памяти в одном модуле приводит к отказу всего решения.
|
||
|
||
**Постепенное устаревание стека технологий.** Сложно переходить на новые фреймворки и подходы в монолитном приложении, посколько это чаще всего невозможно сделать точечно. Нельзя сказать, что модуль оплаты мы разрабатываем на спринге, а модуль пользователей на кваркусе. |