Но, по статье, вы-то как раз сделали все наоборот - пока были стартапом, то делали микросервисы, а как подросли, то стали переходить на монолит. Что странно, потому что как раз на начальном этапе проекта как раз может быть еще вообще неясно на какие микросервисы систему разбивать и рациональней делать монолит, а потом уже, при большей ясности структуры системы её разбивать. Возможно, что у вас все последующие проблемы как раз из-за этого и возникли.
Делали то, что лучше умели и под текущую задачу бизнеса, так как не ясно что получится в итоге - не угадали, пришлось переделывать. С такой же вероятностью могло сильно стрельнуть и такая архитектура принесла бы свои плюсы.
Если у вас была постоянная необходимость распределенных транзакций, то, возможно, у вас были не микросервисы, а так называемый "микросервисный монолит" (который суть есть антипаттерн).
Тут согласен, увлеклись и стали выносить даже то, что жёстко связано между собой. В итоге довольно вовремя спохватились и собрали обратно, оставив только то, что необходимо.
Вот тут как раз микросервисы очень сильно выигрывают. Потому что весь cross-cutting делается в виде отдельных пакетов с версионированием, при этом можно обновить какой-то пакет в одном микросервисе не затрагивая все остальные. В монолите ошибка, к примеру, при рефакторинге какого-нибудь логгера завалит вам весь этот монолит.
Так и есть сейчас, отдельный наборы пакетов для работы c ними. Хотя необходимость править ещё и их немного напрягает, но это видимо побочный эффект такого подхода и с этим ничего не сделать.
Мы подобное и пытались сделать - было два крупных сервиса и общие части стали разделять по функционалу и выносить, в какой-то момент их стало очень много и мы действительно "не сдюжили", да и как показала практика не нужны они были под такую низкую нагрузку. Так что мы теперь объединяем лишнее в монолит, а то что действительно себя хорошо показало в качестве микросервисов - оставляем.
В период максимального распространения микросервисов в проекте их процент превышал 50%, соответственно название вполне оправдано. Ну и само собой, как вы отметили "микро" звучит более модно.
Действительно часть сервисов - довольно крупные и не могут считаться "микро", однако остальная - вполне себе может. Например оплата, аналитика, файловое хранилище, пользователи, авторизация и т.д. Они маленькие, выполняют единственную задачу и содержат не много кода.
Делали то, что лучше умели и под текущую задачу бизнеса, так как не ясно что получится в итоге - не угадали, пришлось переделывать. С такой же вероятностью могло сильно стрельнуть и такая архитектура принесла бы свои плюсы.
Тут согласен, увлеклись и стали выносить даже то, что жёстко связано между собой. В итоге довольно вовремя спохватились и собрали обратно, оставив только то, что необходимо.
Так и есть сейчас, отдельный наборы пакетов для работы c ними. Хотя необходимость править ещё и их немного напрягает, но это видимо побочный эффект такого подхода и с этим ничего не сделать.
Мы подобное и пытались сделать - было два крупных сервиса и общие части стали разделять по функционалу и выносить, в какой-то момент их стало очень много и мы действительно "не сдюжили", да и как показала практика не нужны они были под такую низкую нагрузку. Так что мы теперь объединяем лишнее в монолит, а то что действительно себя хорошо показало в качестве микросервисов - оставляем.
В период максимального распространения микросервисов в проекте их процент превышал 50%, соответственно название вполне оправдано. Ну и само собой, как вы отметили "микро" звучит более модно.
Действительно часть сервисов - довольно крупные и не могут считаться "микро", однако остальная - вполне себе может. Например оплата, аналитика, файловое хранилище, пользователи, авторизация и т.д. Они маленькие, выполняют единственную задачу и содержат не много кода.