Composable Commerce. Сверка терминологии

Привет! На связи «Оджетто», мы 15 лет делаем большие интернет-магазины и в этой статье хотим поговорить о популярном ныне термине в электронной коммерции. Но предупреждаем сразу: в этой статье не идет речи о каких-то инновациях или новых подходах к разработке ПО, ведь SOA и микросервисы были придуманы десятки лет назад. Перед нами стояла другая задача: на русском языке в Сети очень мало материалов по этой теме, а в некоторых головах и источниках полная каша из хедлесс, PWA, микросервисов и компоузабл. Мы попытались систематизировать те знания, данные и опыт, который есть у нас. Кто больше любит смотреть, чем читать, то вот ссылка для вас.

Итак, какое-то время назад, большинство еком-решений разрабатывались монолитно, где бэкенд – слои данных и логики были неразрывно связаны с фронтендом – презентационным слоем. Так было и у нас, в качестве монолита выступала платформа Мадженто.

Решение из коробки обладало обширной функциональностью и охватывало большинство требований. Готовые платформы и по сей день – прекрасная возможность для старта MVP с минимальным time to market и TCO (Total Cost of Ownership).

Первым этапом разбиения монолита на части стал headless-подход – теперь не обязательно использовать фронтенд, предлагаемый платформой (в нашем случае это был Knockout.js), а вместо него можно взять какой-то более «модный» фреймворк. Так в нашем стеке появились GraphQL, Vue и React.

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

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

Четкого определения PWA нет, но есть философия и архитектура. Можно сказать, что PWA – это веб-приложение, созданное с использованием определенных технологий (service worker, web app manifest, app shell, push notifications) для достижения заданных целевых показателей: быстроты, надежности и привлекательности (fast, reliable & engaging).

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

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

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

Так возникла парадигма Composable Commerce, в основе которой модульные компоненты (Packaged Business Capabilities) — это элементы системы, которые можно независимо заменить, усовершенствовать и масштабировать. Они могут состоять из одного или нескольких микросервисов, которые объединены общей бизнес-задачей. В этом подходе получается использовать лучшие решения на рынке для каждой бизнес-задачи. Например, если мы переросли «коробочные» возможности управления информацией о товаре, то мы просто добавляем ко всему решению отдельный PIM, например Brandquad. Если не удовлетворяют штатные возможности по управлению контентом (как, например, в Magento Open Source), то мы интегрируем в свою систему Contentful, например.

Composable Commerce строится на трех принципах:

– Модульность – каждый модуль разрабатывается отдельно и независимо, деплоится автономно, легко заменяем и масштабируем. При этом eCom Core может быть одним из модулей, наряду с CMS и прочим.

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

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

Покажем полезность этого подхода на примере компании, которая запустила свою электронную коммерцию на Magento. С самого начала было понятно, что возможности платформы по ведению остатков ограничены, а в компании уже был SAP, поэтому сразу интегрировали его в систему. Позже, по ряду причин, бизнес принял решение вести учет остатков для екома отдельно и выбрал для этого 1С, мы быстро поменяли WMS.

Сложнее был вызов по управлению планированием доставки, так как частично прибегали к использованию 3pl, а в части заказов за последнюю милю отвечал сам клиент магазина. Продукта, который правильно автоматизировал бы эти процессы, на рынке пока не существует в принципе. Поэтому решили задачу написанием микросервиса на Go. Другим сервисом, но уже на .net core, решили проблемы с расчетом финальной цены, когда появилась сложная лояльность.

Часто, когда у магазина большой каталог, возникают проблемы с поиском. И достаточно распространенным решением является Anyquery, который отлично с этим справляется. При этом сам каталог быстро и надежно работает на Elastic. Апселл и персонализацию отлично делает Retail Rocket. Мы интегрировались с этой троицей, но при всем при этом, если на рынке появится решение лучше – любую из них можно быстро поменять.

Вот что такое Composable Commerce на примере.

Параллельно с бизнесцентричным подходом Composable Commerce, в последнее время активно развивается MACH (Микросервисы, API, Cloud first & Headless) – технологический подход к разработке программного обеспечения, который ориентирован на достижения целей composable, но не является технически единственным способом построения компонентной архитектуры. Появился даже MACH-альянс, который ставит своей целью объединить компании, проповедующие одну философию и сервис, отвечающий принципам MACH.

На самом деле, любое сочетание архитектур при «распиливании» монолита можно считать Composable хотя, безусловно, MACH-альянс – это дело полезное и проповедуют они правильный подход.

Спасибо, что дочитали. Если в чем-то не согласны, дополните или подискутируйте с нами в комментариях.