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

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

Попросили поделиться опытом М.Видео-Эльдорадо руководителя домена Канонические сервисы Александра Зеленюка. Под катом его рассказ.

Реплатформинг «от А до Ы»

Для начала давайте определимся с понятиями. Очевидно, что все всё знают, но для проформы дадим несколько определений на букву R.

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

Рефакторинг — это переработка исходного кода программы, чтобы он стал более простым и понятным.

Ребилдинг — перестройка или переделка существующей системы.

Репроектирование\перепроектирование – изменение архитектуры действующей системы.

Так вот, реплатформинг замаячил на наших картах в свете того, что мы ушли от старой платформы Oracle ATG в кастомное решение в остальных частях сайта и мобильного приложения. Все это обусловлено стратегией компании и стремлением к технологическому суверенитету (модное ныне словечко, почти такое же, как «цифровая трансформация» «модернизация», «цифровизация», «диджитализация» и прочий «эджайл»). 

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

Некоторые считают, что миграция монолита в облако — затея утопическая, до момента, пока она не возникает в головах менеджмента, а затем у вас в Jira. Кажется, местами подобное бывает позабористей, чем «Капитал» Карла Маркса любой тимбилдинг. Задача реплатформинга прочно и на долгие годы вперед цементирует отношения программистов, представителей различных отделов и департаментов вашей компании. И все во имя общей и неминуемой победы над системой. Проверено на себе!

Приз в этой технологической гонке вполне осязаем – сокращение дата-центра и все плюшки для DevOps. Кроме вас, безусловно, этому судьбоносному решению будут рады поставщики ваших облачных решений (в нашем случае это парни из Яндекса). Главное не забывать про скорость разработки, масштабируемость, обслуживание и обеспечение устойчивости своего «облачного новодела». С другой стороны, на вашей стороне, все плюсы нативной облачной архитектуры — от микросервисов и контейнеров, до Serverless и Kubernetes. Бонусом прибавьте использование единых политик и платформ CI/CD, безопасности и DevSecOps.

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

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

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

И здесь, увы, не обходится без подводных камней. Архитекторы, занимающиеся модернизацией монолита, обычно, не являются первоначальными его разработчиками или архитекторами. Более того, даже если они стояли у его истоков, со временем, монолит словно кит обрастает ракушками (техническим долгом). Это может обнулить значительную часть вашего изначального замысла. Главное не опускать руки и постараться распутать этот гордиев узел («код-спагетти», «кодовые ласточкины гнезда» и прочее).

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

Наш реплатформинг (немного из внутренней кухни)

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

Несмотря ни на что, мы продолжаем работать над оптимизацией системы. И хотя начинали мы проект в начале 2022 года с коллегами из ЕРАМ и Accenture, после их ухода с рынка, работа не остановилась. Всю нужную нам экспертизу мы забрали внутрь. Вся команда для этого есть теперь в штате.

Сегодня мы строим гибкую, агностическую систему, способную работать с любыми заказчиками (речь не только про наших клиентов, но и пользователей маркетплейсов). Это позволит решать два глобальных запроса от нашего бизнеса и клиентов:

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

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

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

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

Не так давно мы внедрили решение по межсервисного взаимодействия на базе Istio Service MESH. Это позволяет нам сегодня на уровне деплоймента параллельно проводить АВ-тестирование, запускать одновременно в продакшен 2-3 версии, мы также умеем делать «канареечный деплой» и многое другое.

Одним из ключевых элементов реплатформинга можно считать реплатформинг розницы, поскольку он позволяет сэкономить массу оборудования и ресурсов с точки зрения инфраструктурной и «железной» поддержки. Сегодня практически в каждом из 1000 магазинов есть своя мини-серверная, свой сервер, БД, не говоря уже про рабочие станции.

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

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

Прямо сейчас мы готовимся пилотировать облачную печать ценников в магазинах. Это довольно сложный процесс, на самом деле. Тем более, если речь идет сразу о двух торговых сетях – М.Видео и Эльдорадо. Мы постарались его максимально унифицировать в части используемых шаблонов и управления процессом. В ближайшее время «зарелизим» нативное мобильное приложение под Android.

Если раньше, удел печати ценников был за 1-2 людьми, обладающими сакральными знаниями о печати ценников в магазине, то с обновлением мобильного приложения продавца эта функциональность появится у управляющих и ответственных сотрудников, прямо из их смартфона.

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

Наш оптимизм, во многом, связан с тем, что за последнее облачные решения шагнули далеко вперед. Начиная от предложения удобных балансировщиков, до совместной доработки систем управления базами данных. Например, мы долгое время жили на MySQL и недавно мы успешно протестировали с ними жизнь с MongoDB. Сейчас успешно туда мигрируем (кажется это достойно отдельной темы для статьи на Хабр, но это не точно).

В этом месте могут возникнуть подозрения относительно нашей Я-ангажированности. На самом деле, мы начинали общаться со всеми, включая клауд от одного зеленого банка. Но на тот момент, разность облачных архитектур склонила чашу весов в пользу Яндекса. У других был open stack, в противовес собственным разработкам яндексоидов. На самом деле, с тех пор много воды утекло и коллеги серьезно продвинулись в технологическом плане, просто мы уже «глубоко» в Яндексе. При этом, периодически мы думали о резервном облаке. Но содержать два полноценных облака пока что (мягко говоря) дорого. 

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

Вместо заключения

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

P.S. А можете в комментариях поделиться собственным опытом реплатформинга? Как пережили, что утратили и обрели? Будет любопытно сравнить размер грабель и шишек.