Референсные архитектуры

Референсная архитектура - это архитектура "из коробки"
Берём чьё-то готовое решение и используем у себя как некоторый baseline.

Часто спрашивают где брать.
В основном ищем в интернете. Интересные решения демонстрируются на разных конференциях.

Или, например, в приложенной книге.

Производительность и ТОС

Многие считают, что теория ограничений систем Голдратта (ТОС) хорошо справляется с задачей повышения производительности информационных систем.

ТОС даёт нам план:
1. Разбиваем процесс на этапы.
2. Находим бутылочное горлышко.
3. Определяем ограничение.
4. Устраняем ограничение.
5. Повторяем с первого шага.

Если двигаться по этому плану, то можно добиться существенного увеличения пропускной способности.
Если же оптимизировать случайные участки системы, то скорее всего пропускная способность упадёт.

Однако не всё так однозначно.

Если у нас другой concern, например, если нам необходимо улучшить отзывчивость, то план не работает:
1. Разбиваем процесс на шаги.
2. Находим участок с максимальной потребностью в ресурсе (bottleneck)
3. Определяем ограничение/ресурс (например SSD)
4. Устраняем...

А вот тут затык. Да, оптимизация бутылочного горлышка даст нам максимальный эффект.
Но эта оптимизация может быть крайне трудоёмкой или даже вовсе не возможной.

Оптимизация же соседнего участка, может оказаться не столь эффективной, но очень дешевой.

То есть правило работающее на пропускную способность, не работает на отзывчивость или, например, справедливость.

Теория ограничений имеет ограниченную область применения при проектировании программных систем.)

#ТОС

Пост в оправдание

Коллеги, если у вас сложилось впечатление, что я против ТОС, сильно каюсь.
👆Выше я хотел сказать, что ТОС имеет свою область применения (scope) и не стоит рассматривать его алгоритмы как универсальный инструмент оптимизации (многие грешат).
К тому же современный ТОС это не только про слабые звенья.)

В оправдание приведу несколько интересных и не очевидных выводов из ТОС относящихся к оптимизации пропускной способности системы под нагрузкой:
1. В открытой/полуоткрытой модели оптимизировать надо бутылочное горлышко. Остальные участки оптимизировать бесполезно.
2. Узкое место нужно постоянно мониторить. Оно может переместиться. Лучший показатель - длина очереди запросов перед узким местом.
3. Умный планировщик имеет смысл только на узком участке. На других участках приоритет должен отдаваться запросам которые уйдут на узкое место.
4. Важно отслеживать очередь запросов к узкому месту. Плохо если очередь велика. Очень плохо если длина очереди под нагрузкой 0.

#ТОС

Снова про ТОС

И снова возвращаюсь к теме ТОС и оптимизации производительности. Вышел спор/разговор с коллегами по поводу поста выше.
Конкретно по пункту 4.

Аргумент коллеги:
Узкое место перегружено. Важно его разгрузить. Идеально разгруженное узкое место имеет очередь длиной 0.

Аргумент ТОС:
Под нагрузкой производительность всей системы определяется узким местом.
Поэтому ресурс на бутылочном горлышке должен задействовать все свои возможности.
Нельзя чтобы бутылочное горлышко простаивало. Перед ним нужен заполненный буфер.

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

ИМХО аргументы ТОС убедительны.

#TOC

Обеспечение низких задержек в высоконагруженной системе: разбор реального кейса.

PR-отдел IT-One опубликовал статью по моему докладу на HL++.

В принципе ничего нового, но для тех кто не любит смотреть видео может быть интересно.

https://tproger.ru/articles/obespechenie-nizkih-zaderzhek-v-vysokonagruzhennoj-sisteme--razbor-realnogo-kejsa?ysclid=lsbmqtasd5413958027

Антипаттерн "Каша из топора"
(другое название "Рисование совы" )

Методологический антипаттерн.
Нам демонстрируют простой инструмент ("топор").
Немного пасов руками и на столе великолепная каша (решение проблемы).

Рецепт остается за кадром.

Магия рассеивается, когда после демонстрации (чаще платной) пытаешься применить полученные знания на практике.

#Антипаттерны

Выступил сегодня на архитектурном митапе в ИТ-1.
Тема: методология принятия решения архитектором ПО

Представил своего Франкенштейна слепленного из разных методик

https://youtu.be/eBaPm4nPzkA?si=J0wgsgeubO1O_XEF

Запись с митапа

Контекст и метод

- Наблюдая эффективность чужой команды, многие пытаются перенять их МЕТОД
- Часто это заканчивается полной несуразицей (анти-паттерн карго культ)
- Забывается правило, что "Никакой метод работы не может быть перенесён из того конкретного проекта, в котором он был разработан, в другой проект" (см. situational method engineering)
- "Между ситуациями (контекстами) выживает не сам метод, как предзаданная последовательность операций, а только какие-то его части"
- В разных школах ситуационной инженерии методов эти части назывались компонентами/components, кусочками/chunks, ломтиками/slices
- То есть кроме описания метода должна быть предложена схема адаптации метода под ситуацию (контекст)
- Что опять таки требует наличия специалиста, погруженного в контекст - архитектора проекта.

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

Отсюда еще одна ответственность архитектора - натягивать удачные процессы на известные предринятия. )

Определение архитектуры

Существует два популярных определения термина "архитектура":
1. "Архитектура — фундаментальная организация системы, состоящая из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы." (ISO 42010, TOGAF)
Или по простому ССС (Components + Connectors + Constraints)
2. Архитектура представляет значимые решения, где под словом «значимые» подразумевается то, что трудно изменить в дальнейшем. (Grady Booch и последователи Agile)

По первому определению архитектура присутствует в любой системе. Архитектуру можно выявить изучая структуру "компонент".

Во втором случае, утратив обоснования принятых решений - теряем архитектуру. Есть такое определение унаследованной системы:
"Унаследованная (legacy) система - это система архитектура которой утеряна".

А какое из определений ближе Вам ?

👇

Что такое архитектура (cont)

Выскажу свое мнение по вопросу☝.

Я согласен с большинством принявших участие в голосовании.
Считаю оба определения не полными.

1. По определению togaf мне не хватает измерений. Как архитектор я имею дело не просто со структурами компонент, а с четырех мерными (плюс время), или даже с "пяти-мерными" (плюс смысл) структурами.

2. В определении Буча появляется смысл и подспудно присутствует время. Но потерялось слово "система". Простая совокупность решений не дает эмерджентности.
Архитектура не просто набор, это система позволяющая находить оптимальные решения.

Исходя из своего понимания термина стараюсь при описании архитектуры совмещать оба подхода:
1. Давать описания архитектуры как системы (AD)
2. Давать описание архитектуры как набора осмысленных значимых решений (ADR)

Пока так

Архитектура как система

1. Многие рекомендуют при проектировании архитектуры использовать системный подход (см. А. Левенчук и др.)
2. Имеется в виду два момента:
- Мы проектируем систему (то есть не набор компонент, а нечто обладающее эмерджентностью)
- Мы проектируем системно (то есть рассматриваем различные аспекты системы)
3. Однако программная система это продукт всего процесса разработки. А продукт архитектора именно архитектура.
4. Если применять системный подход к работе архитектора, то следует признать, что архитектура тоже является системой со своей эмерджентностью и многоаспектностью.
5. Какое новое качество появляется при объединении всех архитектурных решений, моделек и принципов ?
ИМХО это возможность получить оптимальный и обоснованный ответ на вопрос стейкхолдеров, в частности разработчиков.

То есть, в моем понимании, архитектура это некоторая система знаний и решений позволяющая ответить на вопросы связанные с реализацией системы.

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

Вот такую работу раздают бесплатно

Modeling more software performance antipatterns in cyber-physical systems


Промоделированы многие известные анти-паттерны производительности

#Книга

Граф зависимостей по производительности

Готовлюсь к докладу по методологии принятия арх. решения.

Под это дело "причесал" граф зависимостей по производительности

Разные времена

Поясняя вышеприведенный граф демонстрирую используемые термины.
(пока только время)

Решение задач производительности

Если обобщить все тактики решения задач производительности то остается только два пути:
1. Залить железом (Manage Resources)
2. Повысить эффективность системы (Control Resource Demand)

Многие считают, что залить железом это оптимально. Так как железо зачастую стоит дешевле часов разработки.

Однако, стоимость не единственный критерий качества.

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

Поэтому если стейкхолдер заинтересован в масштабировании, надо четко понимать где наша граница и стоит ли приближаться к ней наливая железо.

Кстати, те же рассуждения верны в плане повышения надежности.

Антипаттерн "Критическое мышление"

1. Критическое мышление по определению - способность анализировать информацию и делать выводы на основе умозаключений.
По факту критическое мышление пришло на смену логическому/научному мышлению.
2. Отличие критического мышления от научного в ареале применения. Логическое мышление Вы используете там, где чувствуете себя специалистом. Критическое мышление используется повсеместно.
3. Критическое мышление притягательно.
- Можно не зная о предмете высказывать свое суждение, облеченное в логические фигуры.
- Можно с легкостью отбивать атаки на свой информационный пузырь.
4. Критическое мышление опасно. Мнение специалиста уже не столь значимо. У каждого есть свое.
Заказчик заранее знает какое "техническое решение" правильно и сколько времени займет его реализация.
Джун легко назовет ошибки архитектора.
5. Стремясь противостоять критическому мышлению архитектор фиксирует не только свои выводы, но и их обоснования (ADR).

Однако, популярность критического мышления возрастает.
Скоро от нас потребуется обоснование обоснований (

#Антипаттерны

Архитектура как система (contd)

Ранее определил для себя архитектуру как некоторую систему знаний и решений, позволяющую ответить на вопросы связанные с реализацией разрабатываемой системы.

Сегодня у Максима Смирнова нашел классификацию тех самых вопросов
https://www.tgoop.com/it_arch/1594

Похоже интересная работа. Добавляю в список для чтения.

Активный архитектор

Перечитал вышеизложенные типы запросов к архитектору и позволил себе некоторые возражения )

ИМХО архитектор в представлении автора череcчур пассивен.
Работает исключительно как служба.

А где вопросы от "самого важного" стейкхолдера - от самого себя.

Я убежден, что должен быть добавлен запрос на выявление рисков не реализовать ожидание заказчиков.

Этот запрос приведет нас к некоторому списку архитектурных задач (enablers), которые впоследствии придется драйвить.