Статьи
2021-10-03 07:26

Как уйти от монолитной системы в крупном ритейле

Вадим Пузырев, директор продукта сети гипермаркетов «Леруа Мерлен», рассказал, почему компания решила уйти от монолитной системы и как выглядит процесс перехода к микросервисам через новую API-платформу. Информация будет полезна компаниям, которые задумываются о создании собственной микросервисной архитектуры, а также продуктологам и IT-специалистам, которые хотят повысить эффективность своей работы.
IT-ландшафт backoffice-систем «Леруа Мерлен» состоит из трех больших блоков: системы управления кадрами, системы финансового учета и ERP. Это крупные монолитные приложения enterprise-уровня. Интеграция данных между этими системами осуществляется через центральную шину данных.

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

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

Проблемы монолита

1. Уровень понимания системы

Монолитная система — это крупное приложение, в котором на данный момент автоматизируется 29 бизнес-процессов, и все они относятся к разным направлениям.
Среди них — логистика, управление ассортиментом, розничной ценой, взаимодействие с товарными поставщиками, управление товарным запасом и т. д. Это большой «кухонный комбайн», который из разных областей соединяет в себе все эти операции.
Удержать в голове одного-двух аналитиков весь этот объем знаний практически невозможно. Чтобы внедрять изменения, часто приходится собирать консилиум целой команды, хорошо разбирающейся в системе и процессах. Каждый рассказывает свою часть, определяет влияние новой фичи сквозь призму своих знаний. И только после этого принимается решение, как дальше действовать.

2. Сложности с внедрением изменений

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

3. Проблемы масштабирования

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

4. Технологические барьеры

Монолит, с которым мы имеем дело, — это не самописное решение, а от вендора. Решение изначально было коробочным, и мы его серьезно кастомизировали. Но так или иначе оно крутится на технологиях вендора — это база данных, веб-сервера, приложения, способы интеграции и т. д.
Технологический стек вендора не предполагает нативных инструментов API-зации, особенно со сторонними/open source решениями. Большинство попыток подключить инородный для монолита техстек — это множественные итерации с плохо прогнозируемым результатом. Это финансовые и временные затраты.
Например, нам нужно автоматизированное тестирование — мы хотим, чтобы все проверки делались не руками, а с помощью автоматических тестов, которые пробегают по формам, проходят этот пользовательский путь и подтверждают, что новая разработка не навредила остальным процессам.
Для нас это возможность ускорить процесс и освободить ресурсы, но мы упираемся в то, что лучшие технологии автоматизации наше решение не поддерживают. Мы крайне ограничены в выборе инструментов, а то, что доступно, является по сути еще одним «кухонным комбайном». То есть мы имеем ограничение в применении современных технологий, в том числе по open source технологиям.

5. Слабая совместимость с продуктовой стратегией

В компании произошли организационные изменения, в том числе децентрализация IT. Если раньше IT был сформирован как один департамент, и там работали все технические специалисты, то сейчас отдельную продуктовую команду получило каждое направление бизнеса, которое образует структурную единицу, домен: товарные закупки, HR, работа с поставщиками, логистика, финансы и т. д.
Каждое из них имеет свое собственное мини-подразделение IT.
При этом у нас есть одна крупная монолитная система, которая содержит в себе восемь доменов. Получается, что она нам противоречит: вроде бы в каждом домене происходит автономное взаимодействие, но система одна на всех, и мы в ней как в коммунальной квартире.
Подход и стратегия, которые выбраны на продуктовую тематику и домены, полностью разбиваются об этот монолит, потому что, как ни крути, чтобы система продолжала работать стабильно, мы вынуждены держать определенный релизный цикл, все домены должны под этот цикл подстраиваться.

Решение проблемы с помощью «микролитов»

Процессы в компании разделены на несколько крупных блоков, которые с технической точки зрения можно условно назвать «микролитами» в большом монолите.
—Управление ценами;
— Взаимодействие с партнерами;
— Market development;
— Управление ассортиментом и гаммой товаров;
— Входящая логистика (транспортировка и перемещение товара);
— Управление товарными остатками;
— Управление финансами;
— Работа с регионами.
Внутри каждого «микролита» есть множество своих задач, и мы стремимся к отдельному управлению каждым блоком независимо от большой коробки. Поскольку ERP зависит от требований внешних регуляторов (таких как налоговое законодательство), нам нужно всегда адаптировать систему. Заморозить ее доработку и строить рядом отдельное решение не получится.

Переход к API

Перед нами встал вопрос — как сделать так, чтобы иметь возможность продолжать сопровождать бизнес со всеми необходимыми изменениями и при этом потихоньку разбивать систему на несколько частей, снижая зависимость элементов между собой? Мы пошли путем разделения живой системы на блоки.
Если посмотреть на систему c верхнего уровня, то это база данных с определенной бизнес-логикой и application-решениями — формами, через которые к нам заходят пользователи. С внешним миром все это связано через ESB (Enterprise Service Bus) — сервисную шину данных.
У нас есть около 300 интеграций и взаимодействий с внешним миром, и наша ERP-система не живет сама по себе, а является элементом большого ландшафта приложений компании. ESB тоже имеет вендорлок и свои ограничения с точки зрения функциональности — например, невозможно выстраивать асинхронные методы передачи данных.

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

Для построения синхронной интеграции и API-функций мы используем low-code платформу Platformeco, нашу внутреннюю разработку, которая выполняет функцию оркестратора интеграций и взаимодействий информационных систем компании между собой и с внешним миром.

Платформа позволяет сделать кастомизацию, то есть можно самостоятельно создать необходимый коннектор к нужным базам данных, исходя из существующей архитектуры. Мы сделали коннектор для работы с базой данных Oracle, а также коннектор для взаимодействия с асинхронной передачей данных Kafka.
Для каждой бизнес-функции мы придумали метод. Функции, которые раньше были доступны только через фронт, задублировали и сделали доступными через API. Параллельно отключаемся от ESB.
Следующим этапом будет вынесение всех сложных зависимостей из самой базы данных в технический API-слой. В результате возможно будет разделить ERP на 8 разных систем.
Важно, что все это мы делаем, не останавливая развитие. Мы не можем в какой-то момент взять и отказаться от существующей ERP, она должна работать. Наша главная задача — при внесении изменений обеспечить полноценное взаимодействие пользователя с системой. Интеграцию с новым функционалом мы делаем через слой API.
Таким образом, в финале мы получаем 8 автономных систем — у каждого домена появляется собственная база данных, набор API и форма (или несколько форм) с фронтом. Дальше они могут действовать отдельно от большой системы, в том числе создавать собственные релизы, использовать современные технологии и ноу-хау, обеспечивая при необходимости контракты с остальными системами.

Результаты

Реализованная как low-code продукт, интеграционная шина Platformeco позволяет команде разрабатывать и развивать систему без компетенций разработки текущей системы ERP. Сейчас в команде четыре разработчика, которые осуществляют распил монолита. Если какой-то домен хочет сделать API фасад — они также это реализуют на этой платформе.
На сегодняшний день уже 300+ API реализовано через платформу только на существующей ERP.
В среднем на API-интеграцию у команды, не имеющей компетенций в разработке этой конкретной системы, уходит 3−5 дней. Без платформы на это уходило бы от 2 до 4 недель. Мы делаем это в шесть раз быстрее, без внешних подрядчиков и с абсолютно управляемым результатом.
В новой интеграции мы вышли на онлайн-получение информации. Раньше актуализация данных происходила с отставанием на 10−15 минут. Сейчас во всех системах, где это необходимо, информация обновляется в течение 1−2 секунд.
Если говорить про ESB, то до API-зации и работы с новой платформой нам приходилось обращаться к поставщику, чтобы соединить нашу систему с внешним миром. Мы зависели от внешней команды, которая проводила разработку и тестирование. Процесс этот иногда затягивался. Переход на API-функционал позволил значительно сократить time to market, поскольку мы стали автономны и независимы от внешнего поставщика услуг.