Давайте (не) разрушим монолит. Часть 1

Снова и снова клиенты просят меня и моих коллег разделить свой монолит на микросервисы и спрашивают, как это лучше всего сделать. Они уверены, что разделение монолита на микросервисы решит серьезные проблемы, с которыми они сталкивались долгое время.

Часто они не хотят обсуждать, поможет ли это решить проблему, которую, по их мнению, микросервис устранит. Они просто хотят получить советы по техническому проектированию и реализации.

Я нахожу этот подход озадачивающим — по моему опыту, микросервисы редко решают проблемы, которые, по мнению большинства, они должны разрешить. Особенно, если внедрять их без других изменений. Я написал серию постов, в которых обсуждаю распространенные заблуждения о микросервисах. В этой серии разберем, какие проблемы не решают микросервисы, а какие — могут решить (если всё сделать правильно). А также, что мы можем сделать, если микросервисы — это не то, что нам нужно.

Но всё же: и вот мы здесь. Клиент уверен, что ему нужны (или, скорее, он хочет) микросервисы. Он убежден, что разделение монолита решит проблемы. Если спросить, почему клиент этого хочет, как правило, получите два ответа:

1. Монолит превратился в большой комок грязи (программная система с нераспознаваемой архитектурой — прим. пер.), его практически невозможно обслуживать. Микросервисы улучшат сопровождаемость сервисов. 

2. Нужно сократить time-to-market. Вносить изменения в монолит долго. Микросервисы ускорят запуск новых фич. 

Часто в этих ответах звучит что-то вроде: «Разве это не очевидно, глупенький? Зачем ты это вообще спрашиваешь?».

Итак, на основе этих двух ответов давайте посмотрим, помогут ли микросервисы решить эти проблемы. Статья получилась бы длинной, поэтому разбил ее на две части. В этой — рассмотрим первый ответ. А в следующей — второй и подведем итоги.

Проблема «большого комка грязи» 

С момента появления микросервисов более 10 лет назад я постоянно слышу одно и то же: «Монолит это большой комок грязи, его невозможно обслуживать — микросервисы могли бы решить эту проблему».

Поясню:

В том, что ваш код стал недоступен, виновато не монолитное приложение.

Это ваша вина, вина всех участников!

Монолит развертывания, когда говорим о «монолите» — это не всегда большой комок грязи. Он может быть идеально структурирован, использовать одни и те же принципы во всем коде, прост для понимания, обслуживания и изменений. Для этого нужны — модульность и концепция, которые развиваются в IT более 60 лет. И немного доброй воли и дисциплины.

Можно даже организовать работу нескольких автономных групп с одним монолитом и деплоить его несколько раз в день. Маркетплейс Etsy использовал модульный монолит. Благодаря такому подходу в условиях слабой взаимосвязи нескольким командам удалось работать над одной и той же кодовой базой и развертывать монолит более 50 раз в день.

Однако большинство монолитных приложений не такие. Они представляют собой большой комок грязи, который никто в действительности уже не понимает, и который трудно поддерживать и изменять.

Опять же: это не ошибка «монолита». Напротив, это во многом связано с людьми, процессами и организацией:

— Отсутствие коммуникации. Даже во времена agile мы видим, что большинство этапов разработки происходят в одностороннем порядке: бизнес-департаменты записывают требования (на языке agile это «пользовательские истории»), а разработчики должны их реализовать. Обратной связи нет. Обсуждений нет. В худшем случае кто-то (например, инженеры по требованиям, псевдопродакт-оунеры, IT-бизнес-координаторы) находится между бизнесом и IT-департаментом и тщательно следит, чтобы они не общались друг с другом напрямую. Обратная связь и диалог могли бы решить проблемы, но без обратной связи большому комку грязи быть.

— Фича-мания (Feature mania). В дополнение к предыдущей проблеме, во многих компаниях бизнес-функции — это священная корова. Всё строится вокруг них. Ценность определяется только бизнес-характеристиками. Никто не заботится о качестве кода — это не ценно. Вместо этого давайте вложим все деньги в дополнительные фичи, чтобы повысить ценность для бизнеса. Наивно так думать, ведь у IT-систем длительный срок службы и до вывода из эксплуатации их нужно постоянно менять. Если разработчиков стимулируют небрежно собрать код — достаточно хороший для работы новой функции, но который невозможно дорабатывать, уже намечается большой комок грязи.

— Недостаток документации. В процессе разработки мы часто сталкиваемся с недостатком (полезной) документации: какие основные принципы проектирования? Как организована система? Что и где находится? Как взаимодействовать между модулями? Какие стандарты кодинга? И так далее.

Описание основных принципов проектирования и реализации не займет много времени — 10-20 страниц, или 30 страниц для крупной системы. В случае изменений было бы проще поддерживать актуальность документации, ведь там не так много информации, которую нужно обновлять постоянно. Обычно мы находим тонны (часто бесполезной) документации для enterprise-разработки. Но практически никогда не находим важную документацию, прокладывая путь к большому комку грязи. 

— Отсутствие обучения. Даже при наличии необходимой документация, мы понимаем — это не значит, что ее прочли те, кому следовало это сделать. Чтобы вся команда разделяла установленные принципы и стандарты проектирования и реализации, необходима регулярная подготовка. Каждый новичок должен подготовиться, прежде чем вносить изменения в программу.

Время от времени всем членам команды следует освежать знания, чтобы ничего не забылось. Регулярное обучение — возможно, лучшее средство от деградации. Это также стимулирует обсуждение, если какие-то параметры пора обновить. Так все участники процесса не только понимают друг друга, но и соблюдают актуальные стандарты и принципы. На практике мы редко видим такое — что прокладывает дорогу к большому комку грязи.

— Недостаток знаний и навыков. Часто над кодом работают люди без необходимых знаний и навыков. Умение писать некоторый код не означает готовность работать над приложением, которое должно надежно работать следующие 20 и более лет. Например, я занимаюсь ремеслом — могу работать с деревом, камнем и металлом. Также знаю кое-что об электричестве и немного о сантехнике. Тем не менее, без соответствующего образования и подготовки никто не наймет меня строить дом — мне не хватит необходимых знаний. И это хорошо. К сожалению, в IT человек, немного разбирающийся в программировании, работает с критически важным для бизнеса кодом. Как если бы я клал кирпичи, не заботясь о чертежах, статике, дверях, окнах, водопроводных трубах, линиях электропередач или о чем-то еще.

Хуже, что многие компании предлагают низкие зарплаты («Они всего лишь разработчики!»‎), отсутствие развития, устаревшую и демотивирующую атмосферу (а затем заявляют о нехватке навыков, если никто не откликается на их посредственное предложение о работе). Бывает, в таких компаниях часто не хватает сотрудников со скиллами, необходимыми для разработки и сопровождения критически важного для бизнеса программного обеспечения, которое должно надежно работать следующие 20 лет. Добро пожаловать, большой комок грязи!

— Отсутствие дисциплины. Нужно строго следовать стандартам и принципам работы большого приложения, чтобы не ухудшить качества кода. Мы не можем делать так, как нам больше нравится. Если бы все делали это, через несколько месяцев мы увидели бы десятки методов, а код станет непонятным и недоступным для обслуживания.

Иногда так заманчиво просто вызвать эту функцию или метод внутри другого модуля, даже если это часть интерфейса модуля. Я имею в виду, что IDE показывает этот метод. Почему я не должен его вызывать? И тогда многие просто делают по-своему. Давление со стороны, отсутствие документации и обучения вносят свой вклад — в конечном счете это ведет к отсутствию дисциплины. Может прозвучать грубо, но за свою карьеру я видел много людей, которые с радостью добавляли нитку за ниткой к большому комку грязи только потому, что это экономило им немного времени или им так больше нравилось. И снова: добро пожаловать, большой комок грязи!

Вот некоторые из известных мне причин и мотивов, которые приводят к образованию большого комка грязи. Как всегда, причин и движущих сил больше. Но перечисленные выше уже рисуют четкую картину — у всех них есть одна общая черта:

Появление большого комка грязи не имеет отношения к монолитному приложению. Это непосредственно связано с людьми, процессами и организацией.

Итак, почему компании думают, что изменение монолита решит их проблему, без устранения проблем, которые я перечислил выше?

Или, как выразился Саймон Браун: «… возникает вопрос: если вы не можете создать хорошо структурированный монолит, с чего вы решили, что микросервисы — это выход?».‎

Если вы перейдете на микросервисы, не используя ни один из названных драйверов, скорее всего, получите распределенный комок грязи — худшее из двух миров. Монолит из большого комка грязи — это не норм во время разработки, но он хорош в среде выполнения (потому что монолит — это простейший из возможных артефактов). C распределенным комком грязи и время разработки, и время выполнения — не норм, потому что теперь вы усложнили запуск распределенных приложений, не решив ни одной из проблем времени разработки.

Итак, что мы имеем

Компании (всё еще) хотят разделить свои монолиты на микросервисы. Если вы спросите их, зачем — они, скорее, ответят, что с микросервисами надеются решить проблему «большого комка грязи» или сократить time-to-market. Или и то, и другое.

В этой статье обсудили, что простая замена монолита на микросервисы не поможет решить вопрос, потому что реальные проблемы кроются в организации, процессах и людях, а не в технологии — особенно не в монолитном приложении.

Во второй части мы рассмотрим проблему time-to-market. Stay tuned …