Инструменты для работы с Архитектурой as Code

Слайды в pptx и подробности: https://t.me/rsa_enc/321

IT-архитектура, представленная просто картинкой (схемой) имеет ряд недостатков — она может быть не актуальной, она не говорит о принципах и паттернах используемых при проектировании и она никак не контролирует дальнейшую разработку на соответствие первоначальному замыслу архитектора. В своем докладе я расскажу как решить все эти проблемы и в автоматическом режиме проверять, что они не вернулись вновь. Поговорим о моей предлагаемой методике покрытия архитектуры тестами и автогенерации архитектуры as Code из инфраструктуры as Code. Я поделюсь OpenSource репозиторием с примерами и инструментами для внедрения тестов и автогенерации архитектуры на ваших проектах!
Инструменты подойдут и для Solution-архитектуры микросервисов, и для Enterprise архитектуры ландшафта предприятия, если у вас уже внедрён подход InfrastructureAsCode.

Ещё больше об ИТ-архитектуре в моём телеграм-канале: https://t.me/rsa_enc
Подписывайтесь :)

Transcript

1. Инструменты для работы с архитектурой «as Code» Руслан Сафин, Бындюсофт v. 2.04
2. Технический директор и архитектор в Бындюсофт Автор и преподаватель курса по микросервисной архитектуре в ИТМО Член программных комитетов CodeFest и TechLeadConf Руслан Сафин 2
3. 3 Byndyusoft — 12 лет на рынке Создаём IT-продукты для на заказ. Нам доверяют ключевые сервисы, от которых зависит бизнес.
4. 1. Что это? 2. Форматы 3. Примеры 4. Преимущества Архитектура As Code 4
5. ИТ-архитектура «Фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие» © стандарт ANSI/IEEE Std 1471-2000 5
6. Архитектура — картинка 6
7. — — Версионирование — Работа с ветками — Синхронизация с исполняемым кодом — Возможности интеграции Картинка + — Наглядность 7
8. + — Версионирование — Работа с ветками — Синхронизация с исполняемым кодом — Возможности интеграции Код — — Наглядность 8
9. + — Наглядность — Версионирование — Работа с ветками — Синхронизация с исполняемым кодом — Возможности интеграции Код → Картинка 9
10. Инструменты — Plantuml — Structurizr — … 10
12. Архитектура микросервисов в PlantUML System_Ext(goods, “Goods Repo") System_Ext(stock, “Stock") Container(bff, “BFF", "NestJS") Container(task_repository, “Task Repo", "NestJS”) Rel(bff, goods, "Get products", “API Gateway") Rel(task_repository, stock, “Send task", $tags="async") Rel(bff, task_repository, "Get task", “REST") 12
14. Преимущества архитектуры «as code» — Унификация — Полностью аналогичный работе с кодом процесс: — Версионирование — Ветки — PullRequest’ы — Merge — … — Возможность автоматизации 14
15. Проблемы архитектурных схем 1. Неактуальность 2. Декларативность 3. Отсутствие контроля 15
16. Неактуальность архитектуры 16
17. Неактуальность архитектуры 17
18. Декларативность 18
19. Декларативность 19
20. Отсутствие контроля 20
21. Есть проблемы с архитектурой ↓ Архитектура теперь описывается в коде ↓ Значит есть проблемы в коде! 21
23. Покрытие тестами 1. Типы тестов 2. Откуда брать данные? 3. Примеры 23
24. Типы тестов — Актуальна ли архитектура реальному положению дел на проде? — Соблюдает ли архитектура выбранные принципы проектирования и договоренности команды? 24
25. На примере архитектуры микросервисов 25
26. Архитектура микросервисов в PlantUML System_Ext(goods, “Goods Repo") System_Ext(stock, “Stock") Container(bff, “BFF", "NestJS") Container(task_repository, “Task Repo", "NestJS”) Rel(bff, goods, "Get products", “API Gateway") Rel(task_repository, stock, “Send task", $tags="async") Rel(bff, task_repository, "Get task", “REST") 26 github.com/byndyusoft/aact/blob/main/architecture/C4L2.pu ml
27. — Сложность извлечения данных — Отсутствие инфраструктурных данных Откуда брать актуальные зависимости сервисов? Код сервисов + Первоисточник поведения сервисов 27
28. — Нет «редких» связей — Сложность симуляции на препроде — Данные только после появления трафика Откуда брать актуальные зависимости сервисов? Service Mesh + Реальный трафик 28
29. Ещё варианты? 🙂 29
31. Откуда брать актуальные зависимости сервисов? k8s configs + Все связи, включая «редкие» + Бóльшая информативность + Данные не требуют трафика 31
32. Конфиг сервиса environment: GOODS_REPO_BASE_URL: default: https://gateway.int.com:443/goods/v1 TASK_REPO_BASE_URL: default: http://tasks-repository:8080 KAFKA_TASKS_BROKERS: default: msg-q8s.int.cloud:9092 KAFKA_TASKS_TOPIC: default: stock-tasks-q8s-v1 32
33. Сравниваем данные из архитектуры и конфигов [ Сервис1 { [ связь1, связь2 ] }, Сервис2 { [ связь1, связь2 ] }, ] [ Сервис1 { [ связь1, связь3 ] }, Сервис2 { [ связь1 ] }, Сервис3 ] 33
35. Пример — сопоставление списка сервисов it("finds diff in configs and uml containers", () => { const namesFromDeploy = deployConfigs.map((x) => x.name); const containerNamesFromPuml = containersFromPuml .filter((x) => x.type == "Container") .map((x) => x.name); expect(namesFromDeploy).toEqual(containerNamesFromPuml); }); github.com/byndyusoft/aact/blob/ac05e3217ac4bc8d621ebbd1323ac9c86a828956/test/architecture.test.ts#L43
36. Output Container name bff ✅ Container name task_repository❌ Container name invoice_acl ✅ -------------------------------------------------------- First failed container name task_repository -------------------------------------------------------- FAIL test/architecture.spec.ts • Architecture › finds diff in configs and uml dependencies expect(received).toEqual(expected) // deep equality - Expected - 1 + Received + 1 Array [ “bff", - “stock", + “goods", “invoice", github.com/byndyusoft/aact/actions/runs/6603088421/job/17935846325#step:5:67 36
37. Что ещё можно проверять по конфигу? Всё, что есть в конфиге и важно отразить на архитектуре ☺ Например: • Тип и параметры связей • Параметры контейнеров • Репликация и автоскейлинг • Разделение по хостам и дата-центрам • Метрики мониторинга • Форматирование и конвенции • … 37
38. 38 Фрукт – фрукт!
39. 39 Фрукт – фрукт! Но если мы проверяем соответствие 1 к 1 — почему бы просто не сгенерировать одно из другого?
41. Автогенерация архитектуры 41
42. Берём данные из конфигов [ Сервис1 { [ связь1, связь2 ] }, Сервис2 { [ связь1, связь3 ] }, ... ]
43. Реализация github.com/Byndyusoft/aact
44. Результат генерации 44
45. Ручной plantuml Сгенери- рованный
46. Когда автогенерация может понадобиться? 🙂 46
47. Проблемы архитектурных схем 0. Их отсутствие😅 1. … 47
48. Что если результат плачевный? 48
49. Сигнал о нарушении принципов: • Stable Dependencies Principle: Depend in the direction of stability • Stable Abstractions Principle: A component should be as abstract as it is stable 49
50. Подробнее о принципах проектирования и исправлении их нарушений: youtu.be/P4LW6WskbK0
51. Сложности автогенерации • Именование внешних систем • Направление асинхронных связей • Добавление отсутствующей в конфиге информации 51
52. s v Генерировать постоянно 52 Внести изменения в единожды сгенерированное Если второе — у нас есть тесты на актуальность!
53. Проблемы архитектурных схем 0. Их отсутствие ✅ 1. Неактуальность ✅ 2. Декларативность 3. Отсутствие контроля 53
54. Тесты на соблюдение архитектурных принципов 54
55. Перейдем сразу к примерам в формате: 1. Принцип 2. Договоренность об его использовании 3. Как протестировать 55
56. 1. ACL (Anti-corruption Layer) Pattern За интеграцию с внешними системами ответственны отдельные микросервисы-адаптеры, инкапсулирующие в себе знания о внешних системах (например, об их доменных сущностях) 56
57. 1. ACL (Anti-corruption Layer) Pattern 57
58. 1. ACL (Anti-corruption Layer) Pattern Как протестить: 1. помечаем на архитектуре соответствующие микросервисы признаком Adapter 2. проверяем, что связи с внешними системами имеют только сервисы с таким признаком Container(goods_adapter, “Goods ACL", "NestJS", $tags="adapter") 58
59. 2. Пассивные Repository Микросервисы, отвечающие за доступ к мастер-данным, не обладают дополнительной логикой и не имеют зависимостей помимо своей БД. 59
60. 2. Пассивные Repository 60
61. 2. Пассивные Repository Как протестить: 1. Помечаем на архитектуре соответствующие микросервисы признаком Repository 2. Проверяем, что у таких сервисов нет исходящих связей, кроме единственной БД Rel(task_repository, task_db, "") Rel(camunda, task_repository, "") Rel(task_repository, invoice_acl, "") 61
62. Чуть больше принципов в моей статье: 62 Покрытие архитектуры as Code тестами Статья стала статьёй года на Хабре в номинации Бэкенд
63. Больше принципов в каталоге: 63 github.com/Byndyusoft/aact/blob/main/patterns.md
64. Тестируем не только принципы проектирования, а любые ADR: • Отказоустойчивость • Тегирование критичности сервисов • Правила репликации и автоскейлинга по критичности • Разделение сервисов по хостам и дата-центрам • Наличие DLQ • Наблюдаемость • Поставка метрик в мониторинг • MAX потенциальная сумма требуемых ресурсов • … 64
65. Проблемы архитектурных схем 0. Их отсутствие ✅ 1. Неактуальность ✅ 2. Декларативность✅ 3. Отсутствие контроля 65
66. Предписания архитекторов могут нарушаться по незнанию или умышленно • Упавшие тесты отсеют нарушения по незнанию • Обязательный апрув архитектора для PR в тестах и архитектуре отсеют недобросовестные нарушения 66 Архитектурные изменения не пройдут мимо архитектора
67. Личный опыт • 2 чел/нед разработчика • 2 чел/нед архитектора • 0,5 чел/нед девопса В «продакшне» почти год 67
68. Личный опыт, решённые проблемы • Актуализировали архитектуру • Привели к единым конвенциям • Нашли топики кафки с продьюсерами, но без подписчиков • Нашли неиспользуемые REST-зависимости в конфигах и коде • Актуализировали понимание внешних систем • Измерили и зафиксировали архитектурный техдолг • Переключили на API Gateway все необходимые зависимости • Убрали дублирование в конфигах 68
69. 69 Нашел проблему — напиши тест!
70. Как начать применять? 1. github.com/Byndyusoft/aact 2. Библиотека по работе с PlantUML (или аналогом) на вашем стэке 3. Маппинг вашего варианта InfractructureAsCode в термины архитектуры 4. Генерация и тесты 5. 💰💰💰 70
71. OpenSource-репозиторий Architecture As Code Tools Планы и анонсы 71
72. Roadmap репозитория • Покрытие архитектуры тестами • Каталог архитектурных паттернов (ADR+тесты) • Автогенерация • Инструменты рефакторинга микросервисной архитектуры https://github.com/Byndyusoft/aact/blob/main/roadmap.md 72
73. Roadmap. Покрытие архитектуры тестами ✅ Покрытие тестами микросервисной архитектуры ✅ Покрытие тестами архитектуры модульного монолита 🟩 Добавление реализаций и примеров под разные • стэки (сейчас TypeScript и C#) • “Architecture as Code”-инструменты (+ Structurizr) • реализации “Infrastructure as Code” ⌛ Справочник принципов и паттернов проектирования (в формате ADR) с примерами тестов 73
74. Справочник принципов. ADR 74 Шаблон ADR Пример ADR: ACL-паттерн
75. Roadmap. Автогенерация ✅ Автогенерация архитектурной схемы по конфигам инфраструктуры 🟩 Автогенерация конфигов инфраструктуры по архитектурной схеме 🟩 Добавление провайдеров для различных реализаций IaC 🟩 Автогенерация и архитектурной схемы, и конфигов инфраструктуры по архитектурному решению (ADR) 75
76. Roadmap. Инструменты рефакторинга микросервисной архитектуры 🟩 Изменение сигнатуры метода API (endpoint’а) 🟩 Вынос метода API (endpoint'а) микросервиса в отдельный микросервис 🟩 Inline микросервиса — поглощение микросервиса своим потребителем 76
77. Анонсы. Август-сентябрь • +1 Пример микросервисной архитектуры • на Structurizr • тесты на C# • Открытые онлайн-воркшопы, где разберём ваши примеры микросервисных архитектур и попробуем написать тесты на ваши ADR 77 @Архитектура распределённых систем
78. Как присоединиться к развитию репозитория? 78
79. See all issues 79 github.com/Byndyusoft/aact/issues
80. Welcome! github.com/Byndyusoft/aact
81. Итоги • Архитектура “as Code” • Решение проблем через покрытие тестами • Автогенерация архитектуры • Каталог паттернов проектирования • Присоединяйтесь к развитию OpenSource-репозитория! 81
82. Спасибо! Руслан Сафин, технический директор Бындюсофт @razonrus @Архитектура распределённых систем