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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переход к#nbsp;API

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

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

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

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

Результаты

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