Недавно на Хабре вышла статья от команды Diasoft, которая заставила меня задуматься: «Умная шина: почему мы не стали писать ещё один ESB» Источник. Это не просто очередной технический пост — это манифест прагматичного подхода к интеграции. Я, как предприниматель, который за последние три года внедрил десятки AI-агентов в реальные бизнес-процессы, вижу здесь глубокую параллель с тем, как мы строим свою инфраструктуру.
Когда мы начинали проект по автоматизации рутинных задач в отделе закупок, перед нами стоял выбор: писать собственный ESB (Enterprise Service Bus) или использовать готовые решения. Мы выбрали путь, описанный в статье — не изобретать велосипед, а использовать «умную шину»: комбинацию готовых инструментов, AI-агентов и минимального кастомного кода. Результат: сократили время на интеграцию с 3 месяцев до 2 недель.
Почему не стоит писать свой ESB
Главная мысль статьи — современные корпоративные интеграции не требуют монолитной шины. Вместо этого Diasoft предлагает подход, основанный на событийно-ориентированной архитектуре (Event-Driven Architecture, EDA). Я полностью согласен: когда мы внедряли AI-агента для обработки заявок на закупку, мы не поднимали свой брокер сообщений — использовали готовый Kafka.
Вот несколько причин, почему написание собственного ESB — это тупик:
- Сложность поддержки: каждый новый API требует доработки шины. В нашей практике мы подключали Telegram, Salesforce и Google Analytics через API, и каждый раз это была ручная работа.
- Отсутствие гибкости: когда бизнес-логика меняется (а она меняется часто), ESB становится узким горлышком.
- Риски vendor lock-in: многие коробочные ESB привязывают к своему формату данных.
Как мы строим интеграции без ESB
Вместо ESB мы используем подход «умной шины» — это набор автономных AI-агентов, которые общаются через REST API и очереди сообщений. Пример из нашей практики:
- AI-агент-анализатор получает данные из Telegram-бота (заявки от сотрудников).
- AI-агент-трансформатор приводит данные к единому формату (JSON).
- AI-агент-диспетчер отправляет заявку в ERP-систему через REST API.
Каждый агент — это отдельный микросервис, который можно разрабатывать и тестировать независимо. Мы не тратим время на синхронизацию протоколов — просто используем HTTP и JSON.
Практический пример: интеграция с Telegram
Допустим, вам нужно, чтобы AI-агент принимал заявки из Telegram и отправлял их в CRM. Вот минимальная архитектура:
- Telegram Bot API: получает сообщения.
- AI-агент: разбирает текст (например, «купить 100 пачек бумаги») и извлекает сущности.
- CRM API: создаёт задачу.
Никакого ESB — только три HTTP-вызова. ASI Biont поддерживает подключение к Telegram через API — подробнее на asibiont.com/courses. Это позволяет запустить агента за день, а не за месяц.
Что делать, если у вас уже есть ESB
Если вы уже используете ESB, не спешите его выкидывать. В статье Diasoft предлагают постепенный переход: начать с изоляции новых сервисов на событиях, а старые системы оставить на шине. Мы делали так:
- Выявили 20% критических интеграций, которые работают через ESB.
- Остальные 80% (новые проекты, AI-агенты) запустили на событийной модели.
- Через полгода мы полностью отказались от ESB для новых интеграций.
Результат: время на добавление нового источника данных сократилось с 4 недель до 3 дней.
Заключение
«Умная шина» — это не маркетинговый термин, а практический паттерн. Если вы строите современную AI-инфраструктуру, не тратьте ресурсы на создание ещё одного ESB. Используйте готовые инструменты (Kafka, RabbitMQ, REST API) и AI-агентов для адаптации данных. Это сэкономит вам месяцы разработки и миллионы рублей.
Кстати, в статье Diasoft упоминают, что их подход уже используют несколько крупных банков. Мы тоже проверили на себе — работает.
Комментарии