Как выбрать паттерн интеграции?
Это любимый вопрос аналитика. И его можно понять, ибо ставя задачу на разработку и не понимая, как принимаются решения, сложно контролировать и принимать результат работы. Чувство не самое приятное, ты в команде, но почему так сделали непонятно.
➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷♀ Действительно, часто нет логического чёткого объяснения почему так.Потому что наш директор поехал на презентацию, там выпил водки и купил лицензию по шине, а теперь нам с ней работать. Занавес.
➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.
➡️ Дальше, самый сок, когда ты думаешь, ну вот сейчас будет шина, а вот тут брокер. Но приходит партнёр и говорит - у нас нет разработчиков, и вообще мы, уходя на выходные, выключаем сервер. У нас был такой кейс. И тут кроме интеграции через электронную почту, у нас не было больше никаких других вариантов. Даже с файлами они не хотели работать.
➡️ И если включать здравый смысл и логику, то нужно исходить из бизнес требований, нефункциональных требований, объёма передачи данных, масштабирования, развития компании, ИТ-ландшафта, ограничений бюджета,и конечно сотрудников.
Какие есть Паттерны?
По способу передачи данных:
Обмен данных с помощью
✅ файлов
✅ общей базы данных - это антипаттерны интеграции, от них лучше уходить.
Те кто хоть раз подобные паттерны пытался поддерживать в продуктиве могут рассказать множество замечательных историй, про седые волосы и бессонные ночи.
И остаётся чаще всего применяемые паттерны -
✅ удалённый вызов процедур
✅ обмен сообщениями (шина, брокер).
Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.
Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).
Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.
Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.
Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.
В реальности в ИТ-ландшафте компаний можно встретить гибрид из всех паттернов интеграции по способу передачи данных.
И каждый из них имеет свои плюсы и минусы, применимость в конкретных случаях, среде.
И кажется, что в айти всё логично, и есть обоснование всему, что происходит. Но нет. Часто скрытых смыслов и большого пути принятия решений попросту нет.
Подробнее про проектирование интеграционных решений вы можете узнать на нашем курсе, старт потока уже в этот четверг 16 ноября.
Почитать про курс можно вот тут➡️ sup.expert
#курсинтеграции #курс #системныйанализ #паттерныинтеграции
⚡️ Остались вопросы или вы хотите записаться, пишите напрямую мне))
Это любимый вопрос аналитика. И его можно понять, ибо ставя задачу на разработку и не понимая, как принимаются решения, сложно контролировать и принимать результат работы. Чувство не самое приятное, ты в команде, но почему так сделали непонятно.
➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷♀ Действительно, часто нет логического чёткого объяснения почему так.
➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.
➡️ Дальше, самый сок, когда ты думаешь, ну вот сейчас будет шина, а вот тут брокер. Но приходит партнёр и говорит - у нас нет разработчиков, и вообще мы, уходя на выходные, выключаем сервер. У нас был такой кейс. И тут кроме интеграции через электронную почту, у нас не было больше никаких других вариантов. Даже с файлами они не хотели работать.
➡️ И если включать здравый смысл и логику, то нужно исходить из бизнес требований, нефункциональных требований, объёма передачи данных, масштабирования, развития компании, ИТ-ландшафта, ограничений бюджета,и конечно сотрудников.
Какие есть Паттерны?
По способу передачи данных:
Обмен данных с помощью
✅ файлов
✅ общей базы данных - это антипаттерны интеграции, от них лучше уходить.
Те кто хоть раз подобные паттерны пытался поддерживать в продуктиве могут рассказать множество замечательных историй, про седые волосы и бессонные ночи.
И остаётся чаще всего применяемые паттерны -
✅ удалённый вызов процедур
✅ обмен сообщениями (шина, брокер).
Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.
Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).
Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.
Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.
Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.
В реальности в ИТ-ландшафте компаний можно встретить гибрид из всех паттернов интеграции по способу передачи данных.
И каждый из них имеет свои плюсы и минусы, применимость в конкретных случаях, среде.
И кажется, что в айти всё логично, и есть обоснование всему, что происходит. Но нет. Часто скрытых смыслов и большого пути принятия решений попросту нет.
Подробнее про проектирование интеграционных решений вы можете узнать на нашем курсе, старт потока уже в этот четверг 16 ноября.
Почитать про курс можно вот тут
#курсинтеграции #курс #системныйанализ #паттерныинтеграции
Please open Telegram to view this post
VIEW IN TELEGRAM
Паттерны интеграций (технологии передачи данных)
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии