Если вы впервые слышите про микросервисы, то сперва прочитайте хотя бы статью на википедии. И возвращайтесь, если вас увлечёт эта тема.
Если вы только собираетесь распилить на микросервисы свой первый монолит или уже обожглись на микросервисах и рассылаете коллегам картинку с маленькими какашками, то вам интересно будет узнать, что микросервисы нужны не для уменьшения зацепления, а для того, чтобы потратить много денег.
Компании обычно хотят расти. Они зарабатывают деньги и вкладывают их в развитие своих продуктов, чтобы заработать ещё больше денег и снова вложить их в развитие своих продуктов. На первых порах всё просто — небольшая команда бодро пилит крутой, но несложный проект. Денег становится больше и логично потратить их на разработчиков, ожидая получить больше фич и меньше багов. Но это не работает. Большая команда будет работать менее эффективно, чем маленькая (подробнее об этом в Мифическом человекомесяце). Тогда как же потратить деньги?
Выход есть. Надо разделить продукт на слабо связанные части и выделить по команде разработчиков на каждую такую часть. Очень важно, чтобы каждой частью занималась отдельная команда. Чтобы работать быстро, помнить все тонкости своего дела, разработчики не должны отвлекаться на другие проекты. Таким образом можно тратить деньги на новых разработчиков и получать прогнозируемый профит.
Микросервисы хороши, когда их количество пропорционально количеству команд разработчиков. Команда – это человек 5 минимум, ведь сервис нужно тестировать, вводить в эксплуатацию, поддерживать и развивать. Даже если сервис действительно микро и его развитие после разработки не требуется, он всё равно закреплён за какой-то командой для поддержки.
Таким образом микросервисы это не только архитектурное, но и административное решение. Как бы здорово вы не напилили монолит на сервисы, если количество сервисов сильно больше команд разработчиков, то разработка будет неэффективной. Если над одним сервисом работает очень большая команда (или несколько маленьких команд), то разработка тоже будет неэффективной. Нужен баланс.
Нельзя просто так взять и перейти на микросервисы. Скорее всего у вас просто нет столько разработчиков. Сперва придётся распилить монолит на монолитики поменьше. Например никого не удивить разделением на фронт и бэк (а когда-то jquery.js лежал в одном репозитории с index.php). Это неплохое начало! Если у вас ещё есть люди, отпилите биллинг, админку или поиск. Но остановитесь, когда у вас не останется свободных команд.
Придумывая новый сервис, подумайте и о том, кто будет им заниматься. В идеале это должна быть команда, которая посвятит всё своё время этому сервису. А если вы планируете доверить отпиленный сервис тем, кто и так разрабатывает его в составе монолита, то стоит ли вообще пилить?
Сервисы (микросервисами они станут, когда у вас будут сотни программистов) это просто способ разделить работу между разработчиками. И если у вас только одна маленькая команда, то один монолитный сервис – это тоже хорошая и современная архитектура.
Моя мысль совершенно не оригинальна. Прочтите очень похожую статью The Majestic Monolith.