Size: a a a

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

2020 March 20

RT

Roman Tsirulnikov in Архитектура ИТ-решений
В монолите все связано со всем: “плохие” изменения создают проблемы “хорошим” проектам, тянут на дно всю систему.
В MSA система разделена на относительно изолированные сервисы (если конесно верно разделена)
источник

DD

Dmitrii Dima in Архитектура ИТ-решений
А -)
источник

S

Sergey in Архитектура ИТ-решений
"злоба дня" нынче вирус и экономика :)
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
от нас требуют обеспечения непрерывности процессов,
некогда вашу панику читать, работаем)
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Roman Tsirulnikov
На злобу дня:
Микросервисы это очень хорошая тема — они позволяют сделать так что “плохие” проекты будут тихо умирать за своей загородочкой, не отравляя жизнь другим, не создавая рисков опасной дестабилизации системы в целом.
Да. Это одна из основных выгод использования MSA в корпоративных ИС
источник

ДС

Дмитрий Седухин in Архитектура ИТ-решений
Если монолит сложно чистить то получается ядро Линукс полна всякого рода дряни, а ядро проекта ГНУ (не помню как называется) должно быть стабильнее и динамичнее развиваться так как основано на микросервисах... Но почему тогда активнее развивается монолитное ядро?
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Пример некорректен:  разработка ядра Линукс координируется и контролируется централизованно, совсем шлак в код ядра не попадает за счет многоступенчатой системы ревью.
А в корпоративнызх ИС шлака хватает,
проекты очень разного качества. Бывает что делают сами и навека, а бывает чтоб подешевле и на аутсорсе.
источник

ДС

Дмитрий Седухин in Архитектура ИТ-решений
Если сами и на века то какая разница микро сервисы или монолит?
Я пытаюсь понять, если код так себе то без разницы какой он монолитный или раздроблен на обособленные куски.
источник

ДС

Дмитрий Седухин in Архитектура ИТ-решений
И получается архитектура тут не решающий фактор
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Maxim Smirnov
Да. Это одна из основных выгод использования MSA в корпоративных ИС
Эта арх. характеристика называется гибкостью.

В конечном итоге гибкость влияет на ТТМ.

Кроме гибкости MSA позволяет повысить масштабируемость и отказоустойчивость.

Разбиение решения на автономные модули (микросервисы) позволяет повысить все эти важнейшие с  точки зрения бизнеса арх. характеристики.
источник

GK

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Дмитрий Седухин
Если сами и на века то какая разница микро сервисы или монолит?
Я пытаюсь понять, если код так себе то без разницы какой он монолитный или раздроблен на обособленные куски.
Не так важно какой код внутри кусочков, важно чтобы декомпозиция кусочков была выполнена правильно. Так, чтобы они имели низкую связность. Иначе эти кусочки образуют распределённый монолит.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Дмитрий Седухин
И получается архитектура тут не решающий фактор
Решающий, см. сообщение выше
источник

ДС

Дмитрий Седухин in Архитектура ИТ-решений
На сколько я понимаю архитектуру Линукс дистрибутивы строятся, по большей части на микросервисах, а само ядро монолитное?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если внутри кусочка (микросервиса) код с душком, то мы просто переписываем этот кусочек
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Gennadiy Kruglov
Эта арх. характеристика называется гибкостью.

В конечном итоге гибкость влияет на ТТМ.

Кроме гибкости MSA позволяет повысить масштабируемость и отказоустойчивость.

Разбиение решения на автономные модули (микросервисы) позволяет повысить все эти важнейшие с  точки зрения бизнеса арх. характеристики.
Выскажу точку зрения, что всё сложнее. И гибкость может достигаться разными факторами и под TTM поднимают сильно разные вещи. Но главное, что в корпоративной среде, в среднем по больнице, всё вообще очень плохо. Можем мне не везет, но когда кто-то приходит с проблемой, то в большинстве случаев он банально не может сказать сколько и каких сервисов у него в этой проблеме запущено, на чем они и как друг с другом взаимодействуют. Какой там код? Главный вопрос: чинить или менять
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Maxim Smirnov
Выскажу точку зрения, что всё сложнее. И гибкость может достигаться разными факторами и под TTM поднимают сильно разные вещи. Но главное, что в корпоративной среде, в среднем по больнице, всё вообще очень плохо. Можем мне не везет, но когда кто-то приходит с проблемой, то в большинстве случаев он банально не может сказать сколько и каких сервисов у него в этой проблеме запущено, на чем они и как друг с другом взаимодействуют. Какой там код? Главный вопрос: чинить или менять
Да, полностью согласен, в своём докладе об этом говорил. Редко кто может ответить на вопрос, по каким принципам выполнена декомпозиция и за счёт чего обеспечивается низкая связность. Если ответов нет, то скорее всего макароны.
источник

GK

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
И это mindset. Есть коллеги, которые в принципе так работают всегда.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Куда бы побыстрее прилепить и поменьше думать - это тоже про TTM, про скорость выкатки. Но такой подход не работает в долгую.

В итоге на шине столько всего налеплено...
источник