Выбор в пользу микросервисной архитектуры выглядит разумным для бизнеса и привлекательным для IT. Сервис, ответственный за «свой» кусочек бизнеса, проще контролировать и развивать отдельно от всех прочих сервисов и систем компании: он понятен, ограничен, отделён от других и имеет чётко обозначенную задачу. Это в теории.
В действительности бизнес часто бывает недоволен результатом подобного внедрения: вместо новых фич, гибкой системы и оперативно выполняемых процессов он получает растущие расходы на IT и бесконечную доработку в режиме цепной реакции. Причём с каждой доработкой части системы становятся всё сложнее, а связи между ними — запутаннее.
Почему так получается и что с этим делать — рассказывает генеральный директор KT.Team Андрей Путин.
Архитектура кода не решает организационные проблемы
В монолитной организации велик соблазн списать затратность или непрозрачность процесса на «неправильную» технологию или архитектуру. В подобной парадигме кажется, что замена системы или внедрение микросервисной архитектуры должны решить проблему. Уверен, не только в KT.Team, но и в другие IT-компании нередко обращаются именно с такой просьбой. Даже если предыдущие итерации оказались неудачными, доработка микросервиса всё ещё имеет смысл, т. к. может наладить ситуацию.
В реальности внедрение микросервисной архитектуры зачастую похоже на попытку разделить ком замороженного фарша на кусочки говядины, шпика и перца. Сколько бы усилий вы ни приложили к распилу монолита ножом IT, на выходе получатся не отдельные ингредиенты, а такие же монолиты, но размером поменьше.
С IT-архитектурой дело обстоит точно так же: если на глазок разделить монолитную организацию или набор функций на куски поменьше, они будут напоминать микросервисы лишь внешне.
Бухгалтерия как пример архитектуры
Представьте, что вы руководите крупной организацией с тысячами сотрудников. В этой организации работает большая бухгалтерия, разбитая на отдельные группы бухгалтеров для выполнения разного рода задач: выдачи справок, регистрации сотрудников, пересмотра окладов, составления отчётности.
Выражаясь языком IT, можно сказать, что у вас есть сервис (бухгалтерия) и набор микросервисов внутри него (целевые микроотделы).
Все группы работают независимо друг от друга, но в процессе выполнения задач обмениваются сообщениями, например передают документы или запросы.
Главный бухгалтер имеет очевидную потребность в соблюдении всех процедур и разделении зон ответственности — так он понимает, чем занимается каждая группа, как отделы связываются друг с другом и каков статус по каждому процессу и документу.
Более того, даже если прямо сейчас, скажем, отдел начисления зарплаты ничем не занят, его сотрудников не нужно загружать задачами других микроотделов — это нарушит устоявшиеся налаженные процессы. С точки зрения всей бухгалтерии однодневный простой трёх человек дешевле их переключения на процессы, не являющиеся специализацией данных работников.
Такая организация деятельности бухгалтерии по смыслу очень похожа на микросервисную архитектуру. Каждая обособленная часть системы выполняет одну обособленную задачу, имеет входы/выходы, понятный внутренний процесс и защиту от нецелевого использования.
Как сервисная архитектура превращается в монолит
Теперь представьте, что компания не так велика. Да, у бухгалтерии всё тот же набор задач, но, учитывая масштабы бизнеса, «бронировать» персонал на каждую отдельную задачу не нужно. Например, со всеми задачами справляется группа из семи человек. Тот, кто сегодня занимался НДФЛ, завтра приступит к оплате счетов, послезавтра обновит отчёты, а затем снова вернётся к НДФЛ.
Поскольку здесь команда бухгалтерии уже гораздо малочисленнее, классические «ритуалы» между отделами неизбежно нарушаются. Согласно инструкции, например, из отдела выдачи справок нужно написать письмо, зафиксировать его в реестре исходящих документов, а потом получить письмо в отделе регистрации сотрудников и отметить факт получения в реестре. Но если функции обоих микроотделов выполняет один и тот же человек, процесс выглядит абсурдно.
Попытка избавиться от этого абсурда приводит к тому, что входы и выходы процессов объединяются или исчезают, а границы между микроотделами стираются. В итоге в каждый конкретный момент бухгалтеры вроде бы работают в режиме микросервисов, но в действительности получается монолит. Он выполняет все нужные функции, но каждая из функций непрозрачна.
Ситуация может быть ещё хуже: в бухгалтерии бардак, никто толком не знает, как именно устроены процессы. Разные сотрудники подготавливают справки по разным стандартам; Маша считает отчёты в Excel, а Пётр Семёнович — на калькуляторе; новых работников заводят в систему тремя разными способами…
Когда алгоритмы решения рядовых задач никак не прописаны, каждый новый человек только усиливает образовавшийся хаос. Разделить такую бухгалтерию на микроотделы не проще, чем кусок замороженного фарша — на составляющие его ингредиенты.
Почему микросервисы не работают правильно
Работники бухгалтерии из разных микроотделов свободно общаются друг с другом, поскольку у них есть общий контекст. Для каждого бухгалтера один и тот же термин означает одно и то же. Например, «товар» и для закупки, и для учёта материальных ценностей означает связку «артикул + цена».
Если этого контекста нет, внутренние документы бухгалтерии становятся источником хаоса: один и тот же термин разные микроотделы понимают и учитывают по-разному. Как результат — в отчётах возникают повторы и пробелы, и всё рабочее время бухгалтерии уходит на постоянные выяснения, откуда взялись и куда делись те или иные объекты учёта.
Если со связкой «одно подразделение (один сервис) = один контекст» всё понятно, то как быть с процессами и документами, которые двигаются между подразделениями (сервисами)?
В коммерческом отделе, например, слово «товар» означает не артикул, а модель во всех её цветовых вариациях. Так, для бухгалтера чёрный монитор и белый монитор будут считаться двумя разными товарами, а для коммерческого отдела — двумя вариантами одного товара. Каждый из отделов может обосновать, почему именно его понимание термина — правильное. И оба будут по-своему правы.
Чтобы избежать недопонимания и при этом не сломать процессы каждого из подразделений, нужен «переводчик», который умеет правильно соотносить один контекст с другим.
В микросервисной архитектуре аналогом такого переводчика будет middleware (шина). Это отдельный сервис, занятый исключительно налаживанием взаимопонимания между другими системами — даже если разговаривают они на абсолютно разных языках.
Шины может и не быть — тогда микросервисы будут обращаться друг к другу напрямую, когда этого потребует соответствующий алгоритм, заложенный в их логике. Но подобный подход можно использовать, только если нужно связать небольшое количество микросервисов с помощью небольшого количества интеграций.
Для сложных систем с множеством получателей и отправителей применение данного подхода нецелесообразно, т. к. он вновь превращает архитектуру в запутанный монолит: каждый микросервис «прорастает» в десятки других и должен учитывать их процессы и контексты. В таком случае у вас не получится изменить одну часть системы, не затронув при этом какую-нибудь другую.
С каждым последующим изменением поддерживать и тестировать такую систему становится всё сложнее. Фокус разработчиков смещается с внедрения новых функций на беспокойство о том, «как бы ничего не сломалось». Документация по переводу контекста между отделами и сервисами усложняется и разрастается с каждым днём. Улучшения тормозятся, лучшие специалисты уходят, устав работать на грани провала.
Что делать, чтобы микросервисная архитектура работала
Если коротко — начните со структуры компании:
- сформируйте отделы и микроотделы и определите, во всех ли подразделениях возможно выделить такие микроотделы;
- распределите зоны ответственности между микроотделами;
- создайте бизнес-процессы с чёткими алгоритмами для каждого микроотдела;
- зафиксируйте понятные входы и выходы для каждого микроотдела (запросы, документы, сообщения);
- выстройте понятные взаимосвязи между микроотделами и их бизнес-процессами;
- договоритесь о соотношении контекстов микроотделов.
Выполнив все перечисленные шаги, перенесите готовую организационную структуру в IT-контур, где каждый микроотдел должен получить отражение в виде микросервиса: каждый микросервис в своих процессах и взаимодействиях должен отражать процессы и взаимодействия «своего» микроотдела.
Микросервисная архитектура подходит не всем предприятиям и не всем подразделениям. Если компания или отдел по своей структуре монолитны, вывести их функции в отдельные микросервисы невозможно, как бы соблазнительно это ни выглядело.
Как гласит закон Мелвина Конви, сформулированный ещё в 1967 году, «любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структура которых является копией её собственной структуры внутренних коммуникаций».
Мы в KT.Team опираемся на этот закон при разработке IT-продуктов для заказчиков: начинаем с отрисовки бизнес-процессов, с которыми будет связан продукт, и только потом «спускаемся» на уровень кода. Так IT-продукт безболезненно встраивается в работу компании и оказывается эффективен для решения её задач.
