Enterprise Security

К слову о безопасности.
На DZone вышел очередной сборник Enterprise Security (август 2024).
- Тут, как обычно, опрос с учетом угроз OWASP.
- Хорошая статья про упомянутый выше "Zero Trust".
- Замечательный материал по построению модели угроз "Full-Stack Security Guide"

В общем рекомендую )

Серьезные дискуссии
(ворчалка)

- В средние века ни одна приличная дискуссия не проходила без цитирования Книги.
- В век просвещения Книгу заменили списком литературы.
- С приходом интернета этот список сократился до одного источника - википедии.

Господа, пора переходить на llm.
Обсуждение не будет серьезным, если мы не дадим слово AI.

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

Все доклады в одном месте

В связи с замедлением ....

Собрал всё в одном месте
https://vk.com/video/@id83992027

Архитектурная проблема

- Как исследователь, я должен подвергать сомнению любое свое решение.
- Как руководитель, я должен продвигать свое решение, как несомненно верное.
- Не успеваю переключаться (

Балансировка нагрузки

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

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

1. Балансировка нагрузки не важна
Нет, если вы предполагаете масштабировать систему по нагрузке. Несбалансированная система не масштабируется.
2. Балансировка не имеет смысла, если один сервис способен вытянуть всю нагрузку
Нет,
- если нагрузка высока, то есть высока вероятность попасть в очередь.
- если ваша нагрузка не представляет собой строго периодическую подачу одинаковых запросов.
- если вы не исключили все возможные "шумы" со стороны.
Любой всплеск породит рост очереди, которая может никогда не рассосаться. Это сразу ухудшит перцентили по времени отклика. Хуже того, рано или поздно в это состояния перейдут все сервисы.
3. Сервис Kubernetes справится с балансировкой без нашего вмешательства.
Нет. Сервис кубера - эфемерная штучка. По умолчанию нагрузкой управляет IPTables, используя правила полученные от kube-proxy. Любой входящий коннект намертво привязывается к случайному поду.
4. Случайная/карусельная балансировка вполне подойдёт для высоконагруженных систем.
Нет. см. п.2.
5. Под кубер для балансировки лучше всего использовать Service Mesh (Istio)
Нет, если Вам дороги ваши ядра )
Если вы уже используете Istio, то логично использовать его возможности по балансировке. Если же нет, то намного логичнее заюзать возможности ОС (IPVS).
6. Предлагаемые из коробки алгоритмы балансировки оптимальны (см. Istio (least request) и IPVS (least connection))
Нет. Хуже того, "идеального" алгоритма не существует. Для каждого сервиса оптимальным будет являться алгоритм учитывающий особенности этого сервиса и особенности нагрузки. В большинстве случаев алгоритм least request/connection дает приемлемый (удовлетворительный) результат.

Извините, что много букв )

Кто кому модель?

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

Архитектура это первая формируемая Система.

И тогда система это компьютерная модель уже существующей архитектуры.

Часто хреновая модель )

Архитектура архитектуры

Часто попадаю на обсуждение одних и тех же вопросов по ИТ архитектуре.
Попытаюсь ответить на несколько из них здесь, используя архитектурный подход.
То есть представив архитектора как систему и накидав архитектуру архитектуры.

Контекст (зачем и кому нужно?)
Система: Архитектор
Акторы: Стейкхолдеры реализуемой системы
Основной сценарий: Стейкхолдеры получают ответы на вопросы по реализуемой системе (технологии, структура, поведение, ожидаемые качества и т. д.)

Информационное представление (что оно такое?)
- Для ответа на вопросы архитектор строит архитектуру (tobe) как некоторую модель (модели) будущей системы.
...
____________________

Часто задаваемые вопросы:

1. Нужен ли архитектор?
Сложная архитектура, включающая большое количество деталей и зависимостей с окружением очень сложно объективизируется. Для сложной архитектуры естественной средой обитания является мозг.
Вывод: в более менее сложных системах для прогнозирования структуры и поведения системы нужен архитектор (или ИО)
2. Может ли быть архитектором неопытный специалист?
Сложная ментальная модель может эффективно использоваться при наличии в сознании архитектора устоявшихся абстракций. То есть все сложные структуры должны быть привязаны к хорошо продуманным понятиям. Оперировать этими понятиями намного проще.
Вывод: архитектор должен быть опытным, со сформировавшейся понятийной моделью.
3. Можно ли размазать роль архитектора по команде?
Архитектура может быть представлена на нескольких носителях (умах). Но в этом случае требуется обеспечить когерентность данных, иначе мы получим несколько вариантов архитектуры одной системы.
Вывод: распределение архитектуры не будет приводить к противоречиям, если мы декомпозируем ее на несколько частей и распределим по частям. Репликация архитектурной модели чревата неприятными последствиями.
4. Как передаётся архитектурное знание?
Отчуждение архитектурной модели не возможно без потери информации. То есть архитектурное представление не полно отображает породившую его модель.
Вывод: чем лаконичнее архитектурное представление, тем более оно нуждается в сопровождении архитектора.

Архитектура архитектуры (аспекты)

Коллеги, спасибо всем кто принял участие в голосовании/обсуждении.

Набросанная выше, крайне лаконичная модель, не позволила сделать однозначных выводов по свойствам рассматриваемой системы "архитектор-архитектура".

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

Для затравки хочу привести точку зрения стандарта (argumentum ad verecundiam).

Итак ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011

1. Эфемерность архитектуры
Архитектура не эфемерна. Она "представляет собой абстракцию, состоящую из понятий и свойств".То есть как минимум это определённый информационный продукт.
2. Архитектура как описание
Архитектура не тождественна своему представлению.
"Настоящий стандарт отличает архитектуру системы от описания архитектуры".
Где описание архитектуры это совокупность ее представлений.
3. Архитектура как свойство системы
Архитектура связанна с системой, но не является ее свойством (атрибутом).
Любая система имеет архитектуру. Но обратное не верно. Архитектура может существовать без реализованной системы. Более того здесь связь многое ко многому:
"Та же самая система может быть понятной с помощью несколько отличающихся архитектур (например, когда они рассматриваются в различных окружающих средах).
Та же самая архитектура может характеризовать более чем одну систему (например, семейство систем деления какой-то общей архитектуры)."
4. Приземление архитектуры
Стандарт относится к описанию архитектуры и мало что говорит про архитектуру саму по себе.
Однако, зафиксировав изложенные факты
- архитектура это информация
- архитектура не тождественна своему описанию
- архитектура не атрибутивное свойство системы
Можно сделать вывод:
Из положений стандарта следует что информационный объект архитектура может быть физически приземлён...

Не буду делать вывод.
Оставлю диаграмму развёртывания на ваше усмотрение )

Архитектура архитектуры (историческая ретроспектива)

1. Мне повезло работать во времена, когда архитектуры еще не было, и разработка ПО относилась к инженерным практикам.
Перед тем как сесть за терминал, мы прорабатывали детальный проект будущей системы (с точностью до кода).
Зачастую такие проекты сопровождались мат. моделями, включающими расчет производительности (до такта), надежности, безопасности (категория A) и т. п.

2. На моих глазах инженерия деградировала. Нехватка времени/сроков приводила к тому, что многие проекты стали менее детальными. Инженера срезали углы. Многие разделы писались для галочки - от балды.

3. В скором времени этот подход узаконили. Принимали только основные решения: структура, контуры системы, тех. стек и т. п. Тут и появилось модное западное словечко "архитектор".

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

5. Конкуренция росла. Требования по срокам/деньгам становились жестче. И вот уже аджайл выдвинул лозунг: "никакого предварительного проектирования". Но это уже другая история...

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

Архитектура архитектуры (физика явления)

С точки зрения физика архитектура объясняется просто.)

— Система имеет некоторую энтропию (мера хаоса).
— Эта энтропия тем выше, чем сложнее система, то есть чем больше система содержит элементов.
— Высокая энтропия порождает высокую неопределённость. Мы не можем предсказать, как поведёт себя система в дальнейшем, и чего нам ждать от неё.
— Устранить риск можно, получив информацию об элементе системы. Чем больше информации мы имеем, тем меньше у системы шансов «взбрыкнуть».
— Однако для полного контроля над системой нужна вся информация об её элементах и об элементах, с которыми система взаимодействует. Это трудно достижимо.
— Решение: связываем элементы системы, подчиняем их нашим правилам. Чем меньше у элементов степеней свободы, тем предсказуемее их поведение.
Получившийся набор правил нарекаем архитектурой.
Если система реализует архитектуру, то её энтропия снижена и вместе с энтропией смягчены риски.

Ну а архитектор в этом случае — борец с энтропией.)

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

1. Ожидания стейкхолдеров выражаются многочисленными требованиями, из которых архитектор выхватывает архитектурно значимые (в основном - нефункциональные).
2. Большинство методик сходится на том, что именно нефункциональные требования определяют архитектуру.
3. Нефункциональные требования группируются вокруг основных качеств системы, таких как производительность, надёжность, сложность, модифицируемость и т. д. (-ility).
4. При этом опыт подсказывает, что вытягивая одно из качеств, мы обычно топим другие (система "хвост-нос").
5. На этом основании многие авторы делают вывод о том, что "всё в архитектуре - компромисс".
(см. Современный подход к программной архитектуре: сложные компромиссы)
6. Декларируется следующий постулат: "В архитектуре нет правильного или неправильного ответа, все может быть компромиссом".

IMHO
Я описываю эту концепцию несколько со стороны.)
Вспоминая закон Джухэни ("Компромисс всегда обходится дороже, чем любая из альтернатив"), я предпочитаю обходится без компромиссов.

Без компромиссов

Сказав А, спешу сказать Б )

В предыдущем посте зафиксировал свою позицию:
"По возможности обходится без компромиссов"
Реально ли это?

Да, если не принимать на веру постулат о взаимозависимости качеств системы.

Качества системы безусловно связаны, но как ?

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

То есть вытянуть все хвосты, не жертвуя ни одним качеством (хотя вложится зачастую придётся).

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

И еще один трюк:
Если мы правильно проведем декомпозицию, то разные качества распределятся по разным модулям.

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

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

Обратил внимание, что концепция архитектурного кванта не знакома многим архитекторам.

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

Нил Форд и ко. считают квантом элемент архитектуры, имеющий слабую статическую и динамическую связанность с другими элементами.

То есть, упрощая, это автономный модуль который можно
- независимо разрабатывать (статическая связанность),
- автономно запускать (динамическая связанность).

То есть, правильная микросервисная архитектура это много квантов, а распределенный монолит это один квант (хоть и много сервисов).

Кванты относятся к доменам отношением многое на многое.
- Можно все домены затолкать в один монолит.
- Можно, напротив, один домен расщепить на несколько квантов.

В итоге, объем кванта может быть существенно меньше ограниченного контекста диктуемого предметкой.

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

Собственно и в самом DDD домен раскидывается на поддомены ради извлечения смыслового ядра. )

Компоненты программной системы

Поздно подумал, что надо было проиллюстрировать предыдущий пост.
Ну лучше поздно, чем никогда.)

Причины декомпозиции

«Вах, зачем ты предлагаешь мне декомпозицию? Как это снизит связанность? Связи останутся те же, только часть из них станет внешними. В итоге мы получим медленные, ненадежные взаимодействия» (из разговора с заказчиком).

1. Говоря о причинах декомпозиции, многие вспоминают связанность.
Связанность (англ. coupling, рунглиш. каплинг) — мера взаимосвязи элементов системы.
Мол, декомпозировать нужно для того, чтобы уменьшить связанность.
Отнюдь.
Так можно договориться до того, что повышать качество системы нужно ради хорошего коэффициента покрытия модульными тестами.

2. Причина декомпозиции в другом: необходимо подчинить себе сложность системы. Притом сложность сразу на нескольких этапах: сложность разработки, сложность выкатки, сложность сопровождения и т. д.
Верю, что когда кожаных специалистов заменит искусственный интеллект, не знающий сложностей, надобность в декомпозиции отпадёт.

3. Возьмём, к примеру, первичную декомпозицию системы. В редких случаях все ее части строятся на одной онтологии. Зачастую система распадается на множество элементов (доменов, предметных областей), описываемых различными языками. Заставьте разработчиков думать сразу на нескольких языках (Ubiquitous Language) и повторите судьбу строителей вавилонской башни.
Одним из паттернов первичной декомпозиции у Криса Ричардсона является декомпозиция по предметке
(см. https://microservices.io/patterns/decomposition/decompose-by-subdomain.html).
И где здесь про связанность?

4. Если уж говорить про метрики, то лучшей метрикой декомпозиции является сцепленность.
Сцепленность (англ. cohesion) — мера «близости» элементов системы.
Упрощая, мы можем проранжировать все связи по «правильности» и провести декомпозицию так, чтобы «правильные» связи попадали в общий элемент, а «неправильные» связывали элементы между собой.
Минимизировать количество и степень неправильных связей (снизить связанность) — это задача распределения ответственностей и дизайна взаимодействий, а не декомпозиции.

5. Список «правильных» и «неправильных» связей можно найти в стандарте ISO/IEC/IEEE 24765.
Однако этот список изначально был ориентирован на низкоуровневый дизайн и поэтому не полон.
Например, в этом списке есть сцепленность по общим данным, но нет сцепленности по общему языку, которую мы активно используем.

6. Хотелось бы хотя бы тезисно накидать алгоритм декомпозиции, указав, какие сцепки используются на разных уровнях иерархии системы.

Причины декомпозиции

Ну и запоздалая иллюстрация )

Уменьшение связанности
(«Правильный ответ»)

Понятно, что правильный ответ в архитектуре всегда зависит от условий конкретной задачи.

Но есть наборы тактик, позволяющих ослабить связанность, и это сужает область поисков.

У SEI таких тактик четыре (см. рисунок).

Правда, если внимательно вчитаться, то остается только две. )

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

Оба решения были названы в комментариях.
Оркестратор — пример посредника.
Событийка на Publisher-Subscriber — пример повышения уровня абстракции.

ИМХО:
Я бы чуть расширил этот список.
Раз с помощью декомпозиции и перераспределения ответственностей можно увеличить связанность, то уменьшить ее можно с помощью объединения и того же перераспределения ответственности.

Чуть позже покажу это на примере.
Судя по голосованию — активно напросился. )

Event messages vs Command messages

1. Многие не видят принципиальной разницы между этими сообщениями.
Действительно ли сообщения-события связывают компоненты слабее, чем сообщения-команды?

2. Команды (Что сделать)
Проектировщики команд, а вслед за ними и проектируемый компонент «знают», кто и как будет обрабатывать команду. И явно декларируют предсказанное будущее в имени сообщения.

3. События (Что произошло)
Проектировщики событий лишены этого знания. События уходят на «другую сторону реки» и могут быть обработаны по-разному разными получателями, а могут и вообще потеряться.
Мы не можем явно описать их дальнейшую судьбу. Но мы все-таки должны дать им имя, полезное обработчикам. Даем имя по их прошлому, сообщая, как они родились.

4. Взаимозаменяемость
Можно ли использовать события вместо команд?
Да. Но мы теряем замечательную характеристику команды — ясность.
Можно ли использовать команды вместо событий?
Очевидно, нет. Не хватает знаний об их дальнейшей судьбе.

5. Подводя итог
У компонента, посылающего события, меньше знаний о связанных компонентах (эфферентная связанность).
Их связывает только общее знание структуры события. Но за это мы заплатили ясностью.(