Atum1Нужно хорошо подумать прежде чем уйти от монолита !
Монолит это идеальная мечта многих организаций и разработчиков .

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

Вот коллеги- реально высоконагруженная система, работающая на hezner'овских серверах. У них железки хорошо, если не на помойке подобранные, стоят соответственно. В даун может уйти сервер, может сегмент сети.
Микросерверная архитектура позволяет при этом всего лишь притормаживать, а не рушиться. Если не пик нагрузки- то заказчики вообще ничего не замечают.
Кроме того, любая часть общего приложения легко обновляется. Критичные- дублирурются. Всё понятно и просто.

Т.е. микросервисы хорошо подходят к реальному миру, когда клиенты по всему миру (надо ставить сервера поближе к ним), сервера падают, обновления нужны часто и т.п.

А монолит- это примерно как водопадный метод разработки. Хорошо, если сделал, продал и забыл. В реальном мире обслуживание этого слишком дорого. Поэтому те, кто продаёт услугу- переходят на микросервисы.

Petro123Alexey TominПоэтому те, кто продаёт услугу- переходят на микросервисы.
вероятно это как раз продажник\маркетологи и т.д.
Архитектор ведь всегда стремился к монолиту снаружи с микросервисами внутри (ООП).

Это плохие архитекторы. Тот же, который любит логику в SQL.

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

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

Да, у микросервисов другие проблемы. Например если мы хотим добавить функциональность в другой микросервис- то нам надо править код там, потом ждать деплоя чтобы нормально использовать. Хорошо, что это не более 2х недель (спринт).