Подход был давно описан до микросервисов, только почему-то о нём никто ничего не знает... Как и о микросервисах кроме названия

Ну и те, кто делали микросервисные архитектуры в 2016-2017 - отловили кучу граблей с сопутствующий вопросом "а нахрен мы в это влезли?" ) От рекламы микросервисного подхода до готовности в prod прошло 4-5 лет. Появились инструменты трейсинга, жизнь на общей шине перестала быть такой болью и тд.

https://habr.com/ru/post/499174/
Эта статья тоже странная.

"И вот тут мы можем наконец-то перейти к определяющей роли микросервисов — это подход, упрощающий управление конфигурацией продукта. Детальнее говоря, функция каждого микросервиса описывает именно бизнес-функцию внутри продукта согласно доменной модели — а это уже вещи, которые живут не в короткоживущей версии, а в долгоживущей бизнес-возможности."

Как бы это и есть SOA - бить сервисы по бизнес-доменам. В Juno 110+ микросервисов, микросервис на фичу. Вот это микросервисная архитектура )

А как можно вообще софт писать вне бизнеса? Feature - это по сути эмержентная функция - она складывается из совокупности функций-микросервисов

110 - как-то мало.

Тот же Ричардсон пишет что отличие сервиса от микросервиса в том, что сервис по факту является монолитом. Также там встречается глобальная модель данных, шаринг на уровне БД, умные каналы и тп

Вопрос декомпозиции. Но тут микросервисы имхо подталкивают на парадигму "а почему не ещё один сервис ведь у нас микросервисная архитектура".  Где-то на 4-м десятке микросервисов начинают писать свой framework для типичного микросервиса.

Monzo runs more than 1600 core-banking microservices on AWS. Слушал недавно подкаст. Ну и там много вопросов поднимали. Как например деплоить, если только один миросервис поменялся. А что, если какие-то зависимости и т.п.

И один из аспектов у них - моно репозиторий + Go со статической типизацией. Т.е. всякие зависимости (много из того, что может поломаться) и прочее на этапе компиляции находится.

Ой, да.... еще монорепы стоит вспомнить, что б на одной ревизии все сервисы собирались.

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

https://www.youtube.com/watch?v=g9cgppj0gKQ&t    хороший доклад ...

Отдает гуглом и фейсбуком

Да, или добавить еще один метод в существующий сервис, или новый сервис... вот тут делема. С микросервисами часто второе, в soa думают сначала о методе в существующие.

да уже не одна компания села на go-micro - и пишут по факту распределенный монолит

да. так и получается.

просто переход на следующий уровень проблем 😄

Нет тут дилеммы - есть принцип целесообразности. Если вынесли метод в отдельный сервис и менять потом приходится постоянно два - зря вынесли)

и, как тут уже писали, перенос ответственности на других людей 😵