Привожу самый первый комментарий, с которого все началось, в полном виде, орфография и пунктуация автора сохранены.
Я считаю, что интеграционные платформы больше не нужны.
Положить в Кафку / получить из Кафки сообщение, я могу практически любой системой, включая 1С.
Разработка кастомных коннекторов понадобится любому крупному и сложному бизнесу, а другим такие платформы совсем не нужны.
В итоге:
А вендор, при всем уважении, продавая "мультитул", который позволяет все, подсаживает клиента на аутсорс по настройке своей платформы.
Закрытость кода, может привести к не интерпретируемым ошибкам в логах (как в Датареоне с кастомными коннекторами).
Возможно я не прав, но вы же не дадите демку. И документацию до покупки наверное тоже.
Один программист на GO быстро может организовать подключение к любой системе по любому протоколу, включая самые современные, а Кафка со своей отказоустойчивостью обеспечит гарантированную доставку сообщений.
Уже год я делаю обзоры на отечественные продукты, которые относятся к классу ESB: интеграционные шины, платформы и т. д. В реестре отечественного ПО таких решений больше 40. На деле тех, кто активно развивает и продвигает продукт, все же меньше. Я общаюсь с вендорами, прошу показать их разработку, а потом создаю обзор, который поможет тем, кто выбирает для своего проекта шину. Тема меня захватила так, что я даже создал Телеграм-сообщество «Шины не для машины».
При этом периодически в комментариях или даже на встречах с заказчиками звучат такие доводы, что, мол, для интеграций компании не нужна шина данных, будет достаточно брокера сообщений. Сегодня хочу встать на сторону тех продуктов, которые относятся к классу ESB. Возможно, для кого-то это будет звучать, как реклама отечественных шин данных, однако никаких названий давать не буду. Но как технический директор могу сказать, что изобретать велосипеды компаниям выходит гораздо накладнее. Ведь часто интеграцию можно настроить так, что управлять ею будет просто и удобно, а выйдет это даже дешевле, если сравнить затраты на кастомные разработки. Но обо всем по порядку.
Собрал самые популярные аргументы против ESB и подобных продуктов:
Последовательно отвечу на каждый аргумент.
Open source продукты, в отличие от проприетарных, всегда решают достаточно узкую задачу. Брокеры сообщений типа Kafka — хороший инструмент, чтобы передавать сообщения. Однако обычно у компаний стоит больше задач, которые они хотят решить с помощью интеграций. Преобразование данных, последовательность выполнения действий и т. д. Редко когда получается решить конечную задачу, используя один продукт. Обычно это целый набор: отдельно веб-сервер, отдельно брокер сообщений, отдельно система мониторинга и т. д. Все эти компоненты нужно изучить, протестировать, подружить между собой. Это как взять на разборке двигатель, навесное оборудование, проводку и мастерить автомобиль. Компоненты бесплатные, но нужна команда, чтобы все это грамотно собрать. Плюс есть риски багов, с которыми придется что-то делать. Безусловно, на open source можно собрать свою шину данных, большинство отечественных вендоров так и сделали, вопрос, сколько времени нужно потратить на сборку, тестирование. Вряд ли с первого раза получится хорошая система. Поэтому, даже если вам нравится какой-либо open source продукт (мне, например, нравится Apache NiFi), я все равно рекомендую обратиться к вендору, который умеет настраивать этот продукт, имеет компетенции по исправлению багов.
Вообще, тема «Брокеры VS ESB» достаточно глубокая, возможно, руки дойдут написать отдельную статью на эту тему.
Однажды мы попали на проект с самописной шиной на базе 1С. Стандартная история, надо было соединить несколько баз, сделали для этого отдельную базу, создали справочник информационных систем и пошло поехало. Тут опцию надо добавить, тут файлы надо гонять, тут еще что-то. Архитектуру решения особо не проектировали, требования не собирали, делается же для себя, если что подпилим. Потом наступил кадровый голод, допиливать некому, обратились к нам. Мы вдвоем с ведущим разработчиком два дня изучали эту систему. Задача вроде не сложная была, но чтобы понять, как оно работает, нужно потратить много времени.
Недавно в нашем сообществе, посвященном российским ESB, обсуждали самописные системы. Вот несколько комментариев от экспертов со стороны вендоров:
«Ни разу нормальных самописных клиентских шин не видел, потому что всегда идут от текущих потребностей, без оглядки на архитектуру и методологию, а с расширением функционала неизбежно утыкаются в архитектурные проблемы и начинают костылить»
«типичная ситуация: клиент выращивает шину у себя в контуре; потом её содержит в одно лицо; потом все страдают потому , что концов с концами не свести, устаёт это делать; и наконец выпиливает сие коллективное творчество и ставит нормальное коммерческое решение»
К сожалению, так это в большинстве случаев и работает: систему создает команда, которая может поменяться, тогда начинаются вопросы. Хотя они могут возникнуть и раньше, потому что поддерживать такой продукт довольно сложно. К тому же в компании, которая не специализируется на ИТ, ресурс на разработку выделить объективно сложнее. И в пересчете, так ли дорого выйдет решение от вендора?
Да, баги случаются, это нужно честно признать. Они не могут не случаться просто из-за маленького рынка и, как следствие, небольшого количества внедрений и малого количества обратной связи от потребителя к производителю. К слову, кроме ESB мы занимаемся разработкой аналитических витрин, в сегменте BI наблюдаю примерно ту же ситуацию.
Важно, как быстро вендор реагирует на баги, есть ли практика хот фиксов или нужно ждать следующий релиз для исправления.
Недавно в нашем Телеграм-сообществе «Шины не для машины» обсуждали мнение, что ESB (паттерн Enterprise Service Bus) — это легаси, пережиток 2000-х, который не соответствует модным микросервисным подходам. Но если вникнуть в суть, сам паттерн ESB остается актуальным, просто сегодня он должен строиться иначе.
Где ESB все еще незаменим
Почему впечатление о старении ESB ложное
Паттерн ESB не утратил своей актуальности, но, как и любой инструмент, требует грамотного применения и эволюции в соответствии с современными архитектурными подходами. Там, где интеграция сложна или стандарты диктуются извне, ESB по-прежнему остается эффективным выбором.
Вступайте в сообщество в Телеграме «Шины не для машины», там обсуждаем насущные вопросы рынка ESB.
Похожие статьи
