В конкурентной борьбе побеждает тот, кто умеет быстро масштабироваться, быстро реализовывать партнёрские проекты и вкладывать в рост минимум средств. Традиционное представление об интеграциях диаметрально противоположно этим приоритетам. Сроки и стоимость реализации непонятны, эффект непредсказуем, вместо ожидаемого преимущества — неопределённость.
Парадигма low-code гораздо ближе к приоритетам бизнеса. Программное обеспечение, которое работает в этой парадигме, позволяет ускорить разработку и внедрение новых систем, интеграций и фич в разы.
Один из продуктов, работающих в парадигме low-code, — ESB-система (сокр. от англ. enterprise service bus, рус. «сервисная шина предприятия»). ESB — это набор программного обеспечения, которое работает как единый центр для обмена сообщениями между информационными системами и приложениями. Сервисная шина позволяет легко настраивать маршруты движения сообщений, хранит историю сообщений, фиксирует путь каждого из них.
ESB не требует сложной и длительной разработки каждый раз, когда нужно соединить системы, которые изначально не спроектированы для совместной работы. Более того, бóльшая часть работы обеспечивается визуальными средствами разработки. При интеграции главным становится бизнес-анализ, а не технические аспекты этой интеграции.
ESB — это не монолитная система, а слой в IT-инфраструктуре компании, который состоит из нескольких продуктов. Каждый из них берёт на себя одну или несколько функций сервисной шины. В этой статье мы разложим слой ESB по функциям и расскажем, как эти функции реализованы в продуктах, популярных на российском IT-рынке.
Из чего состоит слой ESB
ESB условно делится на пять компонентов или функций: студия, брокер сообщений, логирование, мониторинг, хостинг.
1. Студия — графическая среда для разработки быстрых интеграций. Системы, параметры, действия визуализированы и максимально понятны. Функционала студии хватает на бóльшую часть действий, таких как передача и получение информации, преобразование и сбор атрибутов из одних потоков в другие. Здесь же можно задать параметры, которые ESB-шина должна отслеживать, считать ошибкой интеграции и пр. Если в рамках интеграции нужно уникальное действие, его можно написать парой строк на традиционных языках (например, Java) или специально разработанных.
Без студии и, соответственно, без визуализации интеграций ESB не может считаться low-code решением.
2. Для обмена сообщениями между системами используется брокер сообщений. Это активный компонент, который «забирает» и «отдаёт» сообщения, соблюдает их очерёдность и нивелирует нагрузку на системы, которые генерируют и получают сообщения (т. н. producer и consumer). Часто разработчики заблуждаются, называя ESB-системой именно брокер сообщений, например Apache Kafka или RabbitMQ.
3. Логирование — это фиксация всего, что происходит с сообщением. Какая система его генерирует, как оно обрабатывается, куда попадает (или не попадает) в итоге. Логирование позволяет чётко понять, движется ли сообщение по заданному маршруту и на каком этапе и по какой причине возникла проблема.
4. Важные события, которые происходят с сообщениями и очередями, необходимо мониторить и вовремя отрабатывать, реагируя на них. Компонент мониторинга позволяет задавать события, которые нуждаются в реакции, и сообщать о них поддержке.
Каждое из ESB-решений предлагает на выбор несколько возможностей размещения. Например, некоторые системы позволяют опубликовать интеграцию в частном облаке Kubernetes, OpenShift, Amazon вообще без настройки. Для публикации внутри вашего уникального кластера потребуется работа архитектора.
В этой статье мы разберём, как реализованы компоненты ESB в решениях, которые чаще всего предлагают на российском рынке: Talend, Mule, WSO2, Red Hat Fuse. Иногда разработчики дополняют список брокерами сообщений Apache Kafka (плюс Kafka Connect) и RabbitMQ, но эти два решения не являются ESB и рассматривать их в рамках данного разбора нецелесообразно.
Студия
Поддержка брокеров сообщений
Внутренних брокеров сообщений нет ни у одной из систем. Но в «коробке» есть коннекторы, поддерживающие простую интеграцию внешних брокеров сообщений. Коннекторы систематизированы и внесены в мануалы.
Как организовано логирование
Как видите, внутреннее логирование в 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 решения ничем не отличаются от привычных. Экономия на разработке начинается только после их внедрения.
.png)
