Kachalovmad_nazgulА вот с микросервисной архитектурой не совсем так..
- неправильная разбивка на сервисы (несколько сервисов в одной транзакции), слишком толстый "микро" сервис и т п. Эти ошибки загубят идею на корню. Все будут плеваться и говорить что микросервисы это г-но. Чем кривые микросервисы лучше кривого монолита я не понимаю. Вероятно речь идет о какой то мутной психологии - раз я нашел "серебрянную пулю", все что я с ее помощью делаю будет хорошим. Ну-ну.

Я просто исхожу из самого плохого случая.
Плохо спроектированный монолит можно поддерживать долго.
Его с горем пополам можно как-то изменять и он будет долее-менее работать.
Плохо спроектированная микросервисная архитектура довольно быстро загнется.

Вы считаете, что это плохо.

По мне наоборот.
Чем быстрее загнется плохо спроектированное приложение, тем лучше.
Легче статехолдерам объяснить, что все надо менять. :-)

Андрей ПанфиловУ вас представление об IT в крупном бизнесе несколько превратное, каким образом и в каком направлении развивать IT определяет ДИТ, и основным критерием при принятии решения являются референсы на уже существующие системы (именно это, к приему, является основной причиной засилья в банках ПО и железа от IBM), т.е. в первом приближении ДИТ вообще плевать что там думает архитектор, которого взяли вчера, а завтра уволят - проще у своего знакомого узнать что да как. Для российской действительности это выглядит так, что в крупном энтерпрайзе никто на микросервисы переходить не будет ровно до тех пор, пока условный сбер не объявит всем что микросервисы - это круто и всем нужно туда идти, а у сбера вместо побед на поле IT сплошные обсеры, причем айтишные бюджеты там вполне себе крупные в сравнении с остальными по России.

Я говорил со стороны разработчика, который "вариться" в "кровавом Ынтырпрайзе".
Повидал не одну "унаследованную" систему.
Все они работают. Но чтобы там что-то изменить...

Во первых ни в одной из систем не было актуальной документации.
Во вторых никаких тестов, в принципе. Тестируют мануально пользователи.
В третьих сборка проект и деплой - это танцы с бубном.

При этом "внешне" проблем нет.
Приложения работают и выполняют свою работу.
Но задачи типа "добавить тут кнопку" выливаются в пару недель поиска как добавить кнопку, при этом чтобы ничего не поломать походу.

В этом плане микросеврисная архитектура мне нравиться больше.
Т.к. сам микросервис не большой. И изменения там боле-менее понятны.
А если он еще тестами обложен, то вообще замечательно.

Но спроектировать микросервисную архитектуру сложнее.

И плохо спроектированная микросервисная архитектура более хрупкая, чем монолит.

Андрей ПанфиловТо что вы описываете никакого отношения к монолиту не имеет, а имеет прямое отношение к размеру бюджета IT: есть деньги - пишем тесты, нет денег - не пишем, то же самое с документацией, развитием архитектуры и пр.

Имеет. Почему, сказал выше. Не смотря на все проблемы проекта, приложение работает и работает приемлемо для заказчика.
Если бы точно так же развивалась микросервисная архитектура, то она бы загнулась через пол года - год.

KachalovЯ считаю что плохо спроектированное или неправильно реализованное вне зависимости от изначальной архитектуры (монолит или микросервисы) будет работать плохо и создавать проблемы в дальнейшем.

Согласен, но с оговоркой.
Монолит, будет создавать в дальнейшем проблемы в основном разработчику.
И работать будет не так сильно плохо, чтобы стейтхолдер задумался о необходимости рефакторинга.