Монолит vs микросервисы - противостояние, которое идет уже не один год
Кто-то говорит, что изолированные сервисы — обязанность любой команды и любой проект, даже стартап, должен быть написан только так, другие говорят, что это только модное направление, куда все побежали, плохо разобравшись и вообще, performance — наше все. Как всегда, правда где‑то посередине. В этой статье я хотел бы осветить проблемы перехода от монолита к микросервисам, рассказать про свой опыт и трудности, которые команде пришлось преодолевать.
Корни проблемы
Когда я пришел в команду, она была уже достаточно крупной, около 20–30 разработчиков на проекте, но это было только начало. Монолит недавно включил в себя новое крупное направление, что условно разделило коллектив на две группы, которые двигались каждая в своем направлении, со своими заказчиками, практически не пересекаясь в кодовой базе.
У меня было 2 года опыта за плечами, я рьяно взялся за работу, начал погружаться в процессы, пилить фичи по ТЗ, улучшая себя как специалиста. Команда начала получать все больше задач в стек как от старых заказчиков, так и от новых. Дейлики начали занимать по 30–50 минут. Нужно было что‑то менять. Тогда группа энтузиастов приняла решение поделить уже мое направление на более мелкие, где будет свой набор аналитиков, разработчиков и тестировщиков. В моменте это принесло хорошие результаты, созвоны стали короче, экспертиза росла, так как микро команда была заточена под конкретное направление. Кодовая база и база данных при этом осталась единая. Но со временем команды опять начали расти, задач становилось все больше, уже начали появляться регулярные конфликты в коде, потому что верхнеуровнево это все еще одно направление со схожим функционалом. Тогда я уже влился в коллектив, в проект, приобрел достаточную экспертизу, и так получилось, что стал мини лидом одной из команд. У меня не было огромного количество бюрократической работы, от меня требовалось управлять командой из 4 человек, смотреть задачи на ревью, давать новые, планировать и проводить оценки. Но вскоре люди начали добавлять, и вот у меня уже 10 человек, которые яростно хотят работать.
С этого момента и начинается идея что‑то сделать с кодом, потому что оценки растут, тестирование страдает. Начался мыслительный процесс.
Трудности принятия решения
Работа шла в офисе, и я стал участником регулярных споров: как же улучшить систему. Идея микросервисного подхода появилась сразу, но достаточной экспертизы именно в этом направлении у «ветеранов» команды не было, а молодые не могли продумать всю архитектуру. Скажу сразу, позиции архитектора в компании не было. На более высоком уровне он был, но спуститься конкретно к нам он бы не мог. Поэтому шли споры, иногда более активно, иногда основная работа приостанавливала их.
Сложилась ситуация, когда наша машина на полном ходу, к ней постоянно прикручивается что‑то новое, а времени остановиться, подумать и пересобрать двигатель просто не было.
В итоге команда поделилась на три лагере:
первые — без инициатив, просто пилю код по ТЗ,
вторые — есть бизнес направления, давайте просто сделаем форк репозитория, запросим ресурсов и будем потихоньку отпиливать ненужное, но уже каждый свое, так точно не сломаем,
третьи — революционеры, которые хотели сделать микросервисы, с блэкджеком и DDD.
Основной спор шел между 2 и 3. Как и писал выше, достаточной экспертизы для 100% формирования архитектуры не было ни у кого, поэтому я и еще несколько революционеров пытались своими силами доказать, что такой подход единственно правильный в сложившейся ситуации. Было трудно, приходилось продумывать много деталей, в том числе, как это все сделать на ходу, сохранить возможность откатиться к изначальной версии в случае проблем на проде, отстаивать буквально каждый шаг, каждую микро идею. В какой‑то момент были мысли, что нам вообще все это не нужно и достаточно просто порефакторить монолит, выделить хорошие абстракции и написать качественную документацию на все это, и будет счастье, потому что сил бороться уже не было. Если разговоры останавливались, команда про это забывала, потому что текущий вариант монстра все еще функционировал. Да, оценка разработки уходила в 120 часов регулярно, да, фичи могли выкатываться раз в 2–3 месяца, но оно работало.
Но самая главная проблема была в том, что никто не мог сформировать примерный расчет трудозатрат на переход и дальнейшую поддержку, которую можно было бы показать бизнесу. А заказчика бесили, но не настолько, чтобы прийти и долбить нас, проблемы со сроками выката. И это все была низовая инициатива, которая должна была решить проблемы менеджмент и немного кода.
Причины споров
Когда обсуждалась идея распила на микросервисы, сразу шли противоборствующие вопросы:
Это же будет медленно. Доходило до того, что лучше же вообще все сделать на sql, зачем нам эта ваша java. Отвечая на такие вопросы, пришло понимание, что микросервисы — это не только про код, а точнее, это вообще не про код, это про менеджмент. Как собрать команды таким образом, чтобы они были максимально экспертны и максимально ответственны за свой кусочек кода. В монолите тебе нужно делать разные задачи, которые не разбиваются на параллельные маленькие подзадачи для каждой команды. Один спринт, аналитик, разработчик и тестировщик работают над одним инструментом, погружаются в него, хорошо, если сделают качественную документацию на все это, а в следующий раз получают совершенно другое. Экспертиза размывается, каждый член команды отвечает за все, следить за качеством подходов и реализаций становится просто невозможно.
И как раз микросервисы напрямую решают эту проблему. Теперь аналитик, даже новенький, отвечает только за небольшой функционал в рамках системы, он погружается в него, ведет описание. Разработчик знает код, который написал он и его коллега, он небольшой, понятный с хорошо переписанными абстракцияим, за которые он несет ответственность. И теперь когда ему прилетает БТ на обсуждение и оценку, он может с уверенностью говорить, что это ломает логику текущего функционала, потому что он видит его каждый день, он у него в памяти в полном объеме. Тестировщик уже имеет набор кейсов, быстро их пробегает, да и сами доработки значительно уменьшаются.
Да, станет медленнее, но управляемее, а потеря 30–50мс в рамках и без того ненагруженного и никогда не проходящего оптимизацию кода — это та цена, которую мы должны платить.
Мы это не умеем, зачем подвергать систему такой опасности, давайте лучше сделаем так, как делали до этого, что точно не подвести бизнес. Страх — это нормально, но не нужно бояться развития, тем более, когда все логические доводы на лицо, а заказчик не должен платить оверпрайс за нашу слабость.
Чем дублирование кода в альтернативном подходе плохо?
Вариант с форком репозитория на несколько независимых имеет несколько очень серьезных недостатков:
Огромное количество ресурсов на старте. Если изначально монолит жил на 6 нодах, то 7 таких монолитов потребуют хотя бы по 2 на каждый. Да, один экземпляр будет меньше, но их сумма просто ужасна;
Любое общее изменение потребует кратного времени разработки и анализа, где каждый будет пытаться перекопировать уже имеющийся код;
Система, которая по логике должна быть единой, превратиться в разорванный труп, каждый кусок которого будет иметь внутри все те же проблемы менеджмента;
Это не решит текущих проблем, потому что по факту команды уже разделены на 7, но действуют в рамках одной кодовой базы, при этом поддержка, инциденты, метрики и все остальное поделено на большую группу людей, в которой есть несколько исконно рожденных ответственных за это. Да, мы получим раздельные релизные циклы, но какой ценой.
В следующей части расскажу, какие конкретно шаги предпринимались, с какими техническими трудностями столкнулись и что из этого вышло.