"Любая организация, которая строит системы... неизбежно произведет дизайн, структура которого является копией коммуникационной структуры организации". (с) Мелвин Конвей.

Конечно вместо статей на хабре я бы рекомендовал прочитать книгу от Сэма Ньюмена: "От монолита к микросервисам". Если еще не читали. Есть перевод на русском языке.

Там на эту тему идет более предметный разговор. С аргументами и доводами за и против.

Во-первых никто и не призывает везде лепить микросервисы. Монолиты живы и будут жить во многих проектах. С другой стороны и монолиты клепать везде где не попадя — каменный век.

Сделать микросервисы сложнее. Причем сделать правильно. И тут вопрос даже не в технических способностях. Посмотрите на цитату, с которой я начал этот пост. Вопрос, ни много ни мало, в организации разработки.
Это ничуть ни меньше про менеджмент разработки, чем про архитектуру. И это все более ни менее понимают. Поэтому так престижно говорить на конференции "А у нас микросервисы ...", остальные менеджеры/управленцы "Вау... да вы круты... Смогли организовать процесс!" Конечно, внутрь компании никто лезть не будет. Никто не будет выяснять есть ли там Entity Service в качестве антипаттерна.
Просто пойдет слух, что вот есть организация РосароконсалтТаргетинг у которой микросервисы и они передовые в плане выстраивания процессов.
Отсюда и беруться через пару лет все эти разочарования.

Но в самих микросервисах идея крайне простая и давным давно известная. Нужно сложную систему разбить на части и получить несколько слабо связанных между собой систем. У каждой системы своя команда. Свой деплой. Это известно уже тысячу лет... просто появился buzzword ну и некоторая систематизация практик и паттернов для этого.
И один из главных паттернов — если система не разбивается, то не разбивайте ее. Гемора получите больше выгод. Разве что где-то на конференции скажите "А у нас микросервисы..."