PD
А есть ссылка на описание концепта? Ну и, традиционно, а что там с гарантиями )
Size: a a a
2020 November 20
PD
А то будет, как с service mesh - идея хорошая, но не работает в нагруженной среде (
GK
А есть ссылка на описание концепта? Ну и, традиционно, а что там с гарантиями )
Можно погулить) Ссылки на источник, который можно назвать авторитетным я и сам хотел попросить)
GK
Меня зацепил один слайд, с таким содержанием:
Characteristics:
• Event Catalogue is used to Design
and Runtime Governance
• ACLs Enforced, and and Stats are
retrieved
• Data Lineage
Characteristics:
• Event Catalogue is used to Design
and Runtime Governance
• ACLs Enforced, and and Stats are
retrieved
• Data Lineage
PD
Ну, вот Event Catalogue - это да, этого не хватает. Особенно с возможностью задания или хотя бы мониторинга отправителей и получателей.
GK
То есть, даже если и не случится чудес с бесшовной интеграцией брокеров)) каталог ивентов и lineage ивентов точно будет полезен. Хотя задачу lineage можно решить и с помощью трассировки.
p
Alexander Bukarev
https://lightstreamer.com я вот это решение пару лет назад смотрел, сделали PoC, по нагрузке посмотрели, всё отлично. Ценовая модель у них только раньше у них была очень не гибкая, потому в итоге пришлось отказаться. Сейчас, насколько вижу, сделали в т.ч. тарификацию по человеко-часам уже. Так что могу рекомендовать как минимум посмотреть. Документация внятная, возможности ровно под вашу задачу, как я понимаю.
А вот что бы вы стали делать если после внедрения возникнут проблемы? Вроде того что каким-то клиентам не доставляются сообщения?
GK
Как я вижу:
- контракт в событийно-ориентированной архитектуре (EDA) - это формат сообщения и канал его доставки (топик)
- всегда нужно организовывать Governance, в том числе обеспечить поиск контрактов
- сейчас видно только один способ учёта контрактов в EDA - портал со стандартной структурой и дисциплина
- контракт в событийно-ориентированной архитектуре (EDA) - это формат сообщения и канал его доставки (топик)
- всегда нужно организовывать Governance, в том числе обеспечить поиск контрактов
- сейчас видно только один способ учёта контрактов в EDA - портал со стандартной структурой и дисциплина
GK
Буду рад, если дополните эту картину мира
GK
Также хочу поделиться карточкой-опросником, которая может помочь восстановить дизайн решения. Буду рад обратной связи.
GK
Из опыта. Разработчики такие карточки обычно заполнить не могут, потому что оказывается, что дизайна нет.
При этом, разработчики показывают чудеса изворотливости, придумывают оправдания, вешают лапшу на уши руководству, открыто саботируют процесс.
Конечно можно холиварить, что дизайн есть всегда, но он может быть неявным. На самом деле, если дизайном никто системно не занимается, то можно сказать, что его нет. Он настолько неявный, что "оцифровать" его практически невозможно.
При этом, разработчики показывают чудеса изворотливости, придумывают оправдания, вешают лапшу на уши руководству, открыто саботируют процесс.
Конечно можно холиварить, что дизайн есть всегда, но он может быть неявным. На самом деле, если дизайном никто системно не занимается, то можно сказать, что его нет. Он настолько неявный, что "оцифровать" его практически невозможно.
GK
Из наблюдений, самый комфортный режим для многих разработчиков - не_мешайте_просто_херачить
A
Из наблюдений, самый комфортный режим для многих разработчиков - не_мешайте_просто_херачить
вас обманули, это не разработчики
GK
вас обманули, это не разработчики
ок, активные участники рынка разработки, продающие свои услуги за некислые деньги
D
У нас что-то такое заполняется перед очередным проектом миграции. Только более абстрактно - без полей типа API, но с полями про чей бюджет, например. Практика правда показывает, что даже RPO/RTO не всегда могут заполнить, не говоря уже о количестве запросов в секунду
GK
У нас что-то такое заполняется перед очередным проектом миграции. Только более абстрактно - без полей типа API, но с полями про чей бюджет, например. Практика правда показывает, что даже RPO/RTO не всегда могут заполнить, не говоря уже о количестве запросов в секунду
Да. Кстати, в шаблоне не хватает владельцев (кто платит) и вообще, стейкхолдеров
PD
Из опыта. Разработчики такие карточки обычно заполнить не могут, потому что оказывается, что дизайна нет.
При этом, разработчики показывают чудеса изворотливости, придумывают оправдания, вешают лапшу на уши руководству, открыто саботируют процесс.
Конечно можно холиварить, что дизайн есть всегда, но он может быть неявным. На самом деле, если дизайном никто системно не занимается, то можно сказать, что его нет. Он настолько неявный, что "оцифровать" его практически невозможно.
При этом, разработчики показывают чудеса изворотливости, придумывают оправдания, вешают лапшу на уши руководству, открыто саботируют процесс.
Конечно можно холиварить, что дизайн есть всегда, но он может быть неявным. На самом деле, если дизайном никто системно не занимается, то можно сказать, что его нет. Он настолько неявный, что "оцифровать" его практически невозможно.
Ну, у меня разработчики пишут design review перед кодированием и сами меняют карточки сервисов при необходимости (конфигурация, связи и т.п.).
Так что смотря как с разработчиками говорить )
Так что смотря как с разработчиками говорить )
GK
Ну, у меня разработчики пишут design review перед кодированием и сами меняют карточки сервисов при необходимости (конфигурация, связи и т.п.).
Так что смотря как с разработчиками говорить )
Так что смотря как с разработчиками говорить )
Тоже верно. Вопрос в том, где место ревьювера в орг структуре и какие у него полномочия
PD
Ну, это да )