Здравствуйте, Miroff, Вы писали:

M>Да ровно те же что и в монолите. Берешь сценарии, которые составляют SLA, определяешь сервисы, которые в них задействованы, тестируешь, снимаешь метрики, анализируешь. Плюс именно микросервисов в грануляции метрик. В монолите ты получаешь ответ "приложение делает 100RPS на стенде" и делай с таким ответом что хочешь, ни в чем себе не отказывай. Можешь профайлер запустить, если не встраивает. В микросервисах ты получаешь ответ "сервис А делает 20k RPS, Сервис Б делает 100k RPS, сервис В делает 100RPS и упирается в CPU" и тебе понятно что и как нужно масштабировать. Более того, ты эти же метрики получаешь и из продакшена и имеешь относительно адекватные профили нагрузки именно для твоего сервиса, без необходимости извлекать их из зашумленных профилей всего приложения.

Чтобы было ровно то же, метрик должно быть столько же, а это не так, метрик на порядок больше и 100% CPU на одном сервисе в НТ на стейдже нам говорит только о том, что дав этому сервису больше CPU мы возможно что-то ускорим. Это собственно все, остальное исследуем на проде.

M>Сложность, как метрика неоднородности, естественно никуда не делась. Микросервисная архитектура упрощает лишь организацию разработки путем навязывания нормальных инструментов для формализации API, мониторинга, тестирования и деплоя. Без таких инструментов микросервисы не взлетают. В отличие от монолита, где все это внедряется по остаточному принципу когда уже зад начинает пригорать. Микросервисная архитектура упрощает взаимодействие между командами благодаря тому, что у них остается меньше точек взаимодействия.

Формализация API, мониторинг, тестирование и деплой маст хев в любом случае.

M>2 человека и даже 20 человек это вообще не про микросервисы.

Это как пример перехода.

M>Ну т.е. можно поиграться, но профита не будет. Вот 200 человек это про микросервисы. Представь себе монолит с командой в 200 человек. Да плевать уже на переиспользование алгоритмов, у них даже мердж веток в мастер будет требовать отдельного протокола и занимать недели. С микросервисами ты делишь эти 200 человек на ~20 команд которые пилят собственные модули, версионируют и документируют API, независимо деплоятся и взаимодействуют друг с другом очень ограниченно. Не особо важно что они не могут переиспользовать алгоритмы, когда одна команда пишет на python и tensorflow, а другая на Java и SQL.

200 это именно комиттеры или общий размер команд? Если комиттеры именно в один неделимый проект, то понятное дело, что таких проектов единицы и к ним надо подходить с особыми мерками. Монолит с командой в несколько десятков комитеров мне и представлять не нужно, есть опыт. Разбить его на микросервисы и 200 человек не хватит потом для поддержки.