Architecture As Code (AaC): от рисунка на салфетке к инструменту анализа

Сегодня поговорим о подходе Architecture as Code и о том, как он может улучшить ваши рабочие процессы.

Несмотря на популярность термина, устоявшегося определения для него нет. Чаще всего встречается следующая формулировка:

Подход Architecture as Code направлен на разработку и управление архитектурой программного обеспечения на основе читаемой и версионируемой кодовой базы. Это способствует глубокому пониманию, эффективной разработке и бесперебойному обслуживанию сложных информационных систем.

На практике возникает много вопросов о том, что именно можно считать AaC. Например:

Дело в том, что сейчас популярны различные подходы «как код» (Infrastructure as Code, Diagrams as Code, Documentation as Code и т. д.), поэтому важно чётко очертить границы AaC.

Основными задачами, которые мы хотели решить, используя подход AaC, были:

1. Получить согласованную архитектурную модель.

2. Сместить фокус с представления на содержание.

3. Автоматизировать генерацию артефактов.

Причём от автоматизации генерации артефактов зависит выполнение первых двух:

Дополнительными задачами могут стать:

В контексте этих задач становится видна разница между подходами Architecture as Code и Diagram as Code. Diagram as Code работает в первую очередь с визуальным представлением архитектуры. Таких представлений в одном проекте может существовать множество и данный подход не ставит целью обеспечить их согласованность. В свою очередь Architecture as Code фокусируется именно на описании самой архитектуры – архитектурной модели. При этом представления рассматриваются как вспомогательные артефакты, формируемые автоматически на основе данной модели, что позволяет обеспечить их согласованность.

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

Теперь, когда мы разобрались, для чего нужен и чем полезен Architecture as Code, давайте посмотрим, какие инструменты помогают реализовать этот подход.

Чаще всего в контексте AaC упоминаются PlantUML, Structurizr, LikeC4, Archi, ArchUnitNET. Однако не все из них одинаково полезны для описания архитектуры. Например, ArchUnitNET скорее решает задачу контроля реализации, чем проектирования.

На что же стоит обратить внимание при выборе инструмента?

Возможно, ваши критерии будут отличаться с учетом особенностей проекта. Однако, список выше можно использовать как отправную точку. Мы остановили выбор на LikeC4 и последующие примеры используют этот инструмент.

Рассмотрим, как AaC можно применить в реальном проекте.

В качестве примера возьмём онлайн-магазин, вдохновлённый eShop reference app от Microsoft. Доступ к системе возможен из мобильного приложения и через веб-интерфейс.

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

Но как это представить в виде архитектуры? Давайте разберёмся.

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

А также ряд инфраструктурных сервисов.

Однако просто перечислить компоненты недостаточно — важно описать их взаимодействия.

Первое, что нам необходимо описать — это компоненты системы и взаимодействия между ними. Как видите, всё вполне прозрачно.

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

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

Такое описание мы можем положить рядом с кодом и автоматизировать построение представлений. А как еще можно использовать наше описание?

Допустим нам нужно описание API с информацией о нагрузке.

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

Сделать выгрузку суммарных требований по нагрузке к отдельным методам REST API.

В зависимости от потребностей вашего проекта столбцов может быть больше.

Здесь хотим поделиться одним из наших страхов: а что если в выборку попали не все взаимодействия, например, потому что для них не добавлены метаданные? Бывают ситуации, когда нужно срочно внести крупные изменения, либо когда на момент формирования описания нет необходимых данных. Найти потом такие взаимодействия довольно трудно, потому что нужно просматривать все артефакты в поисках того, чего там нет. Можем ли мы автоматизировать такие проверки?

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

Список имеющихся проблем можно встроить в конвейер сборки. Чтобы получить список, нужно запустить скрипт.

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

Это позволяет правильно идентифицировать угрозы и реализовать необходимые меры защиты в рамках практики «моделирование угроз» («Моделирование угроз (описание объекта защиты)»).

Входными данными здесь являются:

Количество взаимодействий может превышать сотню. Такая активность должна проводится при каждом релизе. Ручной сбор этой информации трудоёмок, но AaC позволяет автоматизировать процесс. Архитектурная модель предоставляет исходные данные, а скрипты преобразуют их в нужный формат.

Оформляем модель угроз в виде страницы в Confluence в соответствии с шаблоном. Для получения списка интеракторов достаточно получить из архитектурной модели список элементов с типами Person и External System. Далее на основе него формируется CSV-файл, который загружается как вложение к Confluence-странице.

Границы доверия могут быть заданы через диаграммы развертывания, т.к. они зачастую совпадают с физическими границами устройств, сетей и т.д. Они также экспортируются в CSV и затем загружаются в Confluence.

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

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

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

В результате мы получаем вот такие диаграммы уже в терминах потоков данных.

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

В результате мы получаем такой документ.

Architecture as Code — это мощный инструмент, который помогает не только описывать, но и анализировать архитектуру, делая её прозрачной и управляемой. Architecture as Code сокращает объём рутинной работы, повышает согласованность артефактов и даёт возможность автоматизировать проверки.

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

P.S. Чтобы всегда первыми видеть наши новые материалы, подписывайтесь на канал.