Size: a a a

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

2019 September 20

PO

Paul Olesh in Архитектура ИТ-решений
источник

PS

Petr Shmotov in Архитектура ИТ-решений
Sergei Beilin
А базы данных знать надо? А брокеры сообщений? А стриминговые платформы? А инфраструктуру?
Надо знать возможности и ограничения. А с базами пусть админы бд возятся, с брокерами систехи. А с языками - разработчики )
источник

MB

Maxim Bendin in Архитектура ИТ-решений
Sergei Beilin
Это имхо все такие же технологии, как и язык.
infrastructure as a code
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Petr Shmotov
Надо знать возможности и ограничения. А с базами пусть админы бд возятся, с брокерами систехи. А с языками - разработчики )
О, сколько я насмотрелся проектов, сделанных такими архитекторами....
источник

PS

Petr Shmotov in Архитектура ИТ-решений
Phil Delgyado
О, сколько я насмотрелся проектов, сделанных такими архитекторами....
Монолитно.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, это не самое худшее. Хуже всего, что архитектор читает обещания вендоров и верит им.
Вместо того, что бы смотреть в код тех же брокеров и фреймворков или погружаться в особенности конкретных БД.

Писать архитектору обычно некогда, но вот уметь свободно читать код и понимать, что с этим кодом не так - нужно.
Ну, пока у него меньше 300 разработчиков, может в больших компаниях для старших бизнес-архитекторов уже можно и код не читать, но все равно сомневаюсь )
источник

KG

Kirill Gorin in Архитектура ИТ-решений
Petr Shmotov
Надо знать возможности и ограничения. А с базами пусть админы бд возятся, с брокерами систехи. А с языками - разработчики )
а как знать возможности  и ограничения если сам руками не далал?
источник

KG

Kirill Gorin in Архитектура ИТ-решений
есть наверно у вас документ от вендора - возможности и ограничения?
источник

PS

Petr Shmotov in Архитектура ИТ-решений
Источники разные могут быть: документация, статьи, экспертное мнение и т.д. Не обязательно самому тратить уйму времени, разворачивать, настраивать, проводить нагрузочное тестирование с десятком брокеров, чтобы выбрать один для решения конкретной задачи. Более того,  это нецелесообразно.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Документация всегда врет, статьи почти всегда (и нет возможности отличить правдивые от лживых), экспертное мнение всегда необъективно.
Так что таки нужно разворачивать, настраивать, проводить нагрузочное тестирование, разбираться в реальных гарантиях и ограничениях, читать код.
Где-то самому архитектору, где-то вместе с программистами или DBA/OPS, но понимать внутренности нужно.
Иначе будут получаться ненадежные, плохосопровождамые и нерасширяемые системы.
Ой, а ведь все крупные системы, где архитекторы код не пишут - именно такие. Что телеком, что крупные банки...
источник

KG

Kirill Gorin in Архитектура ИТ-решений
короче можно не своими руками, а чужими
источник

PS

Petr Shmotov in Архитектура ИТ-решений
Phil Delgyado
Документация всегда врет, статьи почти всегда (и нет возможности отличить правдивые от лживых), экспертное мнение всегда необъективно.
Так что таки нужно разворачивать, настраивать, проводить нагрузочное тестирование, разбираться в реальных гарантиях и ограничениях, читать код.
Где-то самому архитектору, где-то вместе с программистами или DBA/OPS, но понимать внутренности нужно.
Иначе будут получаться ненадежные, плохосопровождамые и нерасширяемые системы.
Ой, а ведь все крупные системы, где архитекторы код не пишут - именно такие. Что телеком, что крупные банки...
Идеальная картина, которая убивает time to market в зародыше 🤷‍♂
источник

KG

Kirill Gorin in Архитектура ИТ-решений
но тогда ты можешь знать ограничения, но не понимать откуда они берутся в итоге
источник

KG

Kirill Gorin in Архитектура ИТ-решений
видел много таких вот "спецов"
источник

KG

Kirill Gorin in Архитектура ИТ-решений
ирудиция это пыль ссыпаная в пустую черепную коробку
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Petr Shmotov
Идеальная картина, которая убивает time to market в зародыше 🤷‍♂
Неа, она спасает time-to-market на интервалах от 3х месяцев. А для проектов меньше архитектор вообще не нужен.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но когда брокер для проекта в несколько тысяч человеко-лет выбирается по обещаниям вендоров (а я такое видел много раз)
источник

PS

Petr Shmotov in Архитектура ИТ-решений
Phil Delgyado
Неа, она спасает time-to-market на интервалах от 3х месяцев. А для проектов меньше архитектор вообще не нужен.
Я про микросервисную архитектуру. В которой спринт на выкат в прод 2-3 недели.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Спринт - это не архитектура. А какой брокер между микросервисами - это архитектура. И его менять очень дорого, так как от него зависят гарантии, на которые рассчитывает каждый сервис.
источник

PS

Petr Shmotov in Архитектура ИТ-решений
Ну. И за 2-3 недели надо и архитектуру сделать, и реализовать.
источник