6 шагов, как перевести e-commerce платформу с монолита на микросервисы
Уход таких популярных у онлайн-ритейлеров западных вендоров, как SAP и Oracle, заставляет компании искать замену их решениям. Перед многими встаёт вопрос: «Как провести импортозамещение без заморозки бизнес-процессов и с сохранением темпов развития?» Одно из наиболее современных и оптимальных решений — переход на микросервисную архитектуру. Сергей Кунцевич, CTO Digital Chief, рассказывает, как это сделать правильно и эффективно.
Импортозамещение — не причина отказа, а внешний фактор, ускоряющий принятие решения о переходе с монолита на микросервисную архитектуру. Важно определиться с реальной внутренней потребностью бизнеса, чтобы корректно планировать свои дальнейшие действия и расставлять акценты. Основных предпосылок для отказа от монолита три:
- Стоимость сопровождения и модернизации. В сфере
e-commerce предъявляются повышенные требования к производительности и масштабируемости
системы. Производительность — один из ключевых технологических атрибутов,
определяющий успешность продаж, коэффициент конверсий и т. д. Монолит, особенно
устаревший, содержит множество накопленного технического долга и взаимосвязанного
легаси-кода, который сложно изменять, развивать и масштабировать. Такую систему тяжело,
дорого и иногда невозможно модернизировать для соответствия современным требованиям по
производительности.
- Time to market (TTM) и стоимость новой функциональности.
Чтобысоответствовать ожиданиям цифрового клиента, необходимо постоянно
внедрять новую бизнес-функциональность. Однако монолит — это
большой блок глубоко взаимосвязанного кода, за годы работы обросший множеством временных
решений («костылей»). Они загрязняют систему и делают добавление новых
сервисов и функций крайне долгим и дорогим (а то и невозможным) из-за опасности
«сломать» что-то глубоко внутри монолита и из-за необходимости
проводить обширное тестирование.
- Дефицит кадров, стоимость обучения
специалистов. Монолит — закрытое решение конкретного
вендора, навыки работы с подобными системами — дорогая и
редкая компетенция, а таких специалистов (и ранее представленных не очень широко) на рынке
становится всё меньше. При этом у компаний, как правило, нет возможности и знаний для
организации собственных программ подготовки кандидатов с базовым набором навыков для
работы с конкретным монолитным решением. Кроме того, такие программы обходятся дорого,
поскольку они требуют времени (как правило, до года), в течение которого новый сотрудник
не приносит ценности.
Шаг 1. Выберите, где развернуть микросервисное решение
Выбор между разворачиванием решения в облаке или на собственных мощностях (внутренний ИТ-контур компании или аренда сервера в ЦОД) диктуется совокупной стоимостью владения (Total Cost of Ownership, TCO), профилем компании, особенностями её бизнеса и потребностью в инфраструктуре. В общем случае собственные мощности обойдутся в меньшую сумму, их стоит выбирать, если у компании нет потребности в гибкости. Использование облачной инфраструктуры необходимо в трёх случаях:
- Сезонность спроса и цикличность нагрузки. Если бизнес имеет какие-то цикличные ритмы, нагрузка на серверы может кратно возрастать и падать в зависимости от сезона (например, в связи с возрастающей покупательской активностью при приближении определённых дат), стоит использовать публичное или гибридное облако. Важно, чтобы провайдер облачного решения предоставлял возможность быстрого наращивания инфраструктуры и быстрого её сокращения, чтобы бизнес платил только за ту мощность, которая потребна в моменте.
Цикличность спроса привела к созданию Amazon Web Services (AWS). Компания Amazon, один из крупнейших e-commerce маркетплейсов, использовала в розничном бизнесе собственную инфраструктуру, обладавшую достаточной мощностью для бессбойной работы в высокий сезон. Однако в остальное время более 80% этой инфраструктуры простаивало. Менеджмент предложил сдавать неиспользуемые мощности внешним клиентам, что в дальнейшем изменило ландшафт ИТ-услуг во всём мире, заставив множество компаний отказаться от закупки и поддержки собственных серверов в пользу аренды гибких облачных мощностей.
- Отсутствие внутренней экспертизы по администрированию инфраструктуры. Собственные или арендованные в ЦОД серверы требуют квалифицированного управления, настройки, формирования сервисов. Как правило, такая экспертиза есть в больших компаниях с парком из тысяч серверов. Если её нет, целесообразнее подписаться на услуги облачного провайдера. Большинство вопросов по настройке инфраструктуры и сервисов возьмут на себя его специалисты, а бизнес получит необходимый объём мощностей.
- Высокая гибкость бизнеса, частые изменения и эксперименты. Если запросы бизнеса нестабильны, разные команды постоянно тестируют гипотезы, поднимают на серверах R&D и пилотные проекты, запускают PoC и MVP версии сервисов, облачная инфраструктура окажется эффективнее. В ней можно резервировать и освобождать мощности в соответствии с текущими потребностями, что позволяет не ограничивать себя в количестве и масштабах экспериментов и не закупать под них специальное оборудование.
Организация сервисов не отличается при использовании облачных решений и
собственных мощностей. На собственных или арендованных серверах также можно развернуть
облако, использовать общую инфраструктуру для внешних и внутренних
проектов.
Шаг 2. Используйте стратегию инкрементального перехода
Практика показывает, что одномоментный большой переход с монолита на микросервисы (так называемая стратегия биг бэнга) всегда рискован, долог, трудоёмок и затратен. Чем дольше эксплуатировался монолит, тем больше в нём накоплено логики, нюансов, специфических решений. Всю эту функциональность необходимо воспроизвести на новой платформе в полном объёме, и её перенос потребует очень много времени и ресурсов. Бизнес не может остановить своё развитие на время трансформации, особенно если переход выполняется ради быстрого внедрения востребованных рынком функций.
Оптимальная стратегия — инкрементальная замена функциональности, посервисная миграция с использованием шлюзов (гейтвеев) для перехвата логики работы монолита по мере написания микросервисов той или иной бизнес-функции. Такой подход подразумевает одновременную работу нового и старого кода: какая-то часть или вся функция работает в микросервисе, а ещё не переписанные части и соседние функции продолжают выполняться в старом монолите. Это позволяет начать использовать преимущества микросервисной архитектуры с самого старта перехода, быстро внедрять новую необходимую функциональность, не теряя работоспособности всей системы, эффективно верифицировать и корректировать ошибки, избегать рисков и управлять затратами.
Одновременно с этим часть функций, не требующая модернизации и
изменений, может оставаться в монолите сколько угодно долго и не требовать вложений, пока
не возникнет объективная потребность в том, чтобы внести изменения конкретно в эти
бизнес-процессы.
Шаг 3. Подготовьтесь к переходу
- Коммуникации: синхронизируйте план технологической
модернизации с планом по выводу новой бизнес-функциональности. В противном случае
возникают ситуации, когда специалисты заняты переносом в микросервисы существующей логики,
а не срочно необходимых бизнесу новых функций. Как следствие, эти новые сервисы
реализуются «костылями» на старой платформе, что ведёт к двойной
работе и трате двойного бюджета. Необходимо чётко понимать, сколько времени займёт тот или
иной перенос или разработка новых функций, что именно критично для бизнеса в каждый момент
времени, и адаптировать планы под эти возможности и потребности.
- Приоритеты: определите
бизнес-процессы и функциональность, наиболее нуждающиеся в
модернизации, из-за нахождения которых в старой системе бизнес несёт убытки. Начинать
переход необходимо не с того, что удобно или «логично» перенести
первым, а с тех частей системы, для которых наиболее высока стоимость задержки (cost of
delay).
- Компетенции: убедитесь, что команда, которая будет
осуществлять модернизацию, обладает необходимыми компетенциями для быстрой работы с новым
стеком, обратной связью, облачными технологиями и т. д. У людей,
которые в предыдущие годы сопровождали монолит, нет соответствующих компетенций и опыта;
скорее всего, разрабатывать микросервисное решение они будут, как привыкли: с
трёхнедельными регрессами, с релизами раз в полгода. Это противоречит идеологии
микросервисов и нивелирует их преимущества для бизнеса. При отсутствии нужных компетенций,
возможно, стоит организовать обучение специалистов или привлечь внешнюю команду
профессионалов.
Шаг 4. Решите архитектурно-технологические задачи перехода
- Разработка базиса для работы и интеграции. Процессы
сборки, работы с кодом, верификации, поставки кода; разработка
окружения и DevOps-платформы. В идеале новые релизы должны разворачиваться максимально
быстро, по нажатию кнопки.
- Определение и разработка интерфейсов интеграции
микросервисов. Должны быть подготовлены контракты и форматы, согласно
которым системы, сервисы, потребители сервисов передают и получают информацию, что
позволяет её стандартизировать. Таким образом обеспечивается плавный переезд и поддержка
обратной совместимости. Для синхронной интеграции должен быть подготовлен API-слой
(REST/GRPC), для асинхронной, если она требуется,
современный туннель, брокер передачи информации (Kafka,
RabbitMQ, NATS).
Шаг 5. Переносите бизнес-функции в правильной последовательности
В первую очередь из монолита в микросервисы должна быть вынесена самая высоконагруженная функциональность, поскольку именно она, скорее всего, представляет собой слабое звено старой системы, не справляющееся с современными нагрузками. Конкретная последовательность определяется потребностями бизнеса, но в первую очередь следует обратить внимание на следующие сервисы:
- Логистика: остатки, склады, способы доставок,
логистические калькуляторы и т. д. В последние годы сильно выросли
требования рынка к скорости, точности и вариативности доставки. Из-за сильно
увеличившегося объёма информации выросла нагрузка на эту часть бизнес-логики, в ней стали
более востребованы возможности быстрых изменений.
- Ценообразование: цены, скидочные и акционные
механики, купоны, программы лояльности, баллы и т.
д. В современных решениях практически не применяется ценообразование в
Excel из-за сильно возросших запросов к расчёту цены и необходимого для
него объёма данных. Рынок требует постоянного изменения и развития этих сервисов. Кроме
того, важно сокращение TTM (time to market) для информации, она должна
передаваться между различными частями системы максимально быстро. Например, информация о
покупке товара в розничном магазине, если он же доступен в онлайн,
должна немедленно передаваться в соответствующий сервис, чтобы были обновлены товарные
остатки и клиент не мог приобрести отсутствующую позицию. К скорости движения информации
сейчас предъявляются максимально высокие требования.
- Поиск. Обычно реализуется в виде отдельного
микросервиса, поскольку эффективный поиск — залог успеха современной e-commerce
платформы и служит важным конкурентным преимуществом для усиления продаж. Сервис должен на
основе текстового запроса на естественном языке и знаний системы о клиенте предложить ему
то, что он действительно ищет, и не заставлять покупателя тратить своё время, перебирая
товары в каталоге. Поиск — развивающаяся сфера, место, где происходят постоянные
изменения и тестирование гипотез: подсказки, генеративные модели, фильтры, атрибутивная
информация и т. д. Его не так сложно внедрить в микросервисной архитектуре, а проявит себя
он быстро — и в конверсиях, и в эффективности аналитики.
- Клиентский контент (UGC). Продуктовый каталог с отзывами, видео и фотографиями от клиентов очень востребован современным цифровымпотребителем. Это конверсионная функциональность, её важно быстро наращивать и проверять гипотезы.
Продуманная стратегия перехода позволила провести трансформацию e-commerce платформы сети магазинов одного из крупнейших российских бьюти-ритейлеров без критичных ошибок. Запланированная последовательность действий включала:
- Подготовку ландшафта CI/CD, формирование DevOps-экспертизы, организацию работы с облачной инфраструктурой для быстрого развёртывания микросервисов.
- Разработку API, промежуточного API-шлюза для интеграции с монолитом, внедрение Kafka в качестве брокера сообщений для быстрой передачи большого объёма информации между старым и новым решениями.
- Перенос микросервисов: остатки, цены, пользовательский контент, поиск и поисковые подсказки.
Разработка плана и следование ему позволили быстро масштабировать
систему под рост бизнеса, происходивший одновременно с превращением онлайн-магазина в
бьюти-маркетплейс.
Шаг 6. Избегайте распространённых ошибок
Жёсткие сроки перехода. Не нужно ставить перед собой амбициозные цели по срокам. Такая стратегия обычно приводит к попыткам нагнать график путём реализации «костылей», сильно осложняющих дальнейшую эксплуатацию и развитие нового микросервисного решения. Важно помнить, что во время трансформации бизнес продолжает развиваться, могут возникать новые срочные задачи для разработки с более высоким приоритетом. Необходимо определить стратегию и фокус внимания, найти наиболее проблемные участки старого решения, которые требуют замены или масштабирования в первую очередь. Некритичные же участки, чья эффективность в монолите устраивает бизнес, могут оставаться в нём достаточно долго; не стоит пытаться перенести их любой ценой к обозначенной дате.
Отсутствие координации между командами. В случаях, когда разработкой нового решения и поддержкой старого занимаются разные команды со слабой синхронизацией между собой, возникает ситуация, когда новое вынуждено постоянно догонять старое. Это связано с тем, что команда поддержки реализует на монолите необходимую бизнесу новую функциональность, и лишь потом эти функции переносятся в микросервисную платформу. В результате из-за задержки выхода нового решения на рынок теряются инвестиции, поскольку не используются новые технологические возможности. Необходимо максимально быстро запускать микросервисную платформу, использующую API-шлюзы для перехвата логики монолита, и реализовывать новую функциональность именно на ней, синхронизируя работу между двумя командами.
Чрезмерное разнообразие технологического стека. Существует множество технологий для реализации микросервисной архитектуры (PHP, Java, Go, .NET и т. д.), множество источников данных и систем управления базами данных (PostgreSQL, Oracle, MS, Mongo и т. д.). У каждой технологии и БД есть свои преимущества, что создаёт соблазн использовать их для реализации конкретных функций, в результате чего формируется большой «зоопарк» технологически разных микросервисов, дорогой в обслуживании и поддержке. Лучше сразу унифицировать стек технологий и соблюдать единство архитектуры. Если у вас есть две базы — SQL и NoSQL, надо ещё на этапе планирования определиться, какие конкретно решения будут использоваться.
Недостаточная поддержка здоровья системы. Часто компании забывают про мониторинг, алертинг, логирование, дублирование, систему эксплуатации и прочие инструменты для поддержания работоспособности платформы. Например, при организации развёртывания в режиме высокой доступности важно, чтобы ваш облачный сервер или микросервис дублировался в рамках кластера на случай падения, либо чтобы в случае сбоя автоматически поднималась резервная копия. Во многом упущения в части поддержки доступности и обработки ошибок происходят из-за отсутствия опыта внедрения крупных решений. К сожалению, пока что специалистов с успешным опытом миграции с монолита на микросервисы на рынке немного, потребность в них только начинает формироваться.
Тем не менее надо учитывать, что микросервисная архитектура требует стратегического подхода и соответствующего управления. Вопросы эксплуатации, мониторинга и модернизации в ней решаются быстрее и безопаснее, чем в случае монолита, но они также есть, и им необходимо уделять внимание.
заявка на сотрудничество
Хотите обсудить возможности по внедрению ecom-платформы?
Или получить консультацию с оценкой и анализом текущего технологического ландшафта вашего бизнеса?