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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Управление ценами;
• Взаимодействие с партнерами;
• Market development;
• Управление ассортиментом и гаммой товаров;
• Входящая логистика (транспортировка и перемещение товара);
• Управление товарными остатками;
• Управление финансами;
• Работа с регионами.

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

Переход к API

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

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

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

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

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

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

Следующим этапом будет вынесение всех сложных зависимостей из самой базы данных в технический API-слой. В результате возможно будет разделить ERP на 8 разных систем. 

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

Таким образом, в финале мы получаем 8 автономных систем — у каждого домена появляется собственная база данных, набор API и форма (или несколько форм) с фронтом. Дальше они могут действовать отдельно от большой системы, в том числе создавать собственные релизы, использовать современные технологии и ноу-хау, обеспечивая при необходимости контракты с остальными системами.

Результаты 

Реализованная как low-code продукт, Platformeco позволяет команде разрабатывать и развивать систему без компетенций разработки текущей системы ERP. Сейчас в команде четыре разработчика, которые осуществляют распил монолита. Если какой-то домен хочет сделать API фасад — они также это реализуют на этой платформе.

На сегодняшний день уже 300+ API реализовано через платформу только на существующей ERP.

В среднем на API-интеграцию у команды, не имеющей компетенций в разработке этой конкретной системы, уходит 3-5 дней. Без платформы на это уходило бы от 2 до 4 недель. Мы делаем это в шесть раз быстрее, без внешних подрядчиков и с абсолютно управляемым результатом.

Если говорить про ESB, то до API-зации и работы с новой платформой нам приходилось обращаться к поставщику, чтобы соединить нашу систему с внешним миром. Мы зависели от внешней команды, которая проводила разработку и тестирование. Процесс этот иногда затягивался. Переход на API-функционал позволил значительно сократить time to market, поскольку мы стали автономны и независимы от внешнего поставщика услуг.