Снова про ТОС

И снова возвращаюсь к теме ТОС и оптимизации производительности. Вышел спор/разговор с коллегами по поводу поста выше.
Конкретно по пункту 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://news.1rj.ru/str/it_arch/1594

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

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

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

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

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

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

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

Простая "архитектурная" задача и немного ТРИЗ на прошлом ArchDays
https://youtu.be/j5oiahWsyro?si=_fD7ncNmLbZXR-d4

На InfoQ вышел отчет по архитектурным трендам 2024 года.
Микросервисы продолжают закатываться )

https://www.infoq.com/articles/architecture-trends-2024/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

👆Увидел на восходящих Green software - какие-то недобрые предчувствия (

https://youtu.be/NZuy2QYHfCQ?si=dp5oHU1gSiFZ750l

Fast flow

Крис Ричардсон представил интересный взгляд на микросевисы: концепцию трех быстрых потоков (fast flow):
1. Поток организационный (топология команд)
2. Поток доставки ( DevOps)
3. Поток архитектурный - поддерживающий первые два.

Полностью здесь:
https://microservices.io//post/architecture/2024/04/10/success-triangle-is-about-fast-flow.html