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

Когда IT-архитектура компании только начинает формироваться, будущий её масштаб сложно оценить. Поэтому к моменту, когда вместо двух «1С» для бухгалтерии и управления складом в неё входит уже 30−40 систем, IT-команде приходится работать с исторически сложившейся архитектурой формата «звезда», который также — и неслучайно — называют «спагетти».

В этой статье эксперты KT.Team рассказывают, какие этапы предстоит пройти компании, чтобы заменить прямые интеграции типа «точка — точка» интеграциями через ESB-слой.

ESB для прозрачных и легко поддерживаемых интеграций

Концепция сервисной шины (ESB-слоя) не нова и не так редко встречается в IT-практике.

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

На практике механизм работы сервисной шины таков:

• при помощи интеграции ESB с заданной периодичностью забирает информацию из системы-источника;

• передаёт эту информацию в DWH (хранилище данных) или брокеру сообщений, которому делегированы функции хранилища (мы в KT.Team приняли как правило, что для каждого вида данных должно быть собственное хранилище — это ослабляет связи и взаимную зависимость между системами и сервисами: так, в случае возникновения ошибки в одном хранилище будет затронут не весь IT-контур, а лишь минимальная его часть, связанная с этим хранилищем);

‍

• извлекает данные из хранилища — как правило, по запросу системы-получателя, но можно задать и другие условия;

• трансформирует извлечённые данные, если необходимо;

• обогащает (опять же, по необходимости) извлечённые данные информацией из других хранилищ;

• передаёт информацию системе-получателю в виде, объёме и формате, которые ей подходят.

Фактически ESB берёт на себя роль тех же прямых интеграций. Но интеграции типа «точка — точка» подразумевают, что CRM может отдавать одну и ту же информацию о клиентах 10, 20, 40 раз — если это предусмотрено, соответственно, в 10, 20 или 40 интеграциях. ESB забирает информацию один раз и раздаёт её системам-получателям столько раз, сколько необходимо.

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

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

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

Пять этапов разработки и внедрения ESB-слоя

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

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

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

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

1. Выбор места хранения ESB

Предлагаем начать с этого этапа до выбора само́й системы. Почему? Разные продукты работают в разных парадигмах. Например, n8n подойдёт, только если вы согласны работать через облако. А WSO2 может быть установлена и на выделенных серверах компании. И если для вас по какой-либо причине принципиально важно иметь ESB-слой на собственных серверах (например, таковы отраслевые требования безопасности), n8n не подойдёт вам по определению.

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

1. Планируется ли в ближайшие три года кратное масштабирование компании или IT-архитектуры? Собственный сервер даёт больше свободы в этом вопросе.
2. Важна ли для вас максимально быстрая настройка ESB? У облачного варианта скорость развёртывания и настройки выше.
3. Насколько высоки требования к безопасности данных? Сервер защищён от атак и потерь лучше.
4. Является ли стоимость хранилища важным ограничением? Собственные серверы — более дорогой вариант.

2. Выбор среды для разработки интеграций

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

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

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

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

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

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

3. Выбор стека компонентов

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

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

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

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

4. Настройка и внедрение ESB-слоя

На «нулевом» этапе вы разбирали, как потоки данных выглядели в старой IT-архитектуре (модель as is), а сейчас вашей команде предстоит настроить новую архитектуру (модель to be).

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

Второе: не пытаться подстроить инструмент под привычные парадигмы. Даже в практике В low-code-инструменте разработчики по-прежнему писали интеграции кодом вместо того, чтобы использовать средства графической среды. Поэтому опыт работы с low-code (а лучше — опыт правильного построения интеграций) станет для команды внедрения плюсом.

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

Сам этап внедрения предполагает:

• развёртывание интеграционной платформы и других компонентов ESB-слоя на серверах компании (если выбран этот вариант) или подключение интеграционной платформы и других компонентов к вашей архитектуре;

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

• реализацию интеграций по сценариям, прописанным на предыдущей стадии;

• отладку и дебаггинг.

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

5. Документирование

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

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

Сколько времени потребуется на разработку?

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

‍