От монолита к микросервисам в разумном порядке

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

Переходить к выставлению приоритетов имеет смысл после того, как выделены функциональные области или граничные контексты (BoundedContexts). Иначе определить значения для таких параметров, как бизнес-критичность или инновационность будет крайне затруднительно.

В статье рассмотрены такие параметры как:

• Уровень зависимостей
• Объем транзакций (обращений)
• Утилизация ресурсов
• Сложность сервиса
• Бизнес-критичность
• Интенсивность изменений
• Инновационность

Зависимости

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

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

Объем траназкций

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

Из графика видно, что больше обращений к витрине товаров, карточке товара, поиску и сравнению товаров. При этом анализ зависимостей может показать, что витрина товаров, товар и сравнение обладают значительно бОльшим количеством зависимостей, чем поиск, что продвигает нас в сторону выбора для вынесения сервиса «Поиск», однако, продолжим.

Утилизация ресурсов

Определить этот параметр в монолитной структуре очень сложно, а иногда и вовсе невозможно. Однако, параметр важный и попытаться стоит. Учитываем потребление CPU, памяти, количество подключений, I/O-операции, количество потоков выполнения и так далее. Выделение сервиса с высокой утилизацией ресурсов несет прямую ценность в виде лучшего функционирования системы.

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

Сложность сервиса

Сложность (complexity) складывается из сложности понимания данных, с которыми сервис взаимодействует, сложности кода, конфигурации, работы с потоками, сложности предметной области, бизнес-логики, работы с аппаратными обеспечением, сетевыми подключениями, количества строк кода. Чем сложнее сервис, тем сложнее его вынести за пределы основной системы.

Бизнес-критичность

Бизнес-критичность оценивается по прибыли и/или клиентскому опыту. Более критичные модули обеспечивают большую ценность для бизнеса. Для интернет-магазина витрина, карточка товара и оплата могут быть значительно более критичными, чем отзывы и сравнение, так как обеспечивают основной бизнес-процесс.

Скорость (интенсивность) изменений

Скорость (или интенсивность) изменений определяется как количество внесенных изменений за короткий промежуток времени. Одно из преимуществ микросервисов в том, что автономные команды независимо разрабатывают и поставляют сервисы с требуемой скоростью:

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

Технически интенсивность изменений можно определить с помощью команды git log или инструмента eazybi, но следует быть аккуратным, так как в монолитном приложении границы предметной области могут нарушаться и высокая интенсивность может быть обусловлена наличием зависимостей, а не фактическим изменением рассматриваемого сервиса.

Инновационность

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

Инновационность здесь — это способность найти и запустить новые бизнес-модели или существенно расширить существующие.

Когда все перемешено, то найти возможности, а тем более реализовать их бывает очень сложно, особенно если смешаны в одной куче и generic и core поддомены. Развитие core сдерживает то, что для бизнеса в целом особой роли не играет, а найти возможности для роста в таком месиве — отдельный сорт садомазохизма 🙂

Вот пример того, о чем я говорю:

Итог

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

Допустим, текущая система перестает справляться с нагрузкой, в таком случае наиболее критичным параметров будет утилизация ресурсов, за ним будут следовать параметры «Зависимости» и «Сложность» и другие. Выбирать будем те сервисы с максимальной нагрузкой, которые при этом можно максимально быстро и просто вынести из монолита.

Оценив гипотетический магазин по всем параметрам получим картинку, в которой не так просто разобраться:

Поэтому отстроим график по важным критериям (утилизация, зависимости, сложность):

Видим, что у нас появился отличный кандидат в виде поиска, сравним теперь его с другими кандидатами по всем критериями и проверим, ничего ли мы не упустили:

И видим, что поиск еще и дает возможности к инновационности и гибкости (из-за высокой интенсивности запросов на изменения).