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

G>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.
G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

Так изи или нужен немалый труд нескольких команд специалистов? Про зрелость технологии дискутировать не буду, а вот то, что простые и дешевые решения на ней становятся дорогими и сложными это факт. Ну и цена ошибки просто зашкаливает, аналитики выдали что-то типа — сервис должен выдерживать работу 20к посетителей в час, а потом выясняется, что эти посетители приходят на событие в час в одно и то же время и логин 20к в течении минуты кладет все. Да и без этих ошибок, вывод состоит в том, что мы провели НТ и система не выдержала, надо увеличивать мощности или оптимизировть код. Потом начинается работа по апроксимации этого вывода в дорогие и неоднозначные решения, посколько сказать заранее сколько потребуется мощности в пике нагрузки или насколько мы сможем что-то оптимизировать можно с очень небольшой точностью, так как стоимость железа в RPS превращается очень опосредовано, а уж время программистов на оптимизацию и эффект от нее часто оценивается либо интуитивно, либо программисты говорят что-то типа "да, мы знаем, что здесь O(N!) и это превращается в O(log N) парой строк, но тогда не стали заморачиваться premature optimization".

У меня лично складывается такое впечатление от МС архитектуры
1. Ничего, что сейчас сложно и нужно 20 человек там, где могут справиться 2, зато потом будет все легко и просто.
2. wtf???... неделя поиска распределенного бага, фуух, зато мы получили классный опыт
3. Добавить крупную фичу? Это легко и просто. Нужно два месяца проектирования, две недели совещаний с разработчиками нужных сервисов, месяц разработки, потом месяц регресса. А что вы хотели, это айти, здесь не бывает дешевых решений. Зато нам не страшно, что любой человек уволится, поддерживать его микросервис может любой другой, так как там три строки бизнес кода, остальное — инфраструктура по взаимодействию с остальными. Вон Вася легко сможет поддерживать еще один, все равно его микросервис с прошлого года не требовал изменений. А всего три месяца онбординга и новый программист поймет, как у нас здесь все работает и снимет допнагрузку с Васи.