Нормальная практика это чтобы весь микросервис помещался в голову одного человека. К примеру некоторые из микро сервисов в моей системе:
отправка писем
отправка смс
геосервис(метоположение по координатам или по айпи итд)
метамодель
ботсервисы(телеграм, фейсбук)
кролер
генератор уникальных ключей(отдает строки по заданному алфавиту заданной длинны гарантированно уникальные в контексте указанного дискриминатора)
преобразователь курсов валют (конвертирует валюты)
рассыльщик уведомлений(когда какому клиенту какое письмо послать)

и прочие

Преимуществ полно, хотя и недостатки есть.
Главные преимущества для меня - простота развертывания, и скорость разработки.
Мне не нужно тестировать и перевыклдывать кучу проектов при изменении одного. Также мне просто делегировать задачи разработчикам и не переживать что они недостаточно компетентны. Как только ты будешь писать более менее объемную систему, причем задача будет делать это быстро, а не как в типичном корп. секторе, ты сразу все поймешь.
Вот есть у меня проект, допустим по фрилансу. С одной стороны у меня куча заказчиков, с другой куча исполнителей. С одних я беру рубли, другим я плачу баксы. Мне нужен сервис который конвертирует из одной валюты в другую. Если он живет дллкой, то тебе придется перевыкладывать оба продукта при изменении сервиса(например ты брал курсы ЕЦБ, а решил брать ЦБ). Паблиш большого проекта на прод - это боль и страх и много заморочек, даже с ci. Оба эти продукта тоже находятся в разработке, потому тебе скорее всего не просто будет взять и выложить их, да еще одновременно. Если же они берут данные по контракту с удаленной тачки через шину сообщений, то все становится гораздо проще. Тебе не нужно перевыкладывть оба продукта, тебе не страшен даунтайм микросервсиа, ты скорее всего не наделаешь там ошибок так как там тривиальный код, ты можешь поручить создание этого сервиса новичку и если сервис плохо сделан - просто выкинуть его, он не затронет никакие части системы. Или, к примеру, сервис должен иметь очень широкий интернет канал, или юзает много процессорного времени, тебя тоже это не волнует так как ты можешь заскейлить каждый сервис отдельно.
Главное не делай так чтоб микро сервисы лазили не в свою базу, и будет норм.

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

hVostt,

это не так
микро сервисы меньше чем монолитное приложение, ответственностей у каждого из них гораздо меньше, состояние меньше, вот у меня есть, например, продукт. Я сканирую сторы приложений(appstore, google play) и на базе полученных данных делаю продвинутую аналитику. Это единый продукт. У меня есть админка для себя, у меня есть кабинет для клиента. Данные из этого сервиса также используются в другом, тоже связанном с мобильными приложениями. Вот я постоянно сканирую стор, это гиагабайты трафика, я посылаю задачи на сканы в шину сообщений, там их подхватывают кролеры, для апстор они просто парсят что мне нужно, для гугл плей через айпиротатор, причем нельзя делать более 2 запрсов в секунду на 1 айпи, потому есть синхронизация заппосов через айпиротатор. Часть крола идет через прокси-сервера, которые тоже предоставляются микросервисом. У меня есть кролер который сканирует и говорит какое приложение по какому запросу на каком месте, эти данные ложатся в NoSQL базу. Клиенты просят ежедневные отчеты на почту или ботом, для этого они формируются и отсылаются отдельным сервисом. В кабинете клиенту нужна продвинутая аналитика, так как запросов много, а аналитика из базы строится долго, у меня есть понятие метомодели, где хранятся и обновляются аггрегированные состояния. Метамодель весит примерно 3 гигабайта в памяти и используется в админке, в кабинете и в смежном продукте. Я принимаю платежи на сайт с разных систем, для этого я слушаю постбеки, но нацеливать их на разные урлы ненадежно и неудобно, потому у меня есть микросервис который слушает постбеки надежным образом. Как только прихоит постбек он хранит его в оперативной памяти, оттуда он сразу сливает его на хдд, оттуда он сохраняет его в базу и бросает в шину сообщений заинтересованному консюмеру.
Состояние клиентской сессии я храню в инпроц, потому что так проще и я знаю что мне не нужно скалить этот инстанс, короткий даунтайм тоже приемлем. В итоге я скейлю парсеры как мне удобно, у меня надежные постбеки по приему платежей, я заранее могу себе позволить писать части систему немасштабируемо, так как понимаю их узкий функционал. У меня есть сейчас клиент который хочте купить доступ к апи, я легко сделаю это - подниму новый микрсоервис, подтяну к нему метамодель, напишу чуть кода, например, чтобы считать цену по вызовам апи и готово. И это никак не затронет то что у меня уже есть. И это будет масштабируемо "из коробки".

ViPRos,

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

hVostt,

это не далеко от реальности, это работает как часы, обслуживает 7 000 платящих клиентов и отрабатывает в среднем 200 запросов в секунду от конечных юзеров
Далеко от реальности это
"...Монолитные приложения точно также горизонтально масштабируются и даже проще, чем микросервисы..."

hVostt,

нет, все очень просто. Приложение вообще не скейлится горизонтально если его заранее не писать под скейл, и скейлится нормально и сервисы и монолит ели изначально это учитывать. Только вот писать монолит под изначальный скейл сложнее чем писать его маленький независимый кусочек(микросервис) под скейл, а переписывать микросервис под скейл и переписывать монолит под скейл - две большие разницы. Я довольно давно не работал по найму, но когда работал делал из крупного в частности: инструмент анализа работоспособности оборудования для сот. оператора, портал для банка, система для коллекторов. Все было для больших организаций, довольно важные продукты. Это был кошмар, там была проблема - как 5 мегабайтный вьюстейт спрятать в базу итд. там все было в статиках и сессии. О горизонтальном скейле речь вообще не могла идти. В одном проекте даже была кнопочка "собрать мусор" которая принудительно вызывала gc. Проекты были строчек примерно 200 000 каждый. Так что в легкость горизонтального масштабирования монолита заранее на это не рассчитанного я не верю, так же как и эволюционное изменение такого монолита под скейл - проще переписать. Каждый из своих микросервисов я тоже переписывал раза по 4. Могу себе позволить так как это очень просто и довольно безопасно.

Addx,

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