у тебя не получится так что без сетевого взаимодействия вся система работает
а знач привет все проблемы мс

и оркестрация тебе так же нужна будет

и ваще все все, только образ 1 будет, единственное отличие от канона)

и теряешь возможность, которую я все еще считаю самой важной, деплоить отдельные фичи в разнобой

хотя с гитхаб флоу наверное и в разнобой можно:)

но риски все равно больше с одним мастером

это ведь вопрос выстроеного релиза, а не архитектуры

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

например вынести все что связано с оплатой картами и pci dss мутить

вопрос можешь или нет с монолитом так в принципе

рано или поздно придётся создать второй репо, и тогда навыки деплоя мультирепо пригодятся. например, pci dss compliant приложение требует аудита всего скоупа репозитория, а вы захотите уменьшить скоуп как можно сильнее

Ну минуточку. Система и так без сетевого взаимодействия не работает. Над ней есть лоад-балансер-ssl-терминатор, под ней - базы, стораджи, кэши и очереди. Мы же всё равно не кодируем видео синхронно с его загрузкой, мы точно так же ставим в очередь задачу, которая падает в другую часть монолита. Просто теперь экземпляр этой другой части находится на другом хосте (в другом поде).

Тут есть кстати еще одна неочевидная проблема - релизы.
Если у тебя по настоящему жирный монолит с десятками функций, которые включаются через фича-флаги, то ты почти наверняка не будешь обновлять прям все экземпляры своего приложения на каждый чих, а у тебя их могут работать сотни и тысячи. Рано или поздно ты пойдешь деплоить асинхронно, типа "фича А обновилась - деплоем туда, где у нас фича А включена", что приведет к рассинхрону и проблемам с пониманием что где в каком состоянии и "а доехал ли патч Х для фичи Б, которая нужна для фичи А, которая повявилась в релизе 2.14.123, если фича Б работает на версии 2.14.120, а Б - на 2.14.125, при том, что мы точно делали патч раньше, чем он реально был нужен".

А почему про раздельный деплой - я знаю системы, которые раскатываются неделями для полного апдейта из-за всяких перебалансировок, длинных процессов и прочего SLA. И к такому можно придти достаточно незаметно. И полный апдейт на каждый чих тебе точно не захочется.

слышали, не удивились :(

я с тобой согласен, но напиши, пожалуйста развернутый ответ

ну там ниже и я и другие много написали)

давай с этого начинать тогда, а лол в конце

человек новый, не пуганный еще

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