Комментарии 14
Шина как панацея всему. Как это знакомо.
В одном банке «О». Изначальные архитекторы (команда поменялась полностью за 3 года на 2 круга) настояли на использовании шины для всего. «Ну это же архитектурно круто!» говорили они. «А вдруг эти данные понадобятся где то еще» говорили они. Шина это круть (IBM WSMQ).
А особенно круто нам пришлось помучится с стыковкой синхронного протокола с таймаутами (когда ответ через N ms уже никто не ждет. Клиент давно отошел от терминала и пр.) с этой шиной.
И до сих пор у банка «А где ответ на запрос то?» -> «А мы не знаем… не можем найти какая шина куда отдала и кому вообще».
А где то эти архитекторы и идеологи уже в новом месте работают и хвалятся своим «портфелио» о внедрении крутой рАхитектуры.
В одном банке «О». Изначальные архитекторы (команда поменялась полностью за 3 года на 2 круга) настояли на использовании шины для всего. «Ну это же архитектурно круто!» говорили они. «А вдруг эти данные понадобятся где то еще» говорили они. Шина это круть (IBM WSMQ).
А особенно круто нам пришлось помучится с стыковкой синхронного протокола с таймаутами (когда ответ через N ms уже никто не ждет. Клиент давно отошел от терминала и пр.) с этой шиной.
И до сих пор у банка «А где ответ на запрос то?» -> «А мы не знаем… не можем найти какая шина куда отдала и кому вообще».
А где то эти архитекторы и идеологи уже в новом месте работают и хвалятся своим «портфелио» о внедрении крутой рАхитектуры.
Главное заблуждение при внедрении шины, это то что можно избежать комбинаторного взрыва при интеграции.
Все внедренные шины, которые я наблюдал, никогда эту задачу не решали и решить не могли.
Для чего шина более-менее подходит это только для логирования. Уже с мониторингом начинаются проблемы.
Все внедренные шины, которые я наблюдал, никогда эту задачу не решали и решить не могли.
Для чего шина более-менее подходит это только для логирования. Уже с мониторингом начинаются проблемы.
Главное заблуждение при внедрении шины, это то что можно избежать комбинаторного взрыва при интеграции.Честно говоря, я не вижу, каким образом при правильном применении ESB можно получить комбинаторный взрыв. На практике с таким не сталкивался.
С микросервисами — многократно, с ESB — нет.
Можете в общих чертах описать кейс, пожалуйста?
Я все время слышу про «правильное» применение ESB и никто за почти 10 лет так и не привел примера «правильного» применения ESB.
Вот простой пример.
Нужна интеграция между A (сервер) и B (клиент).
Без ESB (E). Пишем сервер А и клиент В.
При ESB — пишем сервер А, клиент Е, сервер Е, клиент В.
Нужна интеграция между А (сервер) и С (клиент).
Вроде бы нужно написать только клиента в Е-серверу.
А вот и нет. Т.к. Для с С другой БП, нужны другие данные, нужна другая реакция на ошибки и т.д.
Что нужно сделать?
Опять пишем сервера на А для Е(С), потом клиент Е(С), потом сервер Е(С), потом клиента С(Е).
И так для любой интеграции.
ESB всегда превращается в прослойку, которая мешает и никогда не выполняет те функции которые декларирует.
В лучшем случае это централизованное хранилище логов интеграции.
Вот простой пример.
Нужна интеграция между A (сервер) и B (клиент).
Без ESB (E). Пишем сервер А и клиент В.
При ESB — пишем сервер А, клиент Е, сервер Е, клиент В.
Нужна интеграция между А (сервер) и С (клиент).
Вроде бы нужно написать только клиента в Е-серверу.
А вот и нет. Т.к. Для с С другой БП, нужны другие данные, нужна другая реакция на ошибки и т.д.
Что нужно сделать?
Опять пишем сервера на А для Е(С), потом клиент Е(С), потом сервер Е(С), потом клиента С(Е).
И так для любой интеграции.
ESB всегда превращается в прослойку, которая мешает и никогда не выполняет те функции которые декларирует.
В лучшем случае это централизованное хранилище логов интеграции.
Так ведь главное преимущество ESB — наличие огромного множества коннекторов ко всему подряд. Ничего писать не надо, оно уже есть из коробки, только настраивай потоки (поля, если необходимо, трансформацию, обогащение), обычно этим занимается системный аналитик.
Даже если нужно написать новый коннектор, это делается однократно, а не для каждого взаимодействия отдельно.
Возможно, я не прав, но могу предположить, как такое получилось. У человека, который управляет ESB (это роль не столько техническая, сколько управленческая: общаться и договариваться), не хватило полномочий, чтобы продавить «правильное» применение ESB. Грустная ситуация.
Даже если нужно написать новый коннектор, это делается однократно, а не для каждого взаимодействия отдельно.
Опять пишем сервера на А для Е(С), потом клиент Е(С), потом сервер Е(С), потом клиента С(Е).
Возможно, я не прав, но могу предположить, как такое получилось. У человека, который управляет ESB (это роль не столько техническая, сколько управленческая: общаться и договариваться), не хватило полномочий, чтобы продавить «правильное» применение ESB. Грустная ситуация.
Вот-вот. Мне так и отвечают.
Какие коннекторы?
К БД вам полный доступ не дадут, только к определенной выгрузке.
Ибо нефиг.
К другим ИС, типа ЕРП, CRM и прочее — так же.
И можно пример «правильного» применения ESB.
Пока только слова и маркетинговый булшит о внедрении на тысячи предприятий.
И ни слова о реальной эксплуатации.
Какие коннекторы?
К БД вам полный доступ не дадут, только к определенной выгрузке.
Ибо нефиг.
К другим ИС, типа ЕРП, CRM и прочее — так же.
И можно пример «правильного» применения ESB.
Пока только слова и маркетинговый булшит о внедрении на тысячи предприятий.
И ни слова о реальной эксплуатации.
Какие коннекторы?Набор скриптов, обеспечивающих преобразование информации из 100500 разных форматов в требуемый для ESB.
К БД вам полный доступ не дадут, только к определенной выгрузке.Не хочется выступать в роли К.О., но это говорит, что за изменения взялся человек без нужных полномочий. Вряд ли проекты уровня внедрения ESB вообще могут быть реализованы без поддержки топ-менеджмента компании. А в этом случае не бывает аргументов, типа «мы вам то-то не дадим». Что потребуется, то и дадут.
И можно пример «правильного» применения ESB.Если вопрос про мой личный опыт, могу привести примеры в ЛС.
Ага набор скриптов, которые не походят ни к одной реальной ситуации.
Поэтому приходиться все писать ручками. :-)
Вам дают сервис SOAP, или выгрузки, вплоть до xls, которые надо отдать другому сервису.
Каких полномочий?
Это требование ИБ. Что, например, АБС отдает вовне только ту информацию, которую можно отдавать. Никто не будет давать к реальной БД доступ. Только к некоторой «промежуточной» БД.
Иначе будет считаться что данные могут быть скомпрометированы.
Ну или ESB, нужно будет сертифицировать как АБС. :-)
Другой случай когда у вас распределенные ИС, общающиеся между собой по interent.
Сейчас частый кейс.
Когда ESB внутри интрасети, то ещё оно как-то работает.
Если между…
Хотя бы назовите просто парочку компаний, не под NDA.
Потому что везде, где я работал с ESB это был геморрой, который приходилось героически преодолевать.
И хорошо если ESB была одна. А то их могло быть и две и три.
И да, как решает ESB интеграцию трех ИС А, В и С.
Если нет прямого доступа к БД, а есть только soap-сервисы. :-)
Поэтому приходиться все писать ручками. :-)
Вам дают сервис SOAP, или выгрузки, вплоть до xls, которые надо отдать другому сервису.
Каких полномочий?
Это требование ИБ. Что, например, АБС отдает вовне только ту информацию, которую можно отдавать. Никто не будет давать к реальной БД доступ. Только к некоторой «промежуточной» БД.
Иначе будет считаться что данные могут быть скомпрометированы.
Ну или ESB, нужно будет сертифицировать как АБС. :-)
Другой случай когда у вас распределенные ИС, общающиеся между собой по interent.
Сейчас частый кейс.
Когда ESB внутри интрасети, то ещё оно как-то работает.
Если между…
Хотя бы назовите просто парочку компаний, не под NDA.
Потому что везде, где я работал с ESB это был геморрой, который приходилось героически преодолевать.
И хорошо если ESB была одна. А то их могло быть и две и три.
И да, как решает ESB интеграцию трех ИС А, В и С.
Если нет прямого доступа к БД, а есть только soap-сервисы. :-)
Любую здравую идею можно довести до абсурда. А в случае полной смены команды риски возрастают многократно.
У меня есть опыт успешных применений ESB, лишённых описываемых вами проблем. Работать над этим пришлось, конечно, много. Затраты превысили десяток человеко-лет. В самом объёмном примере в контуре больше 20 систем и 400 сущностей.
Судя по всему, в этом и заключается проблема. Пытались решать?
У меня есть опыт успешных применений ESB, лишённых описываемых вами проблем. Работать над этим пришлось, конечно, много. Затраты превысили десяток человеко-лет. В самом объёмном примере в контуре больше 20 систем и 400 сущностей.
И до сих пор у банка «А где ответ на запрос то?» -> «А мы не знаем… не можем найти какая шина куда отдала и кому вообще».
Судя по всему, в этом и заключается проблема. Пытались решать?
ощущение, что текст написан из узбекистана или еще более продвинутой страны, где бигдата в 2021 году еще хайп, а не обязательный инструмент любой фин организации. в наших краях думаю уже нет банка или финтеха без чего-то аля хадуп. и хранят/считают они там, что характерно свои структурированные фин данные, и не превращаются в болото, и выполняют GDPR, т.е. четко отслеживая, где и какие данные и когда они должны быть анонимизированны.
ощущение, что автор не видел реальных ентерпрайзов и насмотревшись чего-то смешного в узбекистане спроецировал на всю индустрию.
ощущение, что автор не видел реальных ентерпрайзов и насмотревшись чего-то смешного в узбекистане спроецировал на всю индустрию.
Ждал этот комментарий, спасибо :)
Какая там, в финтеке, Big data, обычный матан и матстат. Навёрнуты тонны костылей, чтобы реализовать тривиальные алгоритмы, многие из которых остаются неизменны со времён фортрана. И толпа аналитиков, которые пытаются в этом болоте что-то выудить, совсем как в заглавной картинке. Она неспроста стала мемом.
бигдата в 2021 году еще хайп, а не обязательный инструментБлагодаря вашему посту могу добавить ещё один критерий в список — оперирование широкими и заведомо неконкретными понятиями.
Какая там, в финтеке, Big data, обычный матан и матстат. Навёрнуты тонны костылей, чтобы реализовать тривиальные алгоритмы, многие из которых остаются неизменны со времён фортрана. И толпа аналитиков, которые пытаются в этом болоте что-то выудить, совсем как в заглавной картинке. Она неспроста стала мемом.
в узбекистане еще и алгоритмы изобретают? хорошие у вас урожаи.
бигдата в финтеке это в первую очередь data lake на файликах hdfs/s3, анализ с применением обучаемых алгоритмов хоть и идет следом, но математики там давно нет. весь science давно упрятан в ML фреймворки, от аналитика требуется лишь в нужной последовательности дернуть методы.
бигдата в финтеке это в первую очередь data lake на файликах hdfs/s3, анализ с применением обучаемых алгоритмов хоть и идет следом, но математики там давно нет. весь science давно упрятан в ML фреймворки, от аналитика требуется лишь в нужной последовательности дернуть методы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создаём компанию мечты: нет хайпу