Комментарии 8
а где можно найти интерактивную картинку из поста с сеткой мс ? для создании видео , мб подобные сервисы ктото видел
Простота (как антоним к сложности) системы - это своего рода ресурс, им надо управлять, в частности - экономить (при проектировании), или восполнять (рефакторингом) - потраченные на это время и деньги окупаются при разумном планировании. Недостаток простоты увеличивает цену разработки и поддержки - при критически низком значении это может сыграть фатальную роль.
Отдельно управление сложность зависимостей в микросервисах говорит о том, тадам, у вас не микросервисы а распределенный монолит. Можно написать, а где вы эти самые настоящие микросервисы видели то. Да, их в дикой природе практически нет. Просто не надо к распределенным монолитам, которые тоже решают некоторые проблемы, применять теорию "микросервисов", а при переносе практик понимать ограниченность применения. В частности очень четко разделять роли, даже если это один человек, заказчика и поставщика изменений.
И да, если вы сделали большой комок грязи в виде монолита, то вероятно рефакторя их в микросервисы вы получите еще более жуткий комок грязи, просто в силу того, что микросервисы это сложнее монолита, а ваше окружение( ресурсы в самом широком смысле ) и квалификация монолит не осилила.
Чёткенько
Здесь есть проблема с определением стабильных границ между микросервисами - без них сложно получить профит с независимым деплоем частей и не свалиться в распределённый монолит. Если следовать Сэму Ньюману, то нужно начинать с монолитов и по мере стабилизации домена решить, какая конкретно часть в нем применения архитектуры микросервисов. Например увелечение производительности определенного слля или ускорение введения изменений в определенную часть.
А нет ли в этом уравнении третьей силы - управления сложностью разработки?
Не надо ли это также учитывать?
Вполне достаточно прочитать последний абзац, чтобы понять суть статьи
Распутывание микросервисов или балансировка сложности в распределенных системах