От «спагетти» до гибкой архитектуры за 5 шагов: этапы внедрения ESB-слоя

Одно из преимуществ современных ESB-систем — простота на всех этапах. Для разработки интеграций предусмотрен специальный графический интерфейс, созданный в парадигме low-code. Овладеть им может не только разработчик, но и достаточно продвинутый пользователь, или citizen developer. Инструменты мониторинга и логирования позволяют своевременно заметить и локализовать ошибки, что упрощает и удешевляет поддержку.

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

Говоря о пяти этапах, мы немного «умалчиваем». Цифра пять относится непосредственно к числу этапов внедрения ESB-слоя. Но им предшествует важный и ёмкий этап проектирования решения и интеграций.

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

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

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

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

Например, у Talend в перечне функций отсутствует возможность создания переиспользуемой подпрограммы из куска интеграции. Если ваша архитектура предполагает, что какое-то действие повторяется во многих интеграциях (например, преобразование данных из формата № 1 в формат № 2), лучше выбрать систему с возможностью создания и переиспользования подпрограмм.

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

Если у вас есть ограничение на использование только отечественного ПО, вышеперечисленные продукты вам не подойдут. Лучше обратить внимание на российский Datareon.

Не стоит забывать и о финансовой модели продуктов. Так, например, у Mule сама интеграционная платформа является open-source-решением и предоставляется бесплатно, в то время как коннекторы для работы с системами доступны только на платной основе. А WSO2 предлагает покупку годовой лицензии.

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

Помимо среды для разработки интеграций, ESB-слой должен включать системы мониторинга и логирования, а также хранилище данных.
У многих ESB-систем есть встроенные инструменты мониторинга и логирования, а также прописанный перечень предпочтительных (совместимых) продуктов. Поэтому имеет смысл выбирать компоненты только после того, как вы определились со средой разработки.

Иногда мы сталкиваемся с тем, что на этапе выбора стека и внедрения ESB заказчик предлагает пропустить мониторинг и логирование, чтобы, например, удешевить проект или ускорить появление MVP.

Однако специалисты KT.Team не рекомендуют прибегать к подобным решениям, поскольку системы мониторинга и логирования помогают вовремя выявить ошибки и локализовать их. Если что-то пойдёт не так (а это, как вы знаете, случается даже в самой продуманной архитектуре), вы сможете точно локализовать проблему, устранить и предупредить её повторное появление.

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

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

По опыту KT.Team, в среднем разработка и внедрение ESB-слоя занимают около полутора месяцев до запуска MVP. Здесь мы не учитываем аналитический этап, поскольку его длительность зависит от сложности существующей и будущей архитектуры.