Сравнение ESB-решений, популярных на российском рынке

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

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

Один из продуктов, работающих в парадигме low-code, — ESB-система (сокр. от англ. enterprise service bus, рус. «сервисная шина предприятия»). ESB — это набор программного обеспечения, которое работает как единый центр для обмена сообщениями между информационными системами и приложениями. Сервисная шина позволяет легко настраивать маршруты движения сообщений, хранит историю сообщений, фиксирует путь каждого из них.

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

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

ESB условно делится на пять компонентов или функций: студия, брокер сообщений, логирование, мониторинг, хостинг.

Студия — графическая среда для разработки быстрых интеграций. Системы, параметры, действия визуализированы и максимально понятны. Функционала студии хватает на бóльшую часть действий, таких как передача и получение информации, преобразование и сбор атрибутов из одних потоков в другие. Здесь же можно задать параметры, которые ESB-шина должна отслеживать, считать ошибкой интеграции и пр. Если в рамках интеграции нужно уникальное действие, его можно написать парой строк на традиционных языках (например, Java) или специально разработанных.

Без студии и, соответственно, без визуализации интеграций ESB не может считаться low-code решением.

Для обмена сообщениями между системами используется брокер сообщений. Это активный компонент, который «забирает» и «отдаёт» сообщения, соблюдает их очерёдность и нивелирует нагрузку на системы, которые генерируют и получают сообщения (т. н. producer и consumer). Часто разработчики заблуждаются, называя ESB-системой именно брокер сообщений, например Apache Kafka или RabbitMQ.

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

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

Каждое из ESB-решений предлагает на выбор несколько возможностей размещения. Например, некоторые системы позволяют опубликовать интеграцию в частном облаке Kubernetes, OpenShift, Amazon вообще без настройки. Для публикации внутри вашего уникального кластера потребуется работа архитектора.

В этой статье мы разберём, как реализованы компоненты ESB в решениях, которые чаще всего предлагают на российском рынке: Talend, Mule, WSO2, Red Hat Fuse. Иногда разработчики дополняют список брокерами сообщений Apache Kafka (плюс Kafka Connect) и RabbitMQ, но эти два решения не являются ESB и рассматривать их в рамках данного разбора нецелесообразно.

Нравится статья?

Укажите свою почту, и мы будем присылать вам еженедельный анонс новых статей.

+ — студия есть в «коробке».

± — студия есть, но она сложнее в настройке и требует постоянного участия разработчиков, что идёт вразрез с парадигмой low-code.

Внутренних брокеров сообщений нет ни у одной из систем. Но в «коробке» есть коннекторы, поддерживающие простую интеграцию внешних брокеров сообщений. Коннекторы систематизированы и внесены в мануалы.

Как видите, внутреннее логирование в ESB-системах реализовано практически идентично — с небольшими особенностями, индивидуальными для каждого из продуктов.

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

Логирование во внешней системе даёт ESB дополнительную гибкость. Скорее всего, у бизнеса масштаба enterprise в IT-архитектуре уже есть компонент для логирования, и системы не будут дублировать функции друг друга.

Мониторинг событий отдаётся во внешние системы через универсальный компонент. Система мониторинга может быть любой из тех, что удобны отделу эксплуатации: Checkmk, Prometheus, Zabbix и т. д. Бизнес совместно с разработчиками создаёт мануал, описывающий метрики, которые нужно контролировать, допустимые и недопустимые отклонения, а также действия, необходимые для исправления ситуации.

Talend, Mule, WSO2 позволяют решить проблему скорости проведения интеграций и соответствуют парадигме low-code.

Red Hat Fuse по функционалу близка к предыдущим трём продуктам, но уже не может считаться low-code решением: даже для рядовых операций здесь нужен именно разработчик. Однако в ней сохраняется принцип самодокументируемости.

Apache Kafka и RabbitMQ являются не ESB-системами, а брокерами сообщений. Их недостаточно, чтобы создать полноценный слой ESB, они не дают никаких преимуществ в плане упрощения интеграций и масштабирования, но при этом могут стать частью слоя ESB.

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

Отдельно обозначим, что само внедрение low-code ESB происходит не мгновенно. Как и всякая масштабная интеграция, оно требует времени и ресурсов: затрат на команду разработчиков, на серверы (при необходимости) и т. д. В этом low-code решения ничем не отличаются от привычных. Экономия на разработке начинается только после их внедрения.