Composable в ecommerce: от коробки к интеграторам
Я в ecommerce 14 лет и видел путь от коробки на Битриксе до проектов-осьминогов, где внутри всё на go. Сейчас рынок уходит в composable — это не монолит и не микросервисы, а набор систем с готовыми бизнес-функциями (PBC). Рассказываю, почему заказной разработки станет меньше.
Когда я только начинал заниматься ecommerce, а это 14 лет назад. Считалось нормальным развернуть коробку для интернет-магазина, которая плавно дописывалась.
Пожалуй только у гигантов было иначе. Хотя тот же Эльдорадо, Hoff и некоторые другие запускались на Битриксе. Нагрузки были маленькие. Рынки не такие конкурентные. Правила игры проще.
В целом покупатели воспринимали покупки в интернете, как место «тут подешевле, но ждать долго, лучше сходим в магазин».
Как ecommerce пришёл к composable
Потом ковид, рост онлайн-торговли. Адаптация под кратные росты нагрузки. Куча заказной разработки, чтобы совсем этим справится. Проекты-осьминоги, где снаружи Битрикс, а внутри всё на go.
Рынок стал более денежным и консолидированным. Много выставок, специализированых медиа, инфраструктурных игроков (DataInsight, Ecom Expo, New Retail). Это всё способствовало развитию отдельных систем, вендоров. Которые стало удобно подключать как кубики. Это называется composable.
Что такое composable: не монолит и не микросервисы
Composable — это способ построения IT-системы не в форме массивного монолита и даже не десятка микросервисов, которые понятны лишь разработчикам. Это следующий уровень — набор систем с уже готовыми бизнес-функциями (Packaged Business Capability или PBC).
Одни только умных поисков на рынке больше 3х. Хотя рынок измеряется дай бог 300 млн рублей в год. 10 лет назад такое сложно было представить, потому что «ElasticSearch мы и сами развернём». А теперь это сотни часов разработки, чтобы соответствовать всем ожиданиям покупателей.
В итоге чем больше composable, тем меньше заказной разработки на рынке становится. Проекты запускаются быстрее, дешевле, порог входа ниже. Но не так всё просто. Классов систем таких больше 15. Самих систем уже несколько сотен.
Разработчики становятся интеграторами
Задачей разработчиков, как inhouse, так и outsource становится умение разбираться во всех этих вендорах. И превращаться в интеграторов. Находить оптимальное решение в заданной ситуации.
Рынок всё больше поделится на вендоров и интеграторов. И заказной разработки станет меньше. Но я смотрю на это позитивно, в итоге все кому важно запускать проекты быстро и в срок только выигрывают. А тем, кому нравилось исключительно изобретать велосипеды — нет.
К тому же останется большой объем работы для тех, кто будет сопровождать core-систему. Которая будет оркестрировать все эти множество интеграций, обеспечивать graceful degradation и делать пользовательский опыт бесшовным.
Из чего собирают компонуемую платформу
Термин «компонуемая коммерция» в 2020 году ввёл Gartner. Идея простая: магазин собирают из готовых систем, каждая из которых закрывает одну бизнес-функцию и отдаёт данные через API.
Gartner называет такие блоки PBC — Packaged Business Capability. Это не микросервис в техническом смысле, а законченная функция бизнеса: каталог, корзина, поиск, программа лояльности, расчёт доставки. У каждой свой вендор, свой SLA и своя дорожная карта.
Принципы MACH
Рядом с компонуемым подходом почти всегда звучит аббревиатура MACH: Microservices, API-first, Cloud-native, Headless. В 2020 году вендоры даже создали MACH Alliance, чтобы продвигать эти принципы.
Headless здесь главное. Витрина живёт отдельно от бэкенда, поэтому фронтенд на Next.js или Nuxt можно менять, не трогая склад и заказы. Так же отдельно можно запустить мобильное приложение, киоск в магазине или витрину для маркетплейса: все они берут данные из одних и тех же API. Для ритейла с несколькими каналами продаж это главный аргумент в пользу такой схемы.
Классы систем в екоме
Я насчитываю больше 15 классов. Самые частые в российских проектах:
- PIM — управление товарной информацией: Pimcore, Akeneo.
- OMS — управление заказами и их маршрутизацией по складам.
- Поиск и рекомендации: Diginetica, AnyQuery, Elasticsearch как основа для своего решения.
- CDP и маркетинговая автоматизация: Mindbox.
- CMS для контента: Strapi, Contentful.
- Платёжные шлюзы, расчёт доставки, ERP и 1С на стороне учёта.
Монолит, микросервисы и готовые бизнес-функции
Чтобы понять разницу, удобнее всего сравнить три подхода по тем вопросам, которые задаёт владелец бизнеса, а не архитектор.
| Вопрос | Монолит | Микросервисы | Набор PBC |
|---|---|---|---|
| Кто пишет основной код | Своя команда или подрядчик | Своя команда, много сервисов | Вендоры, команда пишет интеграции |
| Скорость первого запуска | Быстро на коробке | Медленно, долгая инфраструктура | Быстро, если системы готовы |
| Цена изменений через 3 года | Растёт с объёмом кода | Зависит от зрелости DevOps | Зависит от контрактов с вендорами |
| Главный риск | Технический долг | Сложность эксплуатации | Зависимость от поставщиков |
Когда монолит или микросервисы всё ещё выигрывают
Монолит на Битриксе или Laravel хорош для магазина с каталогом до десятков тысяч позиций и одной-двумя интеграциями. Нагрузка небольшая, команда маленькая, а лишние системы только добавят подписок.
Свои микросервисы оправданы там, где бизнес-логика нестандартна и готового вендора просто нет. Например, сложное ценообразование для B2B или собственная логистика.
Как выбрать набор систем
Ошибиться с выбором дорого: замена PIM или OMS на живом проекте занимает месяцы, а иногда и год, если к системе уже привязаны склад, маркетплейсы и 1С. Поэтому выбор я начинаю не с вендоров, а с процессов. Я бы шёл так:
- Описать бизнес-процессы и найти, где ручная работа тормозит рост.
- Разложить процессы на функции и для каждой решить: покупаем, берём open source или пишем сами.
- Проверить API вендора: документацию, лимиты запросов, вебхуки, sandbox.
- Посчитать совокупную стоимость владения на 3 года, включая подписки и поддержку интеграций.
- Запустить пилот на одной функции и только потом подключать следующую.
Типичные ошибки при сборке
Самая частая — покупать системы по презентации, не проверив интеграцию на реальных данных. Вторая — забыть про единый идентификатор товара и клиента. Без него данные в PIM, OMS и CRM разъезжаются уже через месяц.
Третья ошибка тише. Никто не отвечает за целое. Вендор поиска отвечает за поиск, вендор PIM — за карточки, а за то, почему покупатель не может оформить заказ, не отвечает никто.
Четвёртая — недооценить миграцию данных. Перенос каталога на 50 000 SKU с историей цен, остатками и связями между товарами съедает больше времени, чем настройка самой системы. Я закладываю на миграцию отдельный этап с тестовыми прогонами и сверкой по контрольным выборкам.
Что остаётся на стороне core-системы
Даже когда все функции куплены, нужна система, которая их связывает. Обычно это слой оркестрации: шина событий на Kafka или RabbitMQ, API-шлюз, кэш и мониторинг.
Graceful degradation здесь обязателен. Если поиск вендора упал, витрина должна показать каталог по простому фильтру, а не пустую страницу. Для этого у каждой внешней системы нужен таймаут, повтор запроса и запасной сценарий, а у команды — дашборд, где видно, какой сервис сейчас отвечает медленно. Если не ответил сервис расчёта доставки — взять тариф по умолчанию и пересчитать позже.
Ещё одна задача core-слоя — единый каталог идентификаторов. Товар, клиент и заказ должны иметь сквозной ID во всех системах, иначе аналитика собирается вручную в Excel.
Именно эта работа, по-моему, и останется за интеграторами надолго: за неё отвечает тот, кто понимает весь контур, а не отдельный продукт.
Вопросы и ответы
Что такое компонуемая архитектура в екоме?
Это способ строить IT-систему не монолитом и не десятком микросервисов, понятных лишь разработчикам. Это набор систем с готовыми бизнес-функциями — Packaged Business Capability, или PBC.
Чем такой подход отличается от монолита и микросервисов?
Вместо собственной разработки каждой функции подключаются готовые системы, как кубики. Проекты запускаются быстрее и дешевле, порог входа ниже.
Что станет с заказной разработкой?
Её станет меньше, рынок поделится на вендоров и интеграторов. Но останется работа над core-системой, которая оркестрирует интеграции и обеспечивает graceful degradation.