Колонки
DIG(IT)AL

Переход от монолита к микросервисам в крупном ритейле. Как провести?

Колонки
Вадим Пузырев
Вадим Пузырев

Директор продукта сети гипермаркетов «Леруа Мерлен»

Алина Алещенко

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

Переход от монолита к микросервисам в крупном ритейле. Как провести?

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

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

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

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

Неповоротливость нашего монолита была вызвана рядом ключевых проблем, над которыми предстояла серьезная работа.

 

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

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

Монолитная система — это крупное приложение, в котором на данный момент автоматизируется 29 бизнес-процессов, и все они относятся к разным направлениям.

Расскажи, как цифровая трансформация изменила твой бизнес

Стань лауреатом RB Digital Awards 2022

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

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

 

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

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

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

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

 

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

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

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

Для нас масштабирование — это боль, особенно когда по части оборудования мы подходим к каким-то лимитам.

 

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

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

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

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

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

 

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

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

Каждое из них имеет свое собственное мини-подразделение IT. 

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

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

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

Проанализировав проблематику, мы стали думать о том, как подружить монолит с API.

 

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

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

  • Управление ценами;
  • Взаимодействие с партнерами;
  • 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, поскольку мы стали автономны и независимы от внешнего поставщика услуг.

Фото на обложке: unsplash.com

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Церемония награждения RB Digital Awards 2022
  2. 2 Риски на пути к цифровой трансформации бизнеса: как их избежать?
  3. 3 В традиционном ритейле есть место для data-driven решений — рассказываем, где и зачем
  4. 4 Зачем автоматизировать бизнес-процессы: 5 главных причин
  5. 5 7 технологий, которые помогут банку стать экосистемой
EdTech: карта российского рынка
Все компании и инвесторы в области образовательных технологий
Перейти