IBM Integration Bus, Oracle Service Bus, Software AG webMethods, TIBCO – все они либо ушли с рынка, либо перестали продлевать лицензии и поддержку российским заказчикам. Компании остались с работающими, но «замороженными» шинами: патчей нет, инцидент с вендором не открыть, а аудиторы безопасности уже задают вопросы. Менять ESB больно – это центр нервной системы ландшафта, через который ходят десятки интеграций. Но тянуть дальше дороже. Разберём, на что смотреть при выборе замены в 2024 году.

Что есть на рынке РФ

Зрелых вариантов несколько, и они закрывают разные сценарии.

  • Российские ESB и iPaaS – например, продукты на базе отечественных платформ интеграции, попавшие в реестр Минцифры. Дают привычную модель «шины»: маршрутизация, трансформация, оркестрация, мониторинг из коробки.
  • Open source как фундамент – Apache Camel, Apache Kafka, RabbitMQ, Keycloak для аутентификации. Это не коробочный ESB, а конструктор. Лицензионных рисков нет, но нужна команда, которая возьмёт на себя сборку, обвязку и эксплуатацию.
  • Гибрид – open-source-ядро плюс собственный слой управления, каталог сервисов и админка. Чаще всего именно этот путь даёт оптимум по стоимости владения для крупного ландшафта.

Готового «один в один как webMethods» на рынке нет. Поэтому выбор – это всегда проектирование под конкретный ландшафт, а не покупка коробки.

Критерии выбора

Не гонитесь за фичами. Сначала ответьте на четыре вопроса.

  1. Реестр и совместимость с КИИ. Если интеграционный контур обслуживает значимые объекты КИИ, шина должна быть в реестре отечественного ПО и проходить требования регулятора. Прежде чем выбирать платформу, категорируйте свои объекты КИИ – от категории зависят и сроки, и допустимый стек.
  2. Реальная нагрузка, а не маркетинговые цифры. Посчитайте текущий объём сообщений, пиковые часы, требования к гарантированной доставке и порядку. Kafka и классический ESB решают разные задачи: первый – потоки событий, второй – синхронные интеграции и сложные трансформации.
  3. Зрелость команды. Open source экономит на лицензиях, но переносит ответственность на вас. Если своей экспертизы нет – берите либо коробочный продукт с поддержкой, либо подрядчика, который доведёт шину до промышленной эксплуатации.
  4. Связь с прикладным слоем. Шина живёт не в вакууме. Если параллельно идёт переход с SAP на российскую ERP, синхронизируйте проекты: переводить интеграции дважды – под старую и под новую ERP – расточительно.

Как мигрировать без простоя

Big bang – плохая идея для интеграционного контура. Работает поэтапная схема: новая шина встаёт рядом со старой, интеграции переезжают пачками по бизнес-доменам, а strangler-подход позволяет откатиться на любом шаге. Параллельно опишите контракты сервисов – многие старые ESB хранили логику маршрутизации в проприетарном формате, и без актуальной документации миграция превращается в реверс-инжиниринг.

Отдельно заложите наблюдаемость: сквозной трейсинг, метрики латентности, алерты на очереди. То, что в коробочных продуктах было «из коробки», в open-source-сборке придётся настроить руками – но зато прозрачность будет выше.

Чем раньше зафиксированы контракты и наблюдаемость, тем спокойнее проходит перенос интеграций на новую шину: аудит текущего контура, выбор стека и поэтапная миграция без остановки бизнес-процессов.

Вывод

Менять ESB в 2024 году придётся почти всем, кто сидел на западных продуктах. Универсального ответа нет: для одних подойдёт коробочная российская шина, для других – сборка на open source с подрядчиком. Начните с инвентаризации интеграций и требований КИИ, а технологию выбирайте под нагрузку и зрелость команды – не наоборот.