Интеграции и обмен данными сегодня — это не просто техническая задача, а фундамент цифровой зрелости бизнеса. Российский рынок переживает быстрые изменения: уход западных вендоров, рост требований к надёжности и безопасности, распространение микросервисных архитектур. Как компании справляются с вызовами, когда стоит менять старую интеграционную платформу, зачем бизнесу API Gateway и брокеры сообщений, и можно ли обойтись без интеграционной шины?
— Когда действительно стоит менять старую интеграционную шину (ESB)?
Владимир Гантурин: Вопрос замены старой ESB стоит рассматривать в двух плоскостях — технологической и нетехнологической.
Нетехнологическая часть связана с правовыми ограничениями и санкциями. Здесь выбора нет: если продукт попадает под ограничения, его нужно заменить на отечественное или иное решение, разрешённое к использованию.
Технологический аспект сложнее. Если шина стабильна, поддерживает необходимые протоколы и справляется с нагрузкой, срочной необходимости в замене нет. Проблема возникает, когда:
отсутствует поддержка актуальных протоколов или есть уязвимости в безопасности;
шина не справляется с увеличившимися объёмами обмена данными;
невозможно интегрироваться с современными облачными архитектурами;
не реализуются новые требования (например, real‑time взаимодействие или развёртывание API).
В таких случаях есть два пути:
Постепенная модернизация. Оставить старую шину в работе, обновить инфраструктуру, поставить фасады — API Gateway, адаптеры, интеграционные сервисы — и постепенно переводить процессы на новую архитектуру.
Полная замена. Применяется при критичных правовых ограничениях или когда шина стала «технологическим тупиком» и её модернизация нецелесообразна.
Оптимальным во многих случаях является гибридный подход: стабилизировать и обновить существующую ESB, интегрировать новые сервисы через фасады, а затем постепенно, по мере миграции критичных процессов, вывести старую систему из эксплуатации.
— Насколько актуален сам термин ESB сегодня?
Владимир Гантурин: Термин Enterprise Service Bus (ESB) сегодня во многом устарел. Современные интеграционные шины работают не по классической ESB‑модели, а на основе событийных архитектур — event sourcing и messaging. В России, да и на Западе, название «ESB» часто используется по привычке, как «ксерокс» или «джип».
В новой архитектуре API Gateway и брокер сообщений — это не альтернативы, а части одной интеграционной платформы.
API Gateway управляет маршрутизацией и доступом к сервисам, обеспечивает единый вход для запросов.
Брокер сообщений — обязательный элемент, отвечающий за транспорт событий и данных.
Ошибочно считать, что установка одного брокера (Kafka, RabbitMQ, ActiveMQ) уже решает задачу построения шины. Брокер лишь передаёт сообщения, но не выполняет бизнес‑логику, трансформацию данных или управление ошибками. Например, если внешний сервис временно недоступен, шина должна уметь повторно запросить данные с нужным интервалом и количеством попыток — брокеры сами по себе этим не занимаются.
Поэтому современная шина — это комплекс, включающий брокер, API Gateway и слой бизнес‑логики, который обеспечивает надёжную и предсказуемую интеграцию между системами.
— Микросервисы упрощают интеграцию или наоборот усложняют её?
Владимир Гантурин: Микросервисы долгое время позиционировались как универсальное решение для масштабируемости и гибкости. Но практика показывает: их внедрение часто не упрощает интеграцию, а наоборот усложняет.
Основные проблемы возникают, когда компании переходят на микросервисы «по моде», без осознанного проектирования:
слишком мелкая грануляция и неудачные границы сервисов превращают взаимодействие в хаос;
отсутствуют системы централизованного логирования, мониторинга и трассировки;
разношёрстный технологический стек (PHP, Go, Python, Java в одном проекте) создаёт проблемы с экспертизой и сопровождением.
С точки зрения интеграции микросервисы действительно добавляют сложностей. Но современные шины строятся именно вокруг событийных моделей и микросервисного подхода. Здесь важно наличие централизованного инструмента для управления интеграционными процессами. Он должен опираться на Enterprise Integration Patterns — стандартные блоки поведения: повторение запросов к «упавшему» сервису, маршрутизация сообщений, трансформация данных и так далее
Ключевой элемент — оркестрация интеграционных потоков. Если каждый поток реализован как микросервис, необходимо централизованное управление, мониторинг и распределённая трассировка. Это сложно, но при правильной реализации даёт серьёзные преимущества:
масштабируемость (один интеграционный процесс можно поднять в десятках инстансов и обрабатывать данные быстрее);
устойчивость к сбоям;
прозрачность интеграций.
Таким образом, переход на микросервисную архитектуру требует зрелой интеграционной платформы с централизованным управлением. Только в этом случае микросервисы перестают быть источником хаоса и становятся инструментом масштабирования и гибкости.
— Как в новой архитектуре управлять API?
Владимир Гантурин: Управление API в классических ESB и в современных микросервисных архитектурах принципиально различается.
В старых шинах всё было централизовано: сама шина отвечала и за публикацию сервисов, и за безопасность, и за контроль доступа. Это давало удобство, но создавало «бутылочное горлышко» — любое изменение или исправление требовало вмешательства в саму шину, что снижало гибкость.
В микросервисной архитектуре эти функции берёт на себя API Gateway. Он становится распределённой точкой входа и решает задачи:
безопасность (аутентификация, авторизация, шифрование);
ограничение нагрузки (rate limiting);
сбор метрик, логирование, трассировка, бизнес‑мониторинг;
аудит доступа.
Важно, что в отличие от старых ESB, API Gateway не содержит бизнес‑логику и трансформацию данных. Его роль — централизовать безопасность, наблюдаемость и управление трафиком, а прикладная логика реализуется отдельными сервисами.
— Насколько сложна миграция с западных решений?
Владимир Гантурин: Миграция с иностранных интеграционных платформ не является критически сложной задачей. На российском рынке есть достаточное количество сильных игроков — как с лицензиями ФСТЭК, так и с современными технологическими подходами. Например, наша шина Compo ESB построена на передовых архитектурных принципах, хотя лицензирование ещё в процессе.
Ключевой фактор миграции — необходимость. Если платформа попала под санкции или возникли проблемы с продлением лицензии, переход неизбежен. Но если система продолжает работать стабильно, всегда стоит взвесить, действительно ли нужна срочная замена.
Есть и важный контекст: западные продукты формировались десятилетиями, с многомиллиардными инвестициями. Это дало им высокое качество интерфейсов и «обложки», к которому привык бизнес. Российские вендоры работают в других условиях — без такого финансового фундамента. Отсюда разрыв ожиданий: бизнес требует «как у западных решений», но отечественные продукты пока выглядят проще внешне.
При этом по сути — по функционалу, производительности, безопасности — российские решения не уступают. Да, интерфейс может быть менее «глянцевым», но технологическая база соответствует современным требованиям и обеспечивает надёжную работу.
— Что значит «интеграция как сервис»?
Владимир Гантурин: Интеграция как сервис — это подход, при котором интеграция перестаёт быть набором точечных связей и становится самостоятельной функцией компании. Для её эффективной работы ответственность делится на три уровня.
Инфраструктура. Команда обеспечивает техническую платформу: доступность, безопасность, маршрутизацию. Здесь SLA может включать, например, 99,9% доступности или ограничение времени маршрутизации до 50 мс.
Интеграционная команда. Определяет форматы данных, протоколы, архитектурные подходы (API‑first, event‑driven), поддерживает документацию и методологию. Их SLA связаны с качеством интеграции: соблюдение контрактов, тестирование эндпоинтов, ограничение числа вызовов, контроль процента ошибок.
Бизнес‑владельцы сервисов. Отвечают за бизнес‑логику и пользовательские SLA: например, обработка оплаты заказа менее чем за 2 секунды в 99% случаев, согласованность данных между системами.
Есть и нюансы. Например, если внешний сервис недоступен (банк или госреестр), из‑за этого ломается часть бизнес‑процессов. В таких ситуациях важно заранее определить зоны ответственности и правила, по которым инцидент влияет на SLA.
Таким образом, интеграция как сервис требует комплексного подхода: технологическая надёжность платформы, методология работы интеграционной команды и бизнесовые SLA должны быть согласованы между собой.
— Как выйти из «золотой клетки» старой платформы? И можно ли обойтись без интеграционной шины?
Владимир Гантурин: Вопрос «как выйти из золотой клетки старой платформы» на самом деле упирается не в технологии, а в бизнес‑логику и финансы. Если система работает стабильно и окупается, менять её ради самой замены нет смысла. Решение о миграции принимается тогда, когда появляются реальные вызовы: санкции, невозможность масштабирования, рост требований к бизнес‑процессам.
Замена платформы — это всегда дорогостоящий и длительный проект, часто на 1–2 года. MVP для отдельных критичных процессов можно реализовать быстрее, но полноценный переход требует серьёзного планирования: составления требований, подготовки ТЗ, выбора подрядчиков.
Что касается второго вопроса — можно ли обойтись без интеграционной шины. Для небольшого бизнеса — да, достаточно простых точечных интеграций. Но в среднем и крупном бизнесе шина становится необходимостью: растёт количество интеграций, возникает потребность в обмене данными с партнёрами и клиентами, увеличиваются требования к надёжности и скорости. На этом уровне «костыли» перестают работать — нужна полноценная интеграционная платформа.