для больших компаний важно, чтобы команды могли независимо друг от друга (насколько возможно) пилить и деплоить свои фичи. это проще с микросервисами, где ты контролируешь весь процесс от разработки до деплоя, чем с монолитом. а дальше закон комвэя говорит, что микросервисы в таком случае будут не по уму делать, а по командам (и еще более гранулированно)
ну да, встречал такое, между нами была лишь шина и два этажа лестницы, там даже разные языки по командам были, единственное, я бы не называл бы это микросервисами точно) скорее 4 монолита, у которых есть по паре микросервисов-помощников)
> фича А обновилась - деплоем туда, где у нас фича А включена
По фэншую у тебя должны фичи приходить вместе с запросом (или с клиента, или обогащаться) и код решает, по какому пути бежать. Деплой в зависимости от фичефлагов - это путь в ад эксплуатации.
Да, я и намекаю на этот путь в ад, когда у тебя один сервис, который имплементирует кучу функций и ты вынужден из-за обновлений в одной функции обновлять все сотни экземпляров сервиса, работающих в разных ролях, что чаще всего невозможно.
50 машин это еще ничего. Особенно если у тебя не появилось требований вида "нельзя рвать коннект, потому что юзеру будет больно", допустим. И все бы ничего, если сессия короткая, а если сессия 3-4 часа?