Распил монолита - дело хитрое. А когда дело хитрое, то всегда хочется в первую очередь сделать самое понятное.
Чаще всего самым понятным оказывается вынесение кода в отдельный микросервис. Команда думает: «Ща микросервис запустим, а потом и данные подтянем». При этом как они эти данные будут подтягивать, никто не задумывается. В итоге получаем распределённый монолит, в котором микросервисы продолжают ходить в общую базу и не могут развиваться независимо.
Бывает и наоборот - базу распилили, а бизнес-логика настолько запутанная, что получается просто монолит, который работает с двумя источниками данных.
И в том, и в другом случае очень частый кейс - “впиливание” ранее выпиленного назад в монолит. Добавим сюда же потерю времени, нервы, пост-мортемы и прочие неприятные последствия. Если команда сделает неправильные выводы и не отрефлексирует этот опыт, то мы получим структурную единицу, которая будет как огня бояться архитектурных задач и не станет развивать систему даже под страхом пытки.
Что же делать? Перед миграцией нужно хотя бы на высоком уровне спроектировать целевую архитектуру и порядок перехода. Это не означает, что нужно заранее детализировать весь проект. Но команда должна понимать, как будут разделены и код, и данные.
Начинать с того, что проще и понятнее - плохая идея (пруфы выше). Гораздо профитнее будет сначала хорошенько проанализировать объём работы и потенциальные сложности. Прежде чем приступать к вынесению микросервиса нужно понять, как вы будете выносить И код, И данные. Это две части одного целого, поэтому игнорирование одной из них ведёт к боли и “впиливанию” назад ранее выпиленного.
Преимущества подобного подхода очевидны. В первую очередь, вы защищаете себя от ситуации, где можно вынести только одну часть сервиса (код или данные). Подумать заранее значит иметь ответы на вопросы:
- Что мы будем выносить?
- Что вынесем сначала: код или данные?
- Как будем выносить код?
- Как будем переносить данные?
- Какие конкретные шаги нужны, чтобы всё заработало?
- Как вернуться назад, если гипотеза не сработает?
Когда вы видите всю картину целиком, то становится не так важно, с чего начинать. Вы можете выбрать более быструю часть, чтобы получить какой-то quick win или наоборот более сложную, чтобы потом простое доделать. Но самое главное - у вас всё время будет перед глазами целостный проект.
Мышление письмом - страшная сила. Подумайте сами, что выгоднее: две недели подумать и сделать нормально или “и так сойдёт”, месяцы работы впустую и чувство разочарования? Я вливал микросервисы назад, поэтому мой ответ - подумать.
Любопытствующим рекомендую книгу Сэма Ньюмена «От монолита к микросервисам». Только не мучьте себя русским переводом, он ужасен.