Как стать автором
Обновить

Комментарии 10

Мне кажется, все уже усвоили главное правило микросервисов: если можно не использовать микросервисы, не используйте их.
В статье это же, только более развернуто.
НЛО прилетело и опубликовало эту надпись здесь
это размен экспоненциальной сложности разработки при росте монолита на линейную в области инфраструктуры и девопс

Почему-то всегда забывают про обеспечение целостности данных, если это требуется. А это задача ни разу не тривиальная.
НЛО прилетело и опубликовало эту надпись здесь
есть внятные описанные правила декомпозиции, проблемы озвученные в статье говорят об их игнорировании

Список правил в студию! А то многие всё ещё мучаются, попадётся какой-нибудь healthcare, и поди, нащупай там границы ответственности между микросервисами и прочий bounded context

микросервисы это способ бороться с экспоненциально возрастающей сложностью


А поделитесь плиз какими-то пруфлинками этому утверждению. Мне совсем неочевидно каким образом распиливание одного процесса на несколько уменьшает сложность.

Весь интернет — один большой пруфлинк. Если бы существующие сайты и сервера разрабатывались не раздельно, а были частью монолита — интернета в текущем виде бы не существовало.


С микросервисами та же история — если один процесс удаётся распилить на несколько слабо связанных между собой — каждый их них разрабатывать действительно проще… а если они оказываются после распиливания сильно связаны — сложнее. В общем и целом уменьшение сложности здесь является следствием удачного разделения на слабосвязанные части, а уж как эти части оформлены — сетевыми сервисами, встроенными микросервисами внутри монолита, или просто отдельными модулями/библиотеками — не так принципиально. Просто когда это сетевые сервисы становится сложнее работать мимо его API напрямую с его БД, сложнее писать без документации API, без автоматизации выката, etc. — т.е. без всего такого, что внутри монолита обычно делать ленятся. И как следствие этой лени обычно получается так, что с микросервисами действительно нередко удаётся бороться со сложностью более успешно, чем без микросервисов.

Был монолит со сложностью 10. Делим на 10 микросервисов, получается не 10 по 1, а 10 по 2-3. Но проектом со сложностью 2-3 управлять гораздо проще, чем сложностью 10. И плюс добавляем сложность в взаимодействии, если декомпозиция проведена хороша, то взаимодействий от 9, иначе до 90, сложностью 1.
Получается, вместо сложности 10 выходит 30=20(сервисы)+10(взаимодействия), как и написано в статье («разработка может обойтись вам примерно в 3 раза дороже, чем на монолите», в последнем абзаце). Но управлять 10 монолита уже нереально (невозможно добавить ещё одну, чтобы стало 11), тогда и делают микросервисы.

Согласнен что микросервисы ТРЕБУЮТ слабой связанности, что хорошо для управояемости. Для управлением слабой связанностью внутри монолита есть сборки, инкапсуляция, средства ЯП и огромное количество паттернов на выбор (конечно же IOC рулит). Т.е. разработчик в проекте с монолитом не должен работать со всеми модулями, у него и в монолите достаточно изоляции и средств её поддерживать. Если архитектор дисциплинирован то сложность моделей можно удерживать на тех же Ваших условных 2-3 единицах, не переходя на микросервисы.

"Размен экспонициалтной сложности?" По-моему не тем Вы зананимались 5 лет, и зря стесняетесь задавать вопросы. Готов утверждать что микросервисы имеют большую асимптотическую оценку сложности разработки. Может конечно не степенную но коэфициент при том же значении будет выше чем у монолита. Автор это затронул в части сложности отладки. Умножте на версионность модулей (разные версии на боевых и тестовых средах) и невозможность статического анализа кода всего решения и вот Вам повышенная(!) сложность разработки.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий