На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Недавно получил такой комментарий к одному из обзоров ESB: «Я считаю, что интеграционные платформы больше не нужны», а спустя время в Телеграм-сообществе «Шины не для машины» развернулась дискуссия на тему «Паттерн ESB безнадежно устарел». Решил собрать в одной статье популярные вопросы по теме и ответить на них.

Привожу самый первый комментарий, с которого все началось, в полном виде, орфография и пунктуация автора сохранены.

«Я считаю, что интеграционные платформы больше не нужны.

Положить в Кафку / получить из Кафки сообщение, я могу практически любой системой, включая 1С.

Разработка кастомных коннекторов понадобится любому крупному и сложному бизнесу, а другим такие платформы совсем не нужны.

В итоге:

• Стоимость интеграции увеличивается.

• Скорость интеграции увеличивается

А вендор, при всем уважении, продавая "мультитул", который позволяет все, подсаживает клиента на аутсорс по настройке своей платформы.

Закрытость кода, может привести к не интерпретируемым ошибкам в логах (как в Датареоне с кастомными коннекторами).

Возможно я не прав, но вы же не дадите демку. И документацию до покупки наверное тоже.

Один программист на GO быстро может организовать подключение к любой системе по любому протоколу, включая самые современные, а Кафка со своей отказоустойчивостью обеспечит гарантированную доставку сообщений».

Уже год я делаю обзоры на отечественные продукты, которые относятся к классу ESB: интеграционные шины, платформы и т. д. В реестре отечественного ПО таких решений больше 40. На деле тех, кто активно развивает и продвигает продукт, все же меньше. Я общаюсь с вендорами, прошу показать их разработку, а потом создаю обзор, который поможет тем, кто выбирает для своего проекта шину. Тема меня захватила так, что я даже создал Телеграм-сообщество «Шины не для машины».

При этом периодически в комментариях или даже на встречах с заказчиками звучат такие доводы, что, мол, для интеграций компании не нужна шина данных, будет достаточно брокера сообщений. Сегодня хочу встать на сторону тех продуктов, которые относятся к классу ESB. Возможно, для кого-то это будет звучать, как реклама отечественных шин данных, однако никаких названий давать не буду. Но как технический директор могу сказать, что изобретать велосипеды компаниям выходит гораздо накладнее. Ведь часто интеграцию можно настроить так, что управлять ею будет просто и удобно, а выйдет это даже дешевле, если сравнить затраты на кастомные разработки. Но обо всем по порядку.

Собрал самые популярные аргументы против ESB и подобных продуктов:

• Зачем нужна шина данных, у нас есть RabbitMQ или Apache Kafka.

• У нас своя самописная система, которая отлично работает.

• Мы не уверены, что нам нужна шина, ведь закрытость кода может привести к непонятным ошибкам в логах.

• ESB — устаревший паттерн.

Последовательно отвечу на каждый аргумент.

Зачем нужна шина данных, ведь есть RabbitMQ или Apache Kafka

Open source продукты, в отличие от проприетарных, всегда решают достаточно узкую задачу. Брокеры сообщений типа Kafka — хороший инструмент, чтобы передавать сообщения. Однако обычно у компаний стоит больше задач, которые они хотят решить с помощью интеграций. Преобразование данных, последовательность выполнения действий и т. д. Редко когда получается решить конечную задачу, используя один продукт. Обычно это целый набор: отдельно веб-сервер, отдельно брокер сообщений, отдельно система мониторинга и т. д. Все эти компоненты нужно изучить, протестировать, подружить между собой. Это как взять на разборке двигатель, навесное оборудование, проводку и мастерить автомобиль. Компоненты бесплатные, но нужна команда, чтобы все это грамотно собрать. Плюс есть риски багов, с которыми придется что-то делать. Безусловно, на open source можно собрать свою шину данных, большинство отечественных вендоров так и сделали, вопрос, сколько времени нужно потратить на сборку, тестирование. Вряд ли с первого раза получится хорошая система. Поэтому, даже если вам нравится какой-либо open source продукт (мне, например, нравится Apache NiFi), я все равно рекомендую обратиться к вендору, который умеет настраивать этот продукт, имеет компетенции по исправлению багов.

Вообще, тема «Брокеры VS ESB» достаточно глубокая, возможно, руки дойдут написать отдельную статью на эту тему. 

У нас своя самописная система, которая отлично работает

Однажды мы попали на проект с самописной шиной на базе 1С. Стандартная история, надо было соединить несколько баз, сделали для этого отдельную базу, создали справочник информационных систем и пошло поехало. Тут опцию надо добавить, тут файлы надо гонять, тут еще что-то. Архитектуру решения особо не проектировали, требования не собирали, делается же для себя, если что подпилим. Потом наступил кадровый голод, допиливать некому, обратились к нам. Мы вдвоем с ведущим разработчиком два дня изучали эту систему. Задача вроде не сложная была, но чтобы понять, как оно работает, нужно потратить много времени. 

Недавно в нашем сообществе, посвященном российским ESB, обсуждали самописные системы. Вот несколько комментариев от экспертов со стороны вендоров:

«Ни разу нормальных самописных клиентских шин не видел, потому что всегда идут от текущих потребностей, без оглядки на архитектуру и методологию, а с расширением функционала неизбежно утыкаются в архитектурные проблемы и начинают костылить»

«типичная ситуация: клиент выращивает шину у себя в контуре; потом её содержит в одно лицо; потом все страдают потому , что концов с концами не свести, устаёт это делать; и наконец выпиливает сие коллективное творчество и ставит нормальное коммерческое решение»

К сожалению, так это в большинстве случаев и работает: систему создает команда, которая может поменяться, тогда начинаются вопросы. Хотя они могут возникнуть и раньше, потому что поддерживать такой продукт довольно сложно. К тому же в компании, которая не специализируется на ИТ, ресурс на разработку выделить объективно сложнее. И в пересчете, так ли дорого выйдет решение от вендора?

Закрытость кода может привести к непонятным ошибкам в логах

Да, баги случаются, это нужно честно признать. Они не могут не случаться просто из-за маленького рынка и, как следствие, небольшого количества внедрений и малого количества обратной связи от потребителя к производителю. К слову, кроме ESB мы занимаемся разработкой аналитических витрин, в сегменте BI наблюдаю примерно ту же ситуацию. 

Важно, как быстро вендор реагирует на баги, есть ли практика хотфиксов или нужно ждать следующий релиз для исправления.

ESB — устаревший паттерн

Недавно в нашем Телеграм-сообществе «Шины не для машины» обсуждали мнение, что ESB (паттерн Enterprise Service Bus) — это легаси, пережиток 2000-х, который не соответствует модным микросервисным подходам. Но если вникнуть в суть, сам паттерн ESB остается актуальным, просто сегодня он должен строиться иначе.

Где ESB все еще незаменим

• Сложные интеграционные цепочки: если вам надо варить кашу из XML, JSON, SOAP, CSV, шифровать, подписывать и логировать по гостам — ESB сильнее самописных решений.

• B2B-интеграции и регуляторы: когда диктуются протоколы и форматы, быстрее и дешевле обернуть интеграцию в ESB.

• Легаси и коробки: если на одном конце интеграции старая инфраструктура или коробочные системы с неудобными API (читай: все учетные системы), удобнее и быстрее воспользоваться ESB, чем писать свое решение.

Почему впечатление о старении ESB ложное

• Образ монолитной централизованной шины действительно устарел. Но сегодня ESB может работать как сеть легковесных модулей, запущенных в микросервисной среде.

• Современные ESB-платформы ставят на self-service для команд, CI/CD, обзорность и стандарты, а не на централизованную фабрику интеграций.

• Сам паттерн обмена, обработки и маршрутизации данных никуда не делся, он просто эволюционировал.

Вывод

Паттерн ESB не утратил своей актуальности, но, как и любой инструмент, требует грамотного применения и эволюции в соответствии с современными архитектурными подходами. Там, где интеграция сложна или стандарты диктуются извне, ESB по-прежнему остается эффективным выбором. 

Приглашаю в сообщество «Шины не для машины», там обсуждаем насущные вопросы рынка ESB.