Composable или традиционная архитектура

В современном цифровом мире компании в сфере электронной коммерции сталкиваются с вызовом сохранения конкурентоспособности и предоставления всё более сложных и инновационных услуг для клиентов.

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

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

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

Что понимается под традиционным подходом?

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

• “Headful” или отсутствие гибкости. Это означает, что фронтэнд и бэкэнд в сложных монолитных системах тесно интегрированы между собой, и добавление новой функциональности может быть затруднительным и медленным.

• Единая кодовая база. Всё приложение создаётся с использованием единой кодовой базы. Изменения вносятся в приложение в целом, и нельзя изолировать изменения или внедрения в определённые его части.

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

Что такое компонуемая архитектура?

Composable commerce отличается от традиционной модели тем, что слои фронтенд и бэкенд разделены между собой, а все компоненты бэкенда — становятся отдельными элементами, которые могут работать, масштабироваться и обновляться независимо. Каждый из компонентов выполняет определённую операцию, необходимую для бизнеса: управление корзиной, расчёт налогов, применение акций или любые другие операции. Все компоненты в такой системе могут быть “собраны” вместе, а доступ к ним осуществляется через API.

Отделение фронт-энда позволяет более гибко использовать различные технологии и приложения на бэкенде для создания лучшего пользовательского опыта. Основные характеристики этого подхода включают:

• “Headless”. Фронтэнд приложения разделён и отделён от компонентов бэкэнда.

• Модульность или микросервисы. Функциональность решения в целом достигается путём объединения изолированных компонентов, так что можно обновлять отдельные компоненты системы без необходимости изменения всего решения.

• API first. API-ориентированная структура позволяет использовать компоненты и функции, взаимодействие которых осложнено в рамках монолитной системы.

Сравнение основных различий

Архитектура

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

Масштабируемость

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

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

Универсальная гибкость через отделение фронтэнда: разнообразие возможностей для различных платформ

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

Гибкость и скорость выхода на рынок

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

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

• Управление данными. Независимые компоненты порождают большие объёмы данных, что усложняет управление ими.

• Затратность ресурсов. Выбор любого компонента требует времени, средств и ресурсов для принятия соответствующих решений.

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

• Высокий уровень DevOps. Управление значительным количеством независимых компонентов требует наличия квалифицированных DevOps команд.

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

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

Безопасность и конфиденциальность данных

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

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

Зависимость от поставщика

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

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

Преимущества компонуемой архитектуры

1. Управление пользовательским опытом: эволюция архитектурного подхода

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

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

2. Увеличение доступных ресурсов и возможность привлечения более широкого круга подходящих разработчиков

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

Риски компонуемой архитектуры

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

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

1. Сложность и внутренняя техническая зрелость

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

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

2. Размер и структура проекта и команды

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

3. Настраиваемость против стандартизации

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

4. Общая стоимость владения

Сравнивая два подхода, компонуемая архитектура, как правило, обещает более высокую общую стоимость владения (TCO) по сравнению с традиционной коммерцией.

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

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

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

Как Magento облегчает внедрение компонуемой архитектуры

Методология компонуемой архитектуры Adobe Commerce

В качестве платформы, существует несколько уникальных возможностей для поддержки eComm-бизнесов, которые рассматривают возможность перехода к “безголовой” и компонуемой архитектуре. Adobe Commerce обеспечивает поддержку обоих архитектурных подходов, позволяя бизнесам выбирать тот или иной подход, либо гибридную комбинацию, наилучшим образом соответствующую их конкретным потребностям.

Богатый функционал с большим количеством готовых решений

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

Гибридные негибкие и “безголовые” интерфейсы

Adobe Commerce предлагает разнообразные варианты доставки клиентского опыта для различных точек контакта, что позволяет интегрировать как негибкие, так и “безголовые” пользовательские интерфейсы в рамках единой экосистемы. Это даёт компаниям возможность выбирать наиболее подходящий архитектурный подход для каждого конкретного случая использования. Более того, такой подход позволяет постепенно переходить к негибким и компонуемым архитектурам, не требуя одновременной миграции всей системы.

API Mesh

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

Заключение

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

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

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

Magento предоставляет решения, которые сочетают в себе лучшие качества обоих подходов, что упрощает и делает более эффективным переход к компонуемой архитектуре.