[Перевод] Давайте (не) разрушим монолит. Часть 2
В предыдущей статье мы начали обсуждать, что компании (всё еще) хотят разделить монолиты на микросервисы. Если спросить их, что они этим изменят — услышите, что с микросервисами рассчитывают решить проблему «большого комка грязи» или сократить time-to-market.
Далее мы обсудили, что изменения в монолитном приложении не решат вопрос «большого комка грязи», потому что реальные проблемы кроются в организации, процессах и людях, но не в технологии. Во второй статье мы рассмотрим вопрос time-to-market, а затем подведем итоги.
Вопрос о time-to-market
Другой типичный ответ, который вы можете услышать от компаний, почему они хотят разделить свой монолит на микросервисы — им нужно сократить time-to-market. Часто ответ основан на давлении, которое они испытывают со стороны своих бизнес-подразделений. Жалобы на медленную работу IT-департамента можно услышать во многих компаниях, особенно в крупных.
Рассуждения о переходе на микросервисы, обычно сводятся к следующему: «У нас уходит много времени для внесения изменений в код, потому что монолит сложный и его трудно понять. Также требуется длительный этап тестирования, чтобы убедиться, что мы ничего не нарушили. Если мы разделим монолит на микросервисы, отдельные сервисы будут небольшими. Сложность исчезнет, потому что сервисы небольшие и, следовательно, их легко понять. Это значит, что мы можем быстрее вносить изменения без долгого тестирования и решим проблему time-to-market».
Конечно, обычно такие рассуждения содержат больше деталей. Но в общих чертах обычно это выглядит так.
Еще раз:
Это не вина «монолита», от которого страдает ваш time-to-market.
Это ваша вина, вина участников процесса!
Анализ цепочки ценностей в IT
Прежде чем переходить к микросервисам для сокращения time-to-market, рекомендую составить честную схему создания стоимости. Распределите все действия от бизнес-идеи до ее практической реализации, когда клиенты смогут с ней ознакомиться. Затем добавьте среднее время обработки и среднее время ожидания. Еще раз, будьте честны!
Как правило, это вызывает цепочку от десятка и более шагов, включая несколько этапов утверждения. Бизнес-идея стоит в очереди перед следующим действием — ждет, когда ее подхватят. Например, функционал ждет, когда его объединят с другими функциями в проекте, релизе, program increment — или как это называется у вас. Мы ждем утверждения проекта и бюджета. Ждем расстановку приоритетов, доработки, планирования, внедрения, тестирования, деплоя и так далее.
Если подсчитать время ожидания, часто оказывается, что от 80% времени мы просто ждем запуск следующего этапа. Особенно, если общая цепочка содержит периодические действия. Например, в крупных компаниях часто есть несколько «советов» и «комитетов», которые собираются лишь время от времени, чтобы оценить и (надеюсь) подписать все пункты, которые остались после предыдущего заседания.
Клаус Леопольд прекрасно описал это в своей книге «Переосмысляя Agile». Он представил создание типичной IT-цепочки ценностей со всеми этапами и согласованиями, которые проходит идея во многих компаниях, прежде чем ее оценят клиенты (включая время ожидания). Как уже сказали, комитеты собираются периодически: ежемесячно, ежеквартально или даже ежегодно (например, для планирования бюджета или портфеля проектов). И где-то на 2/3 этапе цепочки создания ценностей вы обнаруживаете маленькую вставку «разработка» с комментарием «Мы такие чертовски ГИБКИЕ, ура!».
Более быстрое развитие не помогает
Если вы возьмете результаты цепочки создания ценности и посмотрите на фактическое время внедрения (помним: деятельность, которую вы хотите ускорить, разбив монолит на микросервисы, чтобы сократить time-to-market), скорее всего, оно составляет менее 1% или 2% от общего объема времени вывода функции на рынок. Этого необходимо, чтобы она стала идеей и была доступна потребителям.
Давайте предположим, что разработка функции (от идеи до производства) занимает 200 дней — не редкость для корпоративной agile среды. Также предположим, что среднее время внедрения составляет 4 дня — 2% от общего времени, что не редкость для типичной бизнес-функции. Представим, что вам удалось сократить время внедрения на 50%, что было бы неплохим улучшением.
Ура, вы только что сократили время выполнения заказа с 200 до 198 дней! Для этого вам пришлось проделать большую работу заранее. Вы разбили монолит на микросервисы, стоимость которых обычно составляет несколько миллионов евро. Это не принесло никакой пользы бизнесу, а вы использовали архитектуру, на порядок сложнее старой в эксплуатации и обслуживании. Даже если переход приложения на микросервисы сэкономил бы 10 дней, это было бы улучшением всего на 5%. Вряд ли это стоило затраченных усилий, еще и сложностей добавило.
«А как же пропускная способность», — скажите вы. Мы удвоили пропускную способность. Это чего-то стоит.
Конечно, это чего-то стоит. Но выражается по-другому. Возможно, вы сможете реализовать больше функций за единицу времени. Но время на реализацию фичи заметно не изменилось. Если мы говорим о «времени выхода на рынок», то имеем в виду время выполнения, а не пропускную способность.
Вероятно, вы не увеличите пропускную способность в два раза, поскольку фактическая разработка программного обеспечения не является узким местом в IT-цепочке создания ценностей. Даже если это должно быть текущим узким местом, оно не единственное в общей цепочке. Когда вы внедрите больше функций за определенный период времени, станут заметны другие. Сократив время внедрения на 50%, как в примере выше, общая пропускная способность, скорее всего, увеличится только на 10–20% из-за других узких мест в цепочке ценностей.
Сокращение времени ожидания — помогает
Чтобы действительно сократить time-to-market, необходимо честно оценивать время разработки, ожидания разработки, очередь на разработку и постоянно работать над устранением узких мест по всей цепочке создания ценности. Но это гораздо больше, чем просто технические изменения в программе. Это касается организации, процессов и людей.
Если принять изменения, на определенном этапе разделение монолита на микросервисы могло бы ускорить работу — это позволило бы кроссфункциональным командам независимо деплоить свои сервисы, если всё сделано правильно.
Это работает только в том случае, если изменить организацию, процессы и повысить квалификацию сотрудников. Изменение затронет не только IT-отдел, но и бизнес-подразделения, структуру, распределение полномочий по принятию решений, ответственности и многое другое. Короче, улучшение time-to-market означает серьезные изменения, а не перестановку технологий.
Также необходимо правильно спроектировать архитектуру для сервисов и правильно распределить функциональность между ними. К сожалению, факторы, определяющие разработку распределенных приложений (которыми по определению являются микросервисы), сильно отличаются от факторов, определяющих разработку модульной структуры (модульного проектирования монолита).
Если разработка обычных приложений относительно понятна, разработка распределенных приложений — нет. Если вы неправильно спроектируете сервис, процесс разработки не пойдет быстрее, чем при работе с монолитом. Есть вероятность, что вы не станете быстрее после перехода на микросервисы. А только значительно усложните себе жизнь.
Наконец, всегда помните, что монолит также начинался как чистое, хорошо спроектированное и структурированное приложение. Со временем оно превратилось в большой комок грязи по причинам, которые связаны не с самим кодом, а с организацией, процессами и людьми.
Следовательно, если вы не решите ни одну из этих проблем, а только разделите монолит на микросервисы, то качество скоро ухудшится, вы окажетесь на пути к распределенному большому комку грязи — и любое временное увеличение скорости скоро исчезнет.
Другие проблемы
Вот два типичных ответа, которые я слышу, когда спрашиваю клиентов, почему они хотят разрушить свой монолит: они ожидают, что таким образом решат свои проблемы с большим комком грязи и time-to-market.
Иногда вы можете получить и другие ответы, например, что микросервисы поддерживают возможность повторного использования и, таким образом, помогают экономить деньги. Или что они необходимы из соображений масштабируемости. Или для поддержки автономности команды.
Я обсуждал эти и другие ошибки в серии статей «Ошибки микросервисов», о которых уже упоминал в начале первой статьи, поэтому не буду говорить о них здесь снова. Если вам интересно понять, почему все эти очевидные аргументы в пользу микросервисов являются всего лишь ложными выводами — советую почитать их.
Итоги
Эти статьи начались с наблюдения, что компании (всё еще) хотят разделить свои монолиты на микросервисы. Если вы спросите, зачем — как правило, они рассчитывают решить проблему «большого комка грязи» или сократить time-to-market.
Затем рассказал, что просто замена монолитного приложения на микросервисное не приведет ни к тому, ни к другому. Реальные проблемы заключаются в организации, процессах и людях, а не в технологии — и особенно не в монолитной архитектуре.
Тем не менее, осталась давняя традиция решать организационные, технологические и кадровые проблемы с помощью технических решений, потому что проще внедрить еще одно, чем решать реальные (более трудноразрешимые) проблемы. За многие годы мы привыкли следовать по пути ложных технических решений — кажется «естественным», что большинство людей давно перестали подвергать сомнению этот путь.
Но это лишь ложное решение. В такой ситуации путем внедрения технологий ничего не решится.
Со временем вы столкнетесь с теми же проблемами, что и прежде. Плюс с еще новым слоем проблем, потому что вы добавили еще одну технологию, еще один уровень сложности в свой и без того слишком сложный IT-ландшафт (смотрите серию моих блогов «Упростите!», в которых подробно обсуждается проблема сложности в IT).
Значит ли это, что всеми силами следует избегать микросервисов?
Нет, это не так.
Как я уже говорил в серии блогов «Ошибки в микросервисах», они нужны вам реже, чем думает большинство. Тем не менее, если использовать их уместно, правильно и в нужном контексте, они могут стать полезным архитектурным решением.
Но и микросервисы не являются лекарством от проблем, которые коренятся вне технологий. Они могут поддержать другие меры, необходимые на уровне процессов, организации и персонала. Без правильного применения микросервисы в принципе бессмысленны — как правило, даже контрпродуктивны.
