В монолите все связано со всем: “плохие” изменения создают проблемы “хорошим” проектам, тянут на дно всю систему.
В MSA система разделена на относительно изолированные сервисы (если конесно верно разделена)

А -)

"злоба дня" нынче вирус и экономика :)

от нас требуют обеспечения непрерывности процессов,
некогда вашу панику читать, работаем)

Да. Это одна из основных выгод использования MSA в корпоративных ИС

Если монолит сложно чистить то получается ядро Линукс полна всякого рода дряни, а ядро проекта ГНУ (не помню как называется) должно быть стабильнее и динамичнее развиваться так как основано на микросервисах... Но почему тогда активнее развивается монолитное ядро?

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

Если сами и на века то какая разница микро сервисы или монолит?
Я пытаюсь понять, если код так себе то без разницы какой он монолитный или раздроблен на обособленные куски.

И получается архитектура тут не решающий фактор

Эта арх. характеристика называется гибкостью.

В конечном итоге гибкость влияет на ТТМ.

Кроме гибкости MSA позволяет повысить масштабируемость и отказоустойчивость.

Разбиение решения на автономные модули (микросервисы) позволяет повысить все эти важнейшие с  точки зрения бизнеса арх. характеристики.

Всё выше описанное коллегами прежде всего имеет отношение к ТТМ, времени доставки нового функционала, иными словами.

Не так важно какой код внутри кусочков, важно чтобы декомпозиция кусочков была выполнена правильно. Так, чтобы они имели низкую связность. Иначе эти кусочки образуют распределённый монолит.

Решающий, см. сообщение выше

На сколько я понимаю архитектуру Линукс дистрибутивы строятся, по большей части на микросервисах, а само ядро монолитное?

Если внутри кусочка (микросервиса) код с душком, то мы просто переписываем этот кусочек

Выскажу точку зрения, что всё сложнее. И гибкость может достигаться разными факторами и под TTM поднимают сильно разные вещи. Но главное, что в корпоративной среде, в среднем по больнице, всё вообще очень плохо. Можем мне не везет, но когда кто-то приходит с проблемой, то в большинстве случаев он банально не может сказать сколько и каких сервисов у него в этой проблеме запущено, на чем они и как друг с другом взаимодействуют. Какой там код? Главный вопрос: чинить или менять

Да, полностью согласен, в своём докладе об этом говорил. Редко кто может ответить на вопрос, по каким принципам выполнена декомпозиция и за счёт чего обеспечивается низкая связность. Если ответов нет, то скорее всего макароны.

Основной подход к декомпозиции - куда бы попроще прилепить, чтобы побыстрее и поменьше думать.

И это mindset. Есть коллеги, которые в принципе так работают всегда.

Куда бы побыстрее прилепить и поменьше думать - это тоже про TTM, про скорость выкатки. Но такой подход не работает в долгую.

В итоге на шине столько всего налеплено...