Вы наверняка слышали термин «MACH архитектура», которая включает в себя Микросервисы, API-First дизайн, Cloud-Native инфраструктуру и Headless фронтенд. На Хабре тема MACH архитектуры практически не поднимается ввиду как сложности полной реализации и того факта, что MACH обычно ассоциируют только с E-Commerce уровня enterprise. Настораживает, что вокруг МАСН много пиара, но очень мало кейсов внедрений. Собственно, данный обзор — об этом.
На чем не хотелось бы долго останавливаться — это на преимуществах МАСН и расшифровке аббревиатуры. Таких статей полно в интернете, и они все как под копирку. Просмотрев одну, можете считать, что вы видели все.
Небольшой анонс: компания SSP SOFT работает в сфере заказного программирования и приглашает на позиции системного аналитика, разработчиков на Java, React и Python, 1С, инженеров DevOps и QA — см. вакансии на странице компании на hh.ru.
А не придумать ли нам новый термин — МАСН?
Начну с того, что недавняя пара лет (2020-2022) моей работы в компании Virto Commerce дают мне условное право порассуждать по теме этой статьи. Virto Commerce — вендор одноименной платформы электронной коммерции уровня enterprise на архитектуре МАСН, причем на базе стека .NET, что редкость для таких больших систем. Одно время Virto Commerce пробовала найти спрос на свою систему E-Commerce на российском рынке и даже вела блог на Хабре, но после февраля 2022 это все осталось в прошлом.
Теперь ближе к теме — в сфере enterprise E-Commerce, где конкуренция велика, циклы продаж долгие, а сами продукты сложные и дорогие, вендоры очень любят придумывать красивые маркетинговые термины, чтобы отстроиться от конкурентов и продать свою систему E-Commerce крупным ритейлерам, дистрибьюторам и производителям товаров.
В 2020 году, когда в пандемию закрылись оффлайновые магазины и все ринулись покупать онлайн, возник спрос на софтверные решения E-Commerce, которые можно было бы быстро обновлять, развивать и масштабировать под растущий спрос, непредсказуемо меняющийся рынок и капризы покупателей.
Тут Gartner и придумал новый термин «компонуемая коммерция». Речь шла о том, чтобы заказчики систем E-Commerce не были бы жестко привязаны к одному вендору, а могли использовать в своей торговой инфраструктуре лучшие из доступных на рынке приложений и модулей разных производителей, склеенных по API. Цель — поднять электронную торговлю на новый уровень, осчастливить как покупателей, так и сам торговый бизнес. Идея, в целом, здравая и амбициозная.
Естественно, предполагалось, что этим будет заниматься не сам заказчик в лице торговой сети или производителя товаров, а так называемый Implementation Partner, — или по-нашему, приглашенный системный интегратор. Этот момент будет использован позже при создании так называемой МАСН-ассоциации, и о ней я еще скажу ниже.
Также, предполагалось, что компонуемые приложения и иные программные модули должны иметь ограниченную функциональность, обеспечиваемую на уровне микросервисов, и иметь точки сопряжения в виде API. Как пример такого компонуемого модуля в E-Commerce можно назвать модуль поиска по каталогу товаров. Это может быть и Elasticsearch, и Azure AI Search, и т.д.
Теперь мы, собственно, и подошли к появлению термина «MACH архитектура», который является технологической основой «компонуемой коммерции». Первой эту аббревиатуру предложила компания Commercetools, тоже один из вендоров систем E-Commerce. На удивление, термин MACH (Microservices, API-first, Cloud-native, Headless) довольно быстро прижился в ИТ-индустрии для архитектуры E-Commerce. Здесь важно, что МАСН может предоставить омниканальное обслуживание для клиентов и помогает быстро внедрять разные «горячие» новинки онлайн-торговли.
Headless-подход в E-Commerce нужен для омниканального обслуживания — это когда клиент может начать покупку на десктопе, продолжить в смартфоне, далее в боте и т.д. Для разработчиков Headless-подход позволяет не заниматься поддержкой набора фронтендов для разных типов устройств и разных региональных рынков, что тоже удобно.
Если говорить про заявленные реализации MACH архитектуры — все они приходятся на enterprise E-Commerce, причем у очень и очень крупных компаний. В этом списке называются Nike, Puma, Spotify, Netflix, Uber (причем без подробного описания этих проектов, только про «улучшили» и «углубили»). Причины столь выборочной реализации MACH — в больших бюджетах на услуги интеграторов, сложностях построения ИТ-систем для уровня крупных корпораций, и во множестве доработок при интеграции так называемых «best of breed, лучших на рынке» сервисов и приложений от разных вендоров ПО.
Присутствуют и сложности с реализацией информационной безопасности в MACH. Распределенная архитектура на базе микросервисов, облаков и безголового фронтенда провоцирует дополнительные уязвимости в области безопасности, так как каждый компонуемый модуль или интегрируемый внешний модуль/сервис могут представлять потенциальную точку атаки.
MACH-ассоциация как метод борьбы с конкурентами в E-Commerce
На мой взгляд, популяризация и пиар-шум вокруг MACH архитектуры — это не только про технологии, но и многократно протоптанный путь создания разных инициатив, целью которых является отстройка от конкурентов и попутный заработок при раздаче «сертификатов соответствия» и тому подобных мулек.
Положение вещей на рынке enterprise E-Commerce таково, что какая-никакая система электронной торговли уже давно имеется у всего торгового и промышленного крупняка. Но, в подавляющем большинстве, это монолитные системы, которые трудно быстро обновлять и развивать. И эти системы действительно надо модернизировать. Поэтому вокруг торгово-промышленных компаний тучами вьются вендоры E-Commerce систем и интеграторы, с целью продать свои продукты и услуги.
И тут отлично работает прием разделения поставщиков на хороших и плохих парней по типу «Зеленой повестки» с пресловутым углеродным следом. Главное убедить заказчиков, что вендоры и интеграторы с мулькой «Сертифицированный МАСН-поставщик» — это пчелы с правильным медом, а все остальные игроки рынка софта и услуг для E-Commerce — не более, чем унылое г.
Достаточно посетить сайт МАСН-ассоциации, чтобы убедиться, что процесс сертификации и продажи мулек «соответствия МАСН» отлично налажен и действует. А если мы пойдем на страницу кейсов, то найдем не более дюжины внедрений в крупных компаниях, причем ни в одном из кейсов не описана полная МАСН-архитектура. Где-то внедрили микросервисы, где-то перенесли часть системы в облако или сделали мобильную версию.
Означает ли все это, что термин МАСН-архитектуры дискредитирован, а сама архитектура не заслуживает внимания? Отнюдь нет, в сочетании Microservices, API-first, Cloud-native, Headless есть рациональная технологическая идея. Микросервисы сегодня стали одной из основ разработки, а API и облака используются повсеместно. Разве что Headless является заметно более редкой технологией, так как далеко не во всех проектах за пределами E-Commerce эта функциональность имеет практический смысл и востребована.
Точно также, интегратор без мульки «MACH Certified SI» ничем не отличается от имеющего такую мульку, поскольку команды разработчиков и там, и там — наверняка имеют навыки в создании микросервисов и API, а также размещения приложений в облаке.
Сравнение архитектуры МАСН и монолитов
После предыдущего раздела про МАСН-ассоциацию и ее торговлю мульками не хотелось бы создать впечатления, что МАСН — это только маркетинг. Справедливости ради, нельзя не отметить, что практически любая реализация MACH будет лучше монолита для архитектуры большинства ИТ-проектов.
Монолитные решения (в т.ч. в E-Commerce), такие как от SAP и IBM, тоже имеют право на жизнь, но скорее подойдут для компаний в В2В секторе, где требуется высокий уровень информационной безопасности и полный контроль над ИТ-инфраструктурой. Кроме того, они продолжают работать в секторе В2В еще и потому, что там обычно не требуется частых изменений интерфейса приложений, бесконечного расширения функциональности и постоянного обновления пользовательского опыта.
Небольшая таблица поможет сравнить монолитные и MACH системы на функциональность:
| Монолит | МАСН |
Масштабируемость | Масштабируется целиком. Если нужно масштабировать или обновить какую-то отдельную функцию, придется обновлять всю систему. | Можно масштабировать шаг за шагом. Каждый модуль обновляется отдельно, не затрагивая другие процессы. Это дешевле, быстрее, меньше риск краха всей системы. |
Гибкость | Изменение функциональности решения требует длительной подготовки. Высокая зависимость от поставщиков (для покупных монолитов). | Если вам нужно что-то изменить — это можно изменить относительно быстро. Для решений с открытым исходным кодом вы даже можете изменить его на своей стороне и предложить своему поставщику как шаблон или add-on. |
Техподдержка | Чаще всего выполняется вендором решения. Все части монолита взаимозависимы, поэтому полностью самостоятельная поддержка без вендора крайне проблематична. | Каждый модуль можно пофиксить отдельно, даже не обращаясь к вендору ПО. |
Безопасность | Высокий уровень безопасности, при этом все данные, чаще всего, хранятся в одной БД. | Высокий уровень безопасности благодаря раздельному фронтенду и бэкенду. Возможен доступ по ролям пользователей. |
Время окупаемости | Очень медленно внедряемые инновации затрудняют окупаемость. | Относительно быстрая смена всей функциональности, которая вам нужна. |
Интеграция | Интеграция с другими системами и решениями затруднена, порой до уровня “невозможно”. | Благодаря API, микросервисам и облакам относительно легко интегрируется с другими решениями. |
ИИ как способ расширить MACH за пределы сектора E-Commerce
Согласитесь, что раз сочетание микросервисов, API-First, Cloud-Native (и, возможно, вместе с Headless) — достаточно прогрессивно, не стоит ограничиваться только E-Commerce и пиаром вокруг онлайн-торговли и дистрибуции.
Сегодня разные команды работают над расширением областей применения систем с MACH архитектурой за счет внедрения ИИ. Как представляется, это поможет сделать системы на основе MACH архитектуры доступными для более широкого круга заказчиков, включая средний бизнес.
Разработчики, выполняющие интеграцию искусственного интеллекта в архитектуру приложений MACH, в некотором смысле — первопроходцы, пытающиеся прикрутить ИИ ко всему, до чего руки дотянутся. Что-то подобное было в эпоху доткомов, когда был дикий энтузиазм по популяризации доступа к интернету, внедряемого для практически любых вещей.
Вот небольшой список из тех направлений внедрения ИИ в МАСН, которые можно найти на просторах интернета:
1. Использование микросервисов для функций ИИ. Это самое распространенное направление, улучшающее функциональность продуктов, хотя и не способствующее напрямую более широкому внедрению МАСН на рынке. ИИ-функции могут быть реализованы в виде отдельных микросервисов, каждый из которых отвечает за конкретную функцию ИИ. Примеры —обработка естественного языка (Natural Language Processing, NLP), машинное обучение (Machine Learning, ML), анализ данных, тестирование гипотез и т.д.
2. API при взаимодействии с ИИ-сервисами могут быть использованы для выполнения специфических задач через вызов других микросервисов в архитектуре MACH. Подход API-First в архитектуре MACH позволяет относительно безболезненно интегрировать любые сервисы, в том числе и ИИ.
3. В МАСН можно добавлять и использовать облачные ИИ-сервисы, такие как распознавание речи, обработка изображений, прогнозирование и т.д. от различных провайдеров. Эти сервисы могут быть через API интегрированы в основную архитектуру MACH, также базирующуюся в облачной инфраструктуре.
4. ИИ может быть использован в архитектуре headless приложений для улучшения пользовательского опыта, — например, через выполняемую «на лету» персонализацию контента. Считается, что анализ поведения пользователей и предсказания их предпочтений помогает предлагать персонализированный контент, который лучше соответствует интересам каждого конкретного пользователя. Отмечу, что это спорный подход, так как пользователь может лишиться разнообразия в предлагаемом контенте (по типу того, как если купить однажды красные туфли, то в персональном предложении теперь будут только туфли такого цвета).
Заключение
Архитектура MACH, основанная на микросервисах, API, облачной и headless архитектуре, выглядит как вполне перспективная основа для создания гибких и масштабируемых ИТ-экосистем. Со своей стороны, генеративный ИИ предлагает новые возможности для создания динамичных, персонализированных предложений для клиентов в В2С и В2В секторах, а также снижения затрат (например, для оптимизации создания и перевода контента, масштабирования разработки/кодирования и т. д.).
Если отстроиться от излишне маркетингового толкования МАСН, то системным архитекторам и аналитикам имеет смысл обратить внимание на связку МАСН + ИИ как технологическую основу для новых или развивающихся проектов.
А вы как считаете? поделитесь конструктивным мнением :-)
