Size: a a a

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

2019 August 15

SG

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

SG

Sergey Grashchenko in Архитектура ИТ-решений
На последнем месте формулировал это как двунаправленный enforcement. Типа push - "приходит архитектор и говорит так нельзя" и типа pull "приходит команда и спрашивает как можно". Дальше конечно сложность чтобы команды приходили иногда, а не всегда/никогда.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Sergey Grashchenko
Да, гайды, и гайды должны быть короткими. Велосипеды можно и допускать, по регламентам. И, главное - нужны процессы исполнения. В идеале по образцу судебной системы. С исполнением приговоров там, обжалованиями.
Плюс декомпозиция основных систем  (система = группа сервисов) и разделение границ/зон ответственности между ними,
чтобы команды знали правила отнесения определенной бизнес-функции к определенной системе.
источник

SG

Sergey Grashchenko in Архитектура ИТ-решений
Да. И в этом аспекте была конечно мечта тоже регламентировать а автомазировать-) но с текущим состоянием сторон заказчиков/потребителей это утопия
источник

GK

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

GK

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

GK

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

GM

Gleb Mekhrenin in Архитектура ИТ-решений
Roman Tsirulnikov
Что не так с гос заказчиками, расскажите.
Опыта не имею, но интересно.
0 компетенций и понимания что и как работает и требования "мы хотим так". Постоянные требования отойти от тз под эгидой "мы вам ниче не подпишем и не заплатим если не сделаете". Можно бесконечно продолжать.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Интересная статья c KubeCon China 2019 про недостающие факторы в 12-factor app.
источник

MR

Mikhail Romashov in Архитектура ИТ-решений
Коллеги, добрый день.
Порекомендуйте пожалуйста статьи по работе с очередями сообщений (kafka, rebitmq etc.). В каких случиях их целесообразно использовать, в каких лучше обойтись обычными rest запросами.
источник

GM

Gleb Mekhrenin in Архитектура ИТ-решений
кафку вычеркните сразу это не очередь
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Зачем так категорично
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Gleb Mekhrenin
кафку вычеркните сразу это не очередь
А рэббит лучше не использовать )
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
За что мы все любим русскоязычные сообщества ;)
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Mikhail Romashov
Коллеги, добрый день.
Порекомендуйте пожалуйста статьи по работе с очередями сообщений (kafka, rebitmq etc.). В каких случиях их целесообразно использовать, в каких лучше обойтись обычными rest запросами.
Enterprise messaging patterns. Ничего не изменилось же за последние 15 лет
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
По мне так не столь важно что именно использовать, главное не рассчитывать никогда на 100% вероятность доставки, и 100% вероятность доставки один раз. Если все приложения сделаны так, что в случае недоставки или повторной доставки ничего не сломается — то в путь.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Mikhail Romashov
Коллеги, добрый день.
Порекомендуйте пожалуйста статьи по работе с очередями сообщений (kafka, rebitmq etc.). В каких случиях их целесообразно использовать, в каких лучше обойтись обычными rest запросами.
Зависит от модели взаимодействия сервисов. Синхронное, асинхронное, нужна гарантированая доставка или нет. Используете вы событийно ориентированную архитектуру или нет и т.п. Если вы на эти вопросы не ответите, вам не помогут ни очереди ни rest
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Мы недавно считали сервисы и смотрели какие паттерны у нас используются,
в итоге поняли что одновременно используем монолиты, SOA, ESB, MSA.
У каждого подхода свои плюсы и минусы. Все четыре подхода отлично решают задачи своих специфических областей.
Более того, в одном бизнес-процессе могут быть задействованы сервисы всех четырех типов.
Правда, система эксплуатируется и развивается уже примерно 25 лет.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Roman Tsirulnikov
Мы недавно считали сервисы и смотрели какие паттерны у нас используются,
в итоге поняли что одновременно используем монолиты, SOA, ESB, MSA.
У каждого подхода свои плюсы и минусы. Все четыре подхода отлично решают задачи своих специфических областей.
Более того, в одном бизнес-процессе могут быть задействованы сервисы всех четырех типов.
Правда, система эксплуатируется и развивается уже примерно 25 лет.
Йес. Я это называю Mixed Architecture))
источник

GK

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