30 Января 2024 10:00 30 Янв 2024 10:00 |

Поделиться

6 шагов, как перевести e-commerce платформу с монолита на микросервисы

Digital Chief — ИТ-компания, специализирующаяся на е-commerce разработке полного цикла. В 2023 году она представила на рынок российское микросервисное headless решение нового поколения по управлению электронной коммерцией для крупного бизнеса — DC Commerce. Оно может заменить западные платформы — такие как SAP Hybris, Magento (Adobe Commerce) и Oracle ATG Commerce.

Специалисты Digital Chief имеют более 20 лет опыта автоматизации систем электронной коммерции и реализации масштабных проектов для таких компаний, как «Барьер», «Теле2», «М.Видео», «Еврохим», «Северсталь», «Л’Этуаль», Castorama, SEPHORA и многих других.

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

1. Стоимость сопровождения и модернизации. В сфере e-commerce предъявляются повышенные требования к производительности и масштабируемости системы. Производительность — один из ключевых технологических атрибутов, определяющий успешность продаж, коэффициент конверсий и т. д. Монолит, особенно устаревший, содержит множество накопленного технического долга и взаимосвязанного легаси-кода, который сложно изменять, развивать и масштабировать. Такую систему тяжело, дорого и иногда невозможно модернизировать для соответствия современным требованиям по производительности.
2. Time to market (TTM) и стоимость новой функциональности. Чтобы соответствовать ожиданиям цифрового клиента, необходимо постоянно внедрять новую бизнес-функциональность. Однако монолит — это большой блок глубоко взаимосвязанного кода, за годы работы обросший множеством временных решений («костылей»). Они загрязняют систему и делают добавление новых сервисов и функций крайне долгим и дорогим (а то и невозможным) из-за опасности «сломать» что-то глубоко внутри монолита и из-за необходимости проводить обширное тестирование.
3. Дефицит кадров, стоимость обучения специалистов. Монолит — закрытое решение конкретного вендора, навыки работы с подобными системами — дорогая и редкая компетенция, а таких специалистов (и ранее представленных не очень широко) на рынке становится всё меньше. При этом у компаний, как правило, нет возможности и знаний для организации собственных программ подготовки кандидатов с базовым набором навыков для работы с конкретным монолитным решением. Кроме того, такие программы обходятся дорого, поскольку они требуют времени (как правило, до года), в течение которого новый сотрудник не приносит ценности.

Шаг 1. Выберите, где развернуть микросервисное решение

Выбор между разворачиванием решения в облаке или на собственных мощностях (внутренний ИТ-контур компании или аренда сервера в ЦОД) диктуется совокупной стоимостью владения (Total Cost of Ownership, TCO), профилем компании, особенностями её бизнеса и потребностью в инфраструктуре. В общем случае собственные мощности обойдутся в меньшую сумму, их стоит выбирать, если у компании нет потребности в гибкости. Использование облачной инфраструктуры необходимо в трёх случаях:

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

• Отсутствие внутренней экспертизы по администрированию инфраструктуры. Собственные или арендованные в ЦОД серверы требуют квалифицированного управления, настройки, формирования сервисов. Как правило, такая экспертиза есть в больших компаниях с парком из тысяч серверов. Если её нет, целесообразнее подписаться на услуги облачного провайдера. Большинство вопросов по настройке инфраструктуры и сервисов возьмут на себя его специалисты, а бизнес получит необходимый объём мощностей.
• Высокая гибкость бизнеса, частые изменения и эксперименты. Если запросы бизнеса нестабильны, разные команды постоянно тестируют гипотезы, поднимают на серверах R&D и пилотные проекты, запускают PoC и MVP версии сервисов, облачная инфраструктура окажется эффективнее. В ней можно резервировать и освобождать мощности в соответствии с текущими потребностями, что позволяет не ограничивать себя в количестве и масштабах экспериментов и не закупать под них специальное оборудование.

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

Шаг 2. Используйте стратегию инкрементального перехода

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

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

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

Шаг 3. Подготовьтесь к переходу

1. Коммуникации: синхронизируйте план технологической модернизации с планом по выводу новой бизнес-функциональности. В противном случае возникают ситуации, когда специалисты заняты переносом в микросервисы существующей логики, а не срочно необходимых бизнесу новых функций. Как следствие, эти новые сервисы реализуются «костылями» на старой платформе, что ведёт к двойной работе и трате двойного бюджета. Необходимо чётко понимать, сколько времени займёт тот или иной перенос или разработка новых функций, что именно критично для бизнеса в каждый момент времени, и адаптировать планы под эти возможности и потребности.
2. Приоритеты: определите бизнес-процессы и функциональность, наиболее нуждающиеся в модернизации, из-за нахождения которых в старой системе бизнес несёт убытки. Начинать переход необходимо не с того, что удобно или «логично» перенести первым, а с тех частей системы, для которых наиболее высока стоимость задержки (cost of delay).
3. Компетенции: убедитесь, что команда, которая будет осуществлять модернизацию, обладает необходимыми компетенциями для быстрой работы с новым стеком, обратной связью, облачными технологиями и т. д. У людей, которые в предыдущие годы сопровождали монолит, нет соответствующих компетенций и опыта; скорее всего, разрабатывать микросервисное решение они будут, как привыкли: с трёхнедельными регрессами, с релизами раз в полгода. Это противоречит идеологии микросервисов и нивелирует их преимущества для бизнеса. При отсутствии нужных компетенций, возможно, стоит организовать обучение специалистов или привлечь внешнюю команду профессионалов.

Шаг 4. Решите архитектурно-технологические задачи перехода

1. Разработка базиса для работы и интеграции. Процессы сборки, работы с кодом, верификации, поставки кода; разработка окружения и DevOps-платформы. В идеале новые релизы должны разворачиваться максимально быстро, по нажатию кнопки.
2. Определение и разработка интерфейсов интеграции микросервисов. Должны быть подготовлены контракты и форматы, согласно которым системы, сервисы, потребители сервисов передают и получают информацию, что позволяет её стандартизировать. Таким образом обеспечивается плавный переезд и поддержка обратной совместимости. Для синхронной интеграции должен быть подготовлен API-слой (REST/GRPC), для асинхронной, если она требуется, современный туннель, брокер передачи информации (Kafka, RabbitMQ, NATS).

Шаг 5. Переносите бизнес-функции в правильной последовательности

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

1. Логистика: остатки, склады, способы доставок, логистические калькуляторы и т. д. В последние годы сильно выросли требования рынка к скорости, точности и вариативности доставки. Из-за сильно увеличившегося объёма информации выросла нагрузка на эту часть бизнес-логики, в ней стали более востребованы возможности быстрых изменений.
2. Ценообразование: цены, скидочные и акционные механики, купоны, программы лояльности, баллы и т. д. В современных решениях практически не применяется ценообразование в Excel из-за сильно возросших запросов к расчёту цены и необходимого для него объёма данных. Рынок требует постоянного изменения и развития этих сервисов. Кроме того, важно сокращение TTM (time to market) для информации, она должна передаваться между различными частями системы максимально быстро. Например, информация о покупке товара в розничном магазине, если он же доступен в онлайн, должна немедленно передаваться в соответствующий сервис, чтобы были обновлены товарные остатки и клиент не мог приобрести отсутствующую позицию. К скорости движения информации сейчас предъявляются максимально высокие требования.
3. Поиск. Обычно реализуется в виде отдельного микросервиса, поскольку эффективный поиск — залог успеха современной e-commerce платформы и служит важным конкурентным преимуществом для усиления продаж. Сервис должен на основе текстового запроса на естественном языке и знаний системы о клиенте предложить ему то, что он действительно ищет, и не заставлять покупателя тратить своё время, перебирая товары в каталоге. Поиск — развивающаяся сфера, место, где происходят постоянные изменения и тестирование гипотез: подсказки, генеративные модели, фильтры, атрибутивная информация и т. д. Его не так сложно внедрить в микросервисной архитектуре, а проявит себя он быстро — и в конверсиях, и в эффективности аналитики.
4. Клиентский контент (UGC). Продуктовый каталог с отзывами, видео и фотографиями от клиентов очень востребован современным цифровым потребителем. Это конверсионная функциональность, её важно быстро наращивать и проверять гипотезы.

Шаг 6. Избегайте распространённых ошибок

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

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

Чрезмерное разнообразие технологического стека. Существует множество технологий для реализации микросервисной архитектуры (PHP, Java, Go, .NET и т. д.), множество источников данных и систем управления базами данных (PostgreSQL, Oracle, MS, Mongo и т. д.). У каждой технологии и БД есть свои преимущества, что создаёт соблазн использовать их для реализации конкретных функций, в результате чего формируется большой «зоопарк» технологически разных микросервисов, дорогой в обслуживании и поддержке. Лучше сразу унифицировать стек технологий и соблюдать единство архитектуры. Если у вас есть две базы — SQL и NoSQL, надо ещё на этапе планирования определиться, какие конкретно решения будут использоваться.

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

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

Краткая биография

Сергей Кунцевич

• Технический директор компании Digital Chief, разработчик и интегратор решений для e-commerce.
• Обладает двадцатилетним опытом работы на ИТ-рынке, более 13 лет руководит запуском и развитием масштабных технологических проектов как на стороне заказчика, так и в консалтинге.
• Управляет разработкой и внедрением e-commerce решений для крупных российских и международных компаний.
• В 2023 году под брендом Digital Chief разработал и запустил собственную платформу – DC Commerce.

подробнее

Поделиться

Подписаться на новости Короткая ссылка