Почему работающая микросервисная архитектура начинается с порядка
в бизнес-процессах

В монолитной организации велик соблазн списать затратность или непрозрачность процесса на «неправильную» технологию или архитектуру. В подобной парадигме кажется, что замена системы или внедрение микросервисной архитектуры должны решить проблему. Уверен, не только в KT. Team, но и в другие IT-компании нередко обращаются именно с такой просьбой. Даже если предыдущие итерации оказались неудачными, доработка микросервиса всё ещё имеет смысл, т. к. может наладить ситуацию.

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

С IT-архитектурой дело обстоит точно так же: если на глазок разделить монолитную организацию или набор функций на куски поменьше, они будут напоминать микросервисы лишь внешне.

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

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

Все группы работают независимо друг от друга, но в процессе выполнения задач обмениваются сообщениями, например передают документы или запросы.

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

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

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

Теперь представьте, что компания не так велика. Да, у бухгалтерии всё тот же набор задач, но, учитывая масштабы бизнеса, «бронировать» персонал на каждую отдельную задачу не нужно. Например, со всеми задачами справляется группа из семи человек. Тот, кто сегодня занимался НДФЛ, завтра приступит к оплате счетов, послезавтра обновит отчёты, а затем снова вернётся к НДФЛ.

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

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

Ситуация может быть ещё хуже: в бухгалтерии бардак, никто толком не знает, как именно устроены процессы. Разные сотрудники подготавливают справки по разным стандартам; Маша считает отчёты в Excel, а Пётр Семёнович — на калькуляторе; новых работников заводят в систему тремя разными способами…

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

Работники бухгалтерии из разных микроотделов свободно общаются друг с другом, поскольку у них есть общий контекст. Для каждого бухгалтера один и тот же термин означает одно и то же. Например, «товар» и для закупки, и для учёта материальных ценностей означает связку «артикул + цена».

Если этого контекста нет, внутренние документы бухгалтерии становятся источником хаоса: один и тот же термин разные микроотделы понимают и учитывают по-разному. Как результат — в отчётах возникают повторы и пробелы, и всё рабочее время бухгалтерии уходит на постоянные выяснения, откуда взялись и куда делись те или иные объекты учёта.

Если со связкой «одно подразделение (один сервис) = один контекст» всё понятно, то как быть с процессами и документами, которые двигаются между подразделениями (сервисами)?

В коммерческом отделе, например, слово «товар» означает не артикул, а модель во всех её цветовых вариациях. Так, для бухгалтера чёрный монитор и белый монитор будут считаться двумя разными товарами, а для коммерческого отдела — двумя вариантами одного товара. Каждый из отделов может обосновать, почему именно его понимание термина — правильное. И оба будут по-своему правы.

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

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

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

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

С каждым последующим изменением поддерживать и тестировать такую систему становится всё сложнее. Фокус разработчиков смещается с внедрения новых функций на беспокойство о том, «как бы ничего не сломалось». Документация по переводу контекста между отделами и сервисами усложняется и разрастается с каждым днём. Улучшения тормозятся, лучшие специалисты уходят, устав работать на грани провала.

Мы в KT.Team опираемся на этот закон при разработке IT-продуктов для заказчиков: начинаем с отрисовки бизнес-процессов, с которыми будет связан продукт, и только потом «спускаемся» на уровень кода. Так IT-продукт безболезненно встраивается в работу компании и оказывается эффективен для решения её задач.