Весной зарубежные вендоры интеграционных платформ остановили продажи и поддержку в России. Компании, которые построили обмен данными на коммерческих ESB и облачных iPaaS, остались с истекающими лицензиями, заблокированными обновлениями и закрытыми тикетами. Интеграционная шина – это нервная система предприятия: через неё ходят заказы, платежи, складские остатки и обмен с госсистемами. Когда такой узел перестаёт обновляться, под угрозой оказывается вся операционная деятельность. Разберём, чем заместить ушедшие платформы и как пройти миграцию без остановки бизнеса.
Что именно ушло и чем это грозит
Коммерческие ESB и iPaaS закрывали три задачи: маршрутизацию сообщений между системами, преобразование форматов и оркестрацию процессов. Облачные платформы добавляли готовые коннекторы и среду исполнения «как сервис». Уход вендоров бьёт по каждому уровню.
Лицензии перестают продлеваться – формально вы продолжаете работать, но без права на обновления и патчи. Это прямой риск безопасности: непропатченный интеграционный слой становится точкой входа для атаки, а их интенсивность за последние месяцы выросла кратно (мы разбирали это в материале про защиту от кибератак). Облачные iPaaS уязвимее вдвойне – отключение тенанта мгновенно обрывает все потоки, и резервной копии конфигурации на руках часто нет.
На что мигрировать
Готовый ответ есть: зрелые открытые брокеры и интеграционные движки, которые не зависят от санкционного режима.
- Apache Kafka – для событийной архитектуры и потоковой передачи больших объёмов с гарантией доставки.
- RabbitMQ – для классической очередей и маршрутизации сообщений там, где нужна гибкая логика обмена.
- Apache Camel – движок интеграционных маршрутов и трансформаций, по сути замена логики ESB с сотнями готовых компонентов.
Поверх них собирается шина под конкретный ландшафт: адаптеры к 1С, SAP, CRM, банковским системам и госшлюзам, единый реестр сервисов, мониторинг и трассировка. Это не «коробка», а проектируемая платформа, и здесь критична команда, которая владеет и брокерами, и предметной областью. Удержать таких инженеров сейчас сложнее, чем закупить железо, – об этом стоит думать заранее (см. удержание ИТ-команды).
Для госсектора и компаний с госучастием важен ещё один критерий – присутствие решения в реестре отечественного ПО. Шину на открытых компонентах можно собрать и зарегистрировать как российский продукт, что снимает регуляторные вопросы при закупках.
Как пройти миграцию без простоя
Переключать всё разом нельзя. Рабочая схема – параллельная работа старой и новой шины с поэтапным переносом потоков.
- Инвентаризация всех интеграций: источники, форматы, расписания, SLA.
- Развёртывание новой шины и реализация адаптеров для первой группы некритичных потоков.
- Дублирование трафика и сверка результатов старой и новой шины на реальных данных.
- Поочерёдное переключение потоков от низкорисковых к критичным, с возможностью отката.
- Вывод старой платформы из эксплуатации после полного переноса и стабилизации.
Такой подход растягивает проект на недели, но исключает разрыв обмена данными – а для производства, ритейла и финансов остановка шины измеряется прямыми убытками.
Вывод
Замещение iPaaS и ESB – не аварийная замена детали, а пересборка интеграционного контура на компонентах, которые останутся под контролем. Открытые брокеры закрывают всю функциональность ушедших платформ, а грамотная архитектура и поэтапная миграция убирают риск простоя. Начните с инвентаризации потоков – это покажет реальный объём работ и узкие места, а дальше шина проектируется и собирается под конкретный ландшафт поверх открытых брокеров.
