Затем, что ФИО это уже достаточно сложно. Со странами не особо проще. Инет-адреса ещё сложнее. Если всё запихнуть в 1 сервис — получится не «микро», а «жирно».

Это говорит о неправильном выделении сервисов.

Наоборот, о правильном. Имя-фамилие отдельно, страна отдельно, ип-адрес отдельно. В серьёзной системе, с этими вещами можно понаделать столько разных извращений — что одному «микро»-сервису такого будет многовато.

Все на уровне ощущений, пожалуй

Теоретически, микросервис — это специализированный сервис с единственной функцией. Или, уж во всяком случае, работающий лишь в одном предметном домене.
А если больше — начинаются «жирные» сервисы, а-ля монолиты.

В итоге получаются неповоротливые монстры с невнятными классами, у которых — невнятные обязанности и невнятные тесты.

А в это время, такая же (по квалификации) команда в микросервисах... :)

Если написанный такой командой монолит, хоть как-то будет шевелиться и будут возможности отладки доведение напильником — то написанные микросервисы просто не дружно лягут и проект на этом закончится.

Скорее, как Лисп.

пойди почитай для чего gRPC в первую очередь создан.

Ты как сегодня родился. :) Для чего обычно протоколы удалённого вызова процедур создаются? Для удалённого вызова процедур.

Или гугл чегой-то другого этим RPC хотел сказать?

или есть кор а есть все что над ним надстаивается, и все это живет в отдельных проектах и просто подключается к кору и к друг другу с помощью универсальных протоколов взаимодействия ?

Тем не менее, это «монолит» — т.к. 1) система централизована 2) компоненты живут на одной машине (часто даже в одном процессе).

А то, что в разных проектах — то особенности реализации. К рантайму отношения не имеющие.

Да уж, видно не видел ты никогда большие системы...
(адреса и национальности бессмысленны без людей, все что ты тут описал только лишь показывает что ты не понимаешь концепта микросервисов)

бла-бла-бла...

Юрлица тоже имеют адреса и национальности. :)
Так что там в данных клиента, у микросервиса должно быть? Генеалогическое дерево!

Я тебя спросил, как работать с монолитом, над которым работает 100 человек ОДНОВРЕМЕННО. А тысяча?

Ну как работают 1000 чел, над теми же операционками? Так и работают — закатывают рукава и пашут. А не картинки из микросервисов рисуют.

30 лет уже делают нехилые монолиты — но находится хипстер, рассказывающий «так это же не монолит, а операционка» или «это же не монолит, а приложение», итп...

Google с его gRPC вообще подавился от смеха

Удалённый вызов процедур — это очень давние технологии из мира полноценных сервисов-монолитов, а отнюдь не изобретение гугла. Хипстеры тебя разыграли. :)

Это говорит о неправильном выделении сервисов.

Сервисов — неправильно, т.к. сервисы многофункциональны и монолитны.

Но тут обсуждают не сервисы, а микросервисную хипстерщину.

которым нужны данные о клиентах

Данные о клиентах — это, скажем, ФИО, национальность, год рождения... Собственно, даже национальность — это уже отдельный домен (страны, в т.ч. бывшие). Адреса тоже (местоположения).

Но если пихать в «данные клиента» всё — тогда получится не микросервис, а нормальный такой жирный многофункциональный сервис. Монолит.

Зараз на постійну вакансію (а не постдок на 3 роки) черга бажаючих довша за чергу бабульок в собес при совку.

Эти 3 года можно неограниченно продлевать на очередные 3 года (если руководитель удовлетворён работой). Но да, в таком виде приятного мало. Да и «охренителен» заработок, порядка 2,5к/мес «нетто».

Где за 10к — там уже тайтлы пофиг. Играют совсем иные факторы...

Шаренный код не выстраивает естественных границ

Это смотря как кодировать. Если на проекте шарятся исключительно интерфейсы, правильно пользуется инъектирование зависимостей — все классы вполне могут быть непубличны (т.е. недоступны вне сборки с этим классом). Это оговаривается, легко проверяется, за публичные классы бъётся по рукам.

Более того, в условиях монолита нет никаких проблем с дроблением класса до тех пор, пока он не станет выполнять 1 функцию и т.о. станет (выражаясь хипстерской терминологией) «микроклассом» — особых накладных расходов в связи с этим не возникает.
В случае проблем, нет проблем с отладкой, логгингом, итп.

В случае же «микросервисов», выбор между декомпозицией на несколько жирных сервисов (которые, собственно, сами являются немаленькими монолитами) — либо, если дробить начинают на реальные микросервисы, наступает эпик-фейл и летальный исход всего проекта.

Вот например: www.faod.dk

Это не профсоюз, а «объединение». Т.е. цех. С профсоюзом мало общего, рамки зарплат «сверху» не регламентируют.

профсоюза ученых, инженеров, управленцев и других специалистов: www.prospect.org.uk

Наличие профсоюза, желающего заполучить к себе управленцев — не означает, что управленцы там есть. :) Повторюсь ещё раз: как правило в западных компаниях, достаточно управлять десятком чел — чтобы уже не вмещаться в профсоюзные зарплатные рамки. Ни о каком «топ-менеджменте» речь вообще не идёт.

каждая ступенька в тайтле увеличивает целевой показатель для перфоманс-бейзед бонуса в полтора раза

Ок, с 3к до 4,5к. Это успех — жизнь удалась!

в конктретно примере выше я вижу только один сервис

Да, один «жирный» сервис. Но где же тогда микросервисы? :)

так он же за гуглы с фейсбуками говорит. А не за легаси в банках

Про гуглы с фейсбуками начал писать ты, назвав их некими «топ-компаниями». Но я понял твой посыл: аж 2 компании в мире пользуют микросервисы — значит, очень полезная вещь. Непременно учить!

С другой стороны, а где ты у них увидел микросервисы? Фейсбук (платформа) — монолит. Андроид — монолит. Всякие мэпсы/эрзы — монолит. Хром — тоже монолит. У мелкомягких немеренно открытого кода — микросервисов среди него нет. В закрытом коде (винда, sql-сервер, прочий офис) тоже сплошь монолиты. Где они, таинственные и столь популярные в «топ-конторах» микросервисы? :)

А что касается сложности разработки монолитов — так индустрия последние 30 лет занимается тем, что производит монолиты размером порядка несколько сот тысяч человеко-дней. Но таких решений на микросервисах нет. Т.к. всё, что больше 10к строк распределённого по микросервисам кода кода — превращается в тормознутое и выжирающее всю доступную память говно, неприспособленное для какой-либо отладки.

Собственно, я даже пойду далее и напишу, что если у чела в резюме хипстерщина типа функциональщины и прочих микросервисов — на проект не брать. Т.к. чел 1) хипстер, работающий не за деньги, а для развлечения/удовольствия 2) напихает для развлечения/удовольствия в проект хипстерищны 3) будет заниматься тем, что нравится, а не тем, что требудется 4) в один прекрасный момент покинет проект, т.к. «надоело» или «не дают развиваться».
А его хипстерщину потом — попробуй разгреби.

там улетали за сотку, как с гордостью было много раз сказано не одним коллегой на очередном билдинге

Если они, с з/п более сотки понаделали херни в монолите — представляешь, что бы у них были за микросервисы?