d
Измеримость нужна, без нее не понять стало ли лучше от изменений
Size: a a a
2020 February 25
IB
И где вы видите "пользователей данных"?
AG
FYI: Александр Поломодов выложил обзор “Fundamentals of Software Architecture”:
https://medium.com/@alexanderpolomodov/%D0%BE%D0%B1%D0%B7%D0%BE%D1%80-fundamentals-of-software-architecture-1754c0e78d48
https://medium.com/@alexanderpolomodov/%D0%BE%D0%B1%D0%B7%D0%BE%D1%80-fundamentals-of-software-architecture-1754c0e78d48
книга только в феврале вышла, видимо захватила автора статьи, что аж разбор написал тоже быстро
AK
Кстати, про стили. А что там так ругают Orchestration Driven Service Oriented?
преположу что из-за того, что для оркестрации нужен оркестратор, а вот это уже проблема, нормальный оркестратор очень сложно найти. есть либо bpmn-ки всякие (что немного другое и перфоманса от них не жди), либо полуживые проекты, либо дикая муть с настолько бесноватыми настройками и UX, что проще руками всё написать, чем туда залазить.
PD
Ну, нормальный оркестратор не очень сложно и написать )
Да и их уже много. Cadence, наверно, сложно назвать нормальным (с точки зрения ops-ов), но для разработки вполне.
И он как раз и про fault tolerance и про производительность и много про что еще.
Да и их уже много. Cadence, наверно, сложно назвать нормальным (с точки зрения ops-ов), но для разработки вполне.
И он как раз и про fault tolerance и про производительность и много про что еще.
AK
Ну, нормальный оркестратор не очень сложно и написать )
Да и их уже много. Cadence, наверно, сложно назвать нормальным (с точки зрения ops-ов), но для разработки вполне.
И он как раз и про fault tolerance и про производительность и много про что еще.
Да и их уже много. Cadence, наверно, сложно назвать нормальным (с точки зрения ops-ов), но для разработки вполне.
И он как раз и про fault tolerance и про производительность и много про что еще.
только типовый тырпрайз очень не любит писать подобные компоненты систем, настолько, что готовы использовать даже data power какой-нибудь в роли оркестратора или камунду
PD
Типовой - это какой?
PD
В моем опыте комунда появилось только тогда, когда заказчик хотел в UI двигать процессы (все равно не смог, но в требования попало)
AK
Типовой - это какой?
банк, например или иная крупная контора, чей род деятельности не связан и ит. там мало пишут своего софта в принципе, и доверяют только коммерческим решениям вендоров (в большинстве случаев), не дай бог ещё микросервис запустишь - давай деплой на вебсферу или иной апп.сервер.
AK
В моем опыте комунда появилось только тогда, когда заказчик хотел в UI двигать процессы (все равно не смог, но в требования попало)
ну так это одна из основных хотелок применения оркесратора, предостваить возможность запила какой-либо логики или функциональности через UI, по сути кубики собирать (из готовых компонентов) - low code, flow based programming, вот это всё.
PD
В такой компании вообще дело не до архитектурного стиля, все упирается в возможности вендоров. Если вендор умеет в события - то можно делать событийное, если вендор предоставил оркестратор - то можно через оркестратор.
Но, как мне показалось, архитектурные стили - не про интеграционную архитектуру, а скорее про системную или солюшен.
Но, как мне показалось, архитектурные стили - не про интеграционную архитектуру, а скорее про системную или солюшен.
ПА
Кстати, про стили. А что там так ругают Orchestration Driven Service Oriented?
Ну мне лично в ней не нравится то, что такая архитектура убивает всю идею децентрализации. И это очень странно, т.е люди начинают дробить на сервисы, приходят к саге...а потом просто создают единую точку контроля всего. Такой аналог "жирного контроллера" только на уровне всей системы
PD
ну так это одна из основных хотелок применения оркесратора, предостваить возможность запила какой-либо логики или функциональности через UI, по сути кубики собирать (из готовых компонентов) - low code, flow based programming, вот это всё.
Ээ, визуализация и оркестрация вообще никак не связаны.
AK
Ну мне лично в ней не нравится то, что такая архитектура убивает всю идею децентрализации. И это очень странно, т.е люди начинают дробить на сервисы, приходят к саге...а потом просто создают единую точку контроля всего. Такой аналог "жирного контроллера" только на уровне всей системы
ну как раз наоборот. в идеологии service mesh, у тебя будут довольно независимые системы, а оркестратора/мэшаперы будут использовать для генерации BFF и прочей агрегации мапинга между этимим системами, чтобы их никак не трогать. т.е. если системе A нужно скомбинировать апишку от B и C, она просто генерит себе нужный мешапер
I
только типовый тырпрайз очень не любит писать подобные компоненты систем, настолько, что готовы использовать даже data power какой-нибудь в роли оркестратора или камунду
Та мне кажется вот чего-чего а этого добра валом. Еще лет 15 назад все camel оркестрировали :)
I
ну как раз наоборот. в идеологии service mesh, у тебя будут довольно независимые системы, а оркестратора/мэшаперы будут использовать для генерации BFF и прочей агрегации мапинга между этимим системами, чтобы их никак не трогать. т.е. если системе A нужно скомбинировать апишку от B и C, она просто генерит себе нужный мешапер
Ну тут как дядька Фауллер наставлял - умные эндпоинты и простые каналы %)
AK
Ээ, визуализация и оркестрация вообще никак не связаны.
косвенно связаны, визуальное и наглядный интерфейсы как очень хорошо подходят для настройки оркестраторов. в духе того, что когда тебе нужен очередной BFF ты не ставишь задачу беку, а твой аналитик просто идёт и собирает его из типовых кубиков как в камунде он собирает процессы
AK
Та мне кажется вот чего-чего а этого добра валом. Еще лет 15 назад все camel оркестрировали :)
вообще нет. это добра катотрафически мало, да и service mesh внедрять сложно, там куча нерешённых проблем
I
вообще нет. это добра катотрафически мало, да и service mesh внедрять сложно, там куча нерешённых проблем
Ну опять, все зависит от требований к оркестратору. Верблюд довольно неплохо справляется на небольших объемаз, но конечно он не совсем преспособлен для современных распределенных окружений. С мешами история совсем занятная - все про них говорят но я пока в живую на проде нигде не видел.
ПА
ну как раз наоборот. в идеологии service mesh, у тебя будут довольно независимые системы, а оркестратора/мэшаперы будут использовать для генерации BFF и прочей агрегации мапинга между этимим системами, чтобы их никак не трогать. т.е. если системе A нужно скомбинировать апишку от B и C, она просто генерит себе нужный мешапер
Если честно я об агрегации результатов в read model не думал никогда как об оркестрации.
Я в своем комментарии больше описывал проблему когда есть какие-то команды, события, и уже какой-то сервис(оркестрирующий) сам их принимает, анализирует и дергает методы у других, сосредотачивая в себе всю бизнес логику, вместо того чтобы все сервисы общались через шину данных.
Я в своем комментарии больше описывал проблему когда есть какие-то команды, события, и уже какой-то сервис(оркестрирующий) сам их принимает, анализирует и дергает методы у других, сосредотачивая в себе всю бизнес логику, вместо того чтобы все сервисы общались через шину данных.