Comments 7
Не бывает никаких "монолитов" и "микросервисов". Есть декомпозиция системы на физические и логические модули. Просто не надо превращать систему в помойку, тогда и скакать от "монолита" к "микросервисам" не понадобится.
Т.е. вы говорите что есть "монопомойка" и парни разбили ее на "микропомойки"?
Нет. Я говорю, что в большинстве случаев, когда речь заходит о монолитах-микросервисах, это значит что парни просто не владеют навыками проектирования. В результате получится та же помойка, только сбоку. Но, справедливости ради, надо сказать, что микросервисы всё-таки заставляют этих парней учиться декомпозиции.
Вопрос к автору. Можно ли построить микросервисное приложение в одном процессе? А в одной кодовой базе?
Можно.
Но нужно ли?
только для @fougasse
Ну если как у автора цель "поделить" код, то поделить "можно" и в рамках одного процесса/кодовой базы. Получить изоляцию логики, не поимев проблем с межсервисным взаимодействием (транспортом), деплойментом и версионированием.
В статье вроде ничего про команды разрабатывающими на разных языках, лайв деплоймент, маштабировании итд не было, только "у нас всё пишется в один файл, сейчас мы внедрим микросервисы и заживем".
Тут нельзя привести точной меры в виде если у вас 1К строк кода это еще нормально, а 1001 это уже монолит. Нет, мерой скорее является тот момент, когда вы начинаете все более активно применять различные шаблоны проектирования.
Спорное утверждение. Одна из проблем монолита не в объёме и сложности кода, а в том что при росте команды качеством этого кода становится трудно управлять, не пересекая границ субдоменов. Я не очень понимаю причём тут разделение приложения на модули и применение шаблонов проектирования. Это не признак того, что срочно нужно пилить микросервисы. Если у вас в команде три калеки, нет отряда тестировщиков и девопсов, то распил на микросервисы приведёт приложение к распределенному монолиту. Даже если изначально вы его задумаете красивым и каноничным (как в книжке Криса Ричардсона)... Возможно у вас уже сформировалась куча команд, которым стало тесно в одном проекте, но про это как раз в статье ничего нет... Если проект делает 1-2 команды, то возможно проблему бы решил основательный рефакторинг, а не радикальные меры с разбиение приложения на десяток сервисов. ИМХО, решение о переходе к микросервисам должно приниматься только в том случае, если вы к нему организационно готовы и только после этого задумываться об окончательной архитектуре.
По пути от монолита к микросервисам