Size: a a a

Архитектура ИТ-решений

2020 August 25

VU

Vitaly U in Архитектура ИТ-решений
Это обработка формата
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
И что?
источник

VU

Vitaly U in Архитектура ИТ-решений
Gennadiy Kruglov
При интеграции, другое дело. Компоненты независимы. То есть их дизайн выполнятся в разных контекстах, это могут быть вообще разные продукты.
Так речь про самостоятельные системы
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Vitaly U
Так речь про самостоятельные системы
Тогда это интеграция. Мы уже решили, что это всегда - миддл
источник

VU

Vitaly U in Архитектура ИТ-решений
Gennadiy Kruglov
Тогда это интеграция. Мы уже решили, что это всегда - миддл
Ну я же о том же
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Вопрос, что значит самостоятельные системы?
источник

VU

Vitaly U in Архитектура ИТ-решений
Gennadiy Kruglov
Вопрос, что значит самостоятельные системы?
Это значит, что они могут функционировать вне текущего ландшафта
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Vitaly U
Это значит, что они могут функционировать вне текущего ландшафта
Хорошее определение. Тогда - однозначно миддл
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
В контексте интеграции, это компоненты, повлиять на развитие которых не представляется возможным.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Хочу добавить. Разрастание интеграционного слоя обычно свидетельствует о разрые коммуникаций между командами и/или пробелах в архитектурной работе. По закону Конвея, если коммуникации между командами нет, то и между компонентами, которые они разрабатывают, взаимодействия не будет.

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

А все критикуют ESB, потому что "софтину" ругать безопасно.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Главный недостаток ESB в том, что предоставляя богатые возможности для интеграции, она способствует маскированию проблем в коммуникациях и архитектурной работе. В какой-то момент эти проблемы накапливаются в самой ESB.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Наши предшественники из эпохи SOA (SOA School) интуитивно это понимали и говорили:
- не нужно путать взаимодействие и интеграцию
- нужно избегать интеграции везде, где это возможно
- ESB - это лишь один из паттернов SOA, SOA нельзя отождествлять с ESB

Но вендорам нужно было продавать ESB, как сейчас им нужно продавать клауд. Поэтому они внушили SOA = ESB, а сейчас Микросервисы = Контейнеры = Cloud Native
источник

VU

Vitaly U in Архитектура ИТ-решений
Gennadiy Kruglov
Главный недостаток ESB в том, что предоставляя богатые возможности для интеграции, она способствует маскированию проблем в коммуникациях и архитектурной работе. В какой-то момент эти проблемы накапливаются в самой ESB.
Полностью согласен
источник

VU

Vitaly U in Архитектура ИТ-решений
Gennadiy Kruglov
Наши предшественники из эпохи SOA (SOA School) интуитивно это понимали и говорили:
- не нужно путать взаимодействие и интеграцию
- нужно избегать интеграции везде, где это возможно
- ESB - это лишь один из паттернов SOA, SOA нельзя отождествлять с ESB

Но вендорам нужно было продавать ESB, как сейчас им нужно продавать клауд. Поэтому они внушили SOA = ESB, а сейчас Микросервисы = Контейнеры = Cloud Native
Полностью согласен х2
источник

VU

Vitaly U in Архитектура ИТ-решений
Gennadiy Kruglov
Наши предшественники из эпохи SOA (SOA School) интуитивно это понимали и говорили:
- не нужно путать взаимодействие и интеграцию
- нужно избегать интеграции везде, где это возможно
- ESB - это лишь один из паттернов SOA, SOA нельзя отождествлять с ESB

Но вендорам нужно было продавать ESB, как сейчас им нужно продавать клауд. Поэтому они внушили SOA = ESB, а сейчас Микросервисы = Контейнеры = Cloud Native
Немнож поломаю, мы с редхатлм сделали интресную концепцию (для пресловутой нефтянки), концепцию микроесб
источник

VU

Vitaly U in Архитектура ИТ-решений
Когда функционал сосредоточивается для одного сервиса/взаимодействия
источник

VU

Vitaly U in Архитектура ИТ-решений
И таких сервисов под каждое применение
источник

VU

Vitaly U in Архитектура ИТ-решений
Без единой шины
источник

VU

Vitaly U in Архитектура ИТ-решений
Тысячи шин, иысячи сервисов
источник

VU

Vitaly U in Архитектура ИТ-решений
Unbreakable конструкция
источник