Редизайн интернет-магазина планировали сделать за полгода — растянулся на полтора. Или так: вышли на новый рынок и потребовалось подключить нового партнёра по доставке — оказалось, что на это нужно не две недели, а квартал. Симптомы разные, причина одна.

Меня зовут Павел Седаков, я директор и сооснователь «Оджетто». 18 лет наша компания занимается eCommerce, и все эти годы мы работаем прицельно с энтерпрайз-сегментом. В этой статье я расскажу, почему проекты идут не по плану и как Composable Commerce может это поменять. Заодно покажу, как это выглядит в реальной сборке: что за платформа появилась у нас и почему именно такая.

Как мы сами до этого дошли

Мы с 2011 года — первые в СНГ сертифицированные партнёры Magento. К 2022 году уже больше десяти лет плотно работали с этой платформой и сделали много проектов. Чаще всего это был Adobe Commerce, платная версия (после того как Magento купил Adobe), но иногда — Magento Open Source. Тогда это было нашим осознанным выбором: зрелая платформа, огромная функциональность из коробки, понятная лицензия, подходит энтерпрайзу.

Причём часть проектов мы уже делали по новой для нас на тот момент схеме: бэкенд на Adobe Commerce/Magento, фронт на Vue или React, по сути headless. Так мы и шли к composable, и возможно, пришли бы туда в любом случае, но в 2022 году, когда зарубежные вендоры ушли и платить за лицензию Adobe стало просто некому, пришлось резко ускориться. Не эволюционно, а вынужденно и сразу.

Если посмотреть на отечественный рынок решений для eCommerce, можно найти несколько SaaS-решений для совсем небольших магазинов и отечественный 1С-Битрикс, архитектура которого кажется нам сомнительной и с которым связываться не хотелось. Плюс появлялись какие-то фреймворки и платформы, куда нас звали становиться интеграторами, но на деле это было DevOps-окружение без готовой функциональности под капотом, а дальше нужно было долго и дорого писать всё кастомно. Именно тогда стало окончательно очевидно, что будем строить composable-решение. Открытая Magento остаётся тем же мощным ядром. Но мы хорошо знали, что community-версия хороша не во всём, поэтому часть задач, которые раньше решались внутри монолита, будем закрывать отдельным специализированным продуктом.

Почему монолит перестаёт справляться

Я видел разные мнения о том, насколько вообще оправдан монолит, и соглашусь: для части проектов это действительно хорошее решение. Всё необходимое уже есть внутри — каталог товаров, корзина, оформление заказа, управление контентом, программа лояльности, аналитика. Запускаешься быстро, платишь за одно решение, команда работает в одной системе. Для старта — отлично. Проблемы возникают позже: когда бизнес начинает расти, каждая из этих подсистем рано или поздно упирается в потолок. Команда всерьёз берётся за управление товарным каталогом и понимает, что встроенный PIM не тянет: не хватает атрибутов, нет нормальной локализации, невозможно управлять тысячами SKU без боли. Берётся за персонализацию и маркетинговую автоматизацию — встроенные инструменты дают базовые сегменты и простые триггеры, а нужно совсем другое. То же самое с поиском, с управлением доставками, с контентом.

Дело в том, что каждый из этих блоков внутри монолита — это baby-software. Это не про низкое качество: каталог, программа лояльности, поиск внутри монолита изначально не проектировались как отдельные продукты — они часть общего целого, которое должно закрыть сразу все сценарии. Поэтому каждый умеет ровно то, что нужно для старта, и не более: стандартные атрибуты, простую логику, базовые сегменты. Дальше начинается зона, где типового решения недостаточно, не потому что что-то плохо спроектировали, а потому что оно для этого не строилось. Тысячи SKU с уникальными атрибутами и мультиязычностью упираются в PIM, который умел вести сотни. Продвинутая персонализация — с динамическими сегментами и многошаговыми сценариями — упирается во встроенный маркетинговый модуль, который умел делать пару сегментов и триггер по брошенной корзине. Достаточно, чтобы начать. Недостаточно, чтобы выигрывать.

Что такое composable

Composable commerce — это архитектурный подход, при котором вместо одной платформы «всё в одном» вы собираете систему из лучших специализированных продуктов. Каждый отвечает за свою задачу. Каждый делает её хорошо.

Повторюсь, но это стоит явно зафиксировать: вся логика composable строится ровно на том наблюдении, о котором я говорил выше. Раз каждый блок монолита — это baby-software, значит для каждого блока существует продукт, который решает ту же задачу кратно лучше. Не чуть-чуть лучше — принципиально иначе. PIM-системы годами создавались только для того, чтобы управлять товарным каталогом: тысячи атрибутов, сложные иерархии, мультиязычность, синдикация на маркетплейсы, и больше ничего. CDP-платформы всю свою экспертизу сосредоточили в одном — маркетинговой автоматизации и персонализации. А поисковые движки строились специально для eCommerce: с пониманием синонимов, векторным поиском, управлением релевантностью. Ни один универсальный монолит не может конкурировать с таким фокусом.

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

Именно поэтому подход называется composable — от английского compose, «собирать». Вы не используете монолит и не покупаете готовый пакет. Вы собираете систему из частей, осознанно выбирая каждую. Где-то это зрелый продукт с рынка, где-то — собственная разработка под уникальную бизнес-логику. Главное, что эти части не зависят друг от друга: если завтра появится инструмент лучше, вы меняете один блок и не трогаете всё остальное. У нас так вышло с PIM: для типового проекта хватает Akeneo, но если по входящим требованиям конкретному заказчику лучше подходит Pimcore — берём его, не трогая всё остальное вокруг. Это независимость компонентов не в теории, а в том, как мы сами работаем.

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

Как это выглядит на практике

Представьте типичную картину: компания выросла, и внутри уже не один человек, который «занимается сайтом», а маркетинг, операции, аналитики, иногда отдельная команда под мобильное приложение — у каждого свои задачи и свой темп, но все работают в одном бэклоге и конкурируют за время разработки. Условно: маркетологу нужно запустить распродажу к празднику, бэкенду — проверить систему под нагрузкой, памятуя прошлогодний факап, мобильной команде нужно выпустить релиз, а аналитикам — прогнать A/B-тесты. Все четыре задачи одинаково важны и упираются в одну и ту же очередь.

В composable-архитектуре у каждой команды свой инструмент, и очередь исчезает: контент-менеджер заводит коллекцию в PIM, маркетологи настраивают цепочки касаний в CDP, нетоварный контент — баннеры, лендинги под акцию — собирают сами в CMS и выпускают без разработчиков, а разработчики в этот момент заняты нагрузочным тестированием. Не абстрактно «стало быстрее» — а конкретно: каждое направление бизнеса двигается в своём ритме, без зависимостей от коллег.

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

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

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

Что мы в итоге собрали и почему

Расскажу, что у нас получилось в итоге — мы собрали платформу, конкретную архитектурную основу, и назвали её Primo Commerce. Не потому что на рынке совсем ничего нет, а потому что нормальной альтернативы для enterprise-сегмента так и не появилось.

В основе — тот самый открытый Magento, о котором я уже рассказывал. Каталог — Akeneo. Здесь хорошо видно, зачем вообще нужен отдельный PIM: один и тот же атрибут товара расползается на разные варианты написания при импорте из 1С, ERP и Excel, а под каждый канал продаж и рынок нужны свои форматы и картинки.

Контент — Payload CMS. Взяли его за code-first подход (структура контента в коде, не в GUI), блочный редактор, которым маркетологи пользуются сами без разработчиков, live preview и историю версий с откатом. Плюс то, что это open source на MIT-лицензии — без ежемесячных платежей и без зависимости от вендора.

Единственное исключение из принципа open source — Mindbox, для CDP и лояльности. Решений такого уровня в открытом доступе просто нет, и мы интегрируемся с Mindbox на 90% проектов, с уже готовой интеграцией под капотом. Это решение платное, по подписке, со своими тарифами.

Ну и обвязка, которая держит всё вместе: RabbitMQ для очередей сообщений между компонентами, Keycloak для авторизации и ролей, OpenSearch под поиск, KrakenD как API Gateway, который сводит отдельные сервисы в единый вход для фронтенда.

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

Причём мы не продаём это как лицензию — клиент платит за внедрение, за нашу работу по интеграции с существующим ИТ-ландшафтом, требуемой кастомизации под бизнес-процессы клиента, сборке и настройке всех этих компонентов под конкретный проект. А то, что получается на выходе, кроме Mindbox — целиком на open source, и дальше с этим может работать любая команда, не обязательно наша.

Три вопроса о важном

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

Есть ли у вас команда, которая занимается eCommerce профессионально?

Не один человек, который «отвечает за сайт» и ещё десяток других вещей, а выделенные люди с фокусом: маркетинг, операции, merchandising, аналитика. Composable-система — это набор мощных инструментов. Чтобы они раскрылись, нужны люди, которые умеют с ними работать и готовы в них расти. Если команды пока нет — возможно, рано. Если есть или вы её строите — это первый сигнал.

Есть ли у вас профессиональные амбиции по конкретным направлениям?

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

Надёжность и масштаб системы уже мешают бизнесу?

Не «иногда бывают проблемы», а реально тормозят. Высокие нагрузки роняют систему. Каждый релиз — это риск. Команда разработки больше чинит, чем строит. Если вы узнаёте здесь себя — это третий и самый острый сигнал. Архитектурный долг не рассасывается сам по себе, он только растёт.

Если вы ответили «да» хотя бы на два из трёх — composable-подход стоит рассматривать всерьёз.

Резюмируя

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

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

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

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

Расскажите в комментариях: был ли у вас опыт создания с нуля или реплатформинга, и какие ограничения проявлялись первыми?