Автогенерация архитектуры «as Code»

Все дополнения по архитектуре для вашего удобства уже внесены в опенсорс https://github.com/byndyusoft/aact

Ссылка на доклад https://dump-spb.ru/ehksperimenty-po-avtogeneracii-arhitektury-as-code

Infrastructure_As_Code стал де-факто стандартом для индустрии, Architecture_As_Code также становится всё более и более популярным подходом. А раз у нас всё «as Code» — так почему бы всё и не связать между собой? :) Покрыть тестами, связать с друг с другом и с исполняемым кодом, и так далее до полной автоматизации всего :)

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

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

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

Transcript

1. Автогенерация архитектуры «as Code» Руслан Сафин, Бындюсофт
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. Проблемы архитектурных схем 0. Их отсутствие😅 1. Неактуальность 2. … 15
16. Неактуальность архитектуры 16
17. Неактуальность архитектуры 17
18. Архитектуру теперь можно описывать кодом ↓ значит её можно сгенерировать! 18
20. Автогенерация архитектуры 1. На примере микросервисов 2. Откуда брать данные? 3. Результат 20
21. На примере архитектуры микросервисов 21
22. Архитектура микросервисов в 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") 22
23. — Сложность извлечения данных — Отсутствие инфраструктурных данных Откуда брать актуальные зависимости сервисов? Код сервисов + Первоисточник поведения сервисов 23
24. — Нет «редких» связей — Сложность симуляции на препроде — Данные только после появления трафика Откуда брать актуальные зависимости сервисов? Service Mesh + Реальный трафик 24
25. Ещё варианты? 🙂 25
27. Откуда брать актуальные зависимости сервисов? k8s configs + Все связи, включая «редкие» + Бóльшая информативность + Данные не требуют трафика 27
28. Конфиг сервиса 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 28
29. Берём данные из конфигов [ Сервис1 { [ связь1, связь2 ] }, Сервис2 { [ связь1, связь3 ] }, ... ]
30. Реализация github.com/Byndyusoft/aact
31. Результат генерации 31
32. Ручной plantuml Сгенери- рованный
33. Что ещё можно добавить? Всё, что есть в конфиге и важно отразить на архитектуре ☺ Например: • Тип и параметры связей • Параметры контейнеров • Репликация и автоскейлинг • Разделение по хостам и дата-центрам • Метрики мониторинга • … 33
34. Что если результат плачевный? 34
35. Сигнал о нарушении принципов: • Stable Dependencies Principle: Depend in the direction of stability • Stable Abstractions Principle: A component should be as abstract as it is stable 35
36. Подробнее о принципах проектирования и исправлении их нарушений: youtu.be/foKH9KJjgRI
37. Ещё сложности • Именование внешних систем • Направление асинхронных связей • Добавление отсутствующей в конфиге информации 37
38. s v Генерировать постоянно 38 Внести изменения в единожды сгенерированное Что если второе?
39. Проблемы архитектурных схем 0. Их отсутствие ✅ 1. Неактуальность 2. … 39
41. Сравниваем данные из архитектуры и конфигов [ Сервис1 { [ связь1, связь2 ] }, Сервис2 { [ связь1, связь2 ] }, ] [ Сервис1 { [ связь1, связь3 ] }, Сервис2 { [ связь1 ] }, Сервис3 ] 41
43. Пример — сопоставление списка сервисов 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
44. 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 44
45. Проблемы архитектурных схем 0. Их отсутствие ✅ 1. Неактуальность ✅ 2. Декларативность 3. Отсутствие контроля 45
46. Декларативность 46
47. Декларативность 47
48. Отсутствие контроля 48
49. Тесты на соблюдение архитектурных принципов 49
50. 1. ACL (Anti-corruption Layer) Pattern За интеграцию с внешними системами ответственны отдельные микросервисы-адаптеры, инкапсулирующие в себе знания о внешних системах (например, об их доменных сущностях) 50
51. 1. ACL (Anti-corruption Layer) Pattern 51
52. 1. ACL (Anti-corruption Layer) Pattern Как протестить: 1. помечаем на архитектуре соответствующие микросервисы признаком «Adapter» 2. проверяем, что связи с внешними системами имеют только сервисы с таким признаком Container(goods_adapter, “Goods ACL", "NestJS", $tags="adapter") 52
53. Больше примеров принципов и тестов на них: 53 youtu.be/tZ-FQeObSjY
54. Проблемы архитектурных схем 0. Их отсутствие ✅ 1. Неактуальность ✅ 2. Декларативность✅ 3. Отсутствие контроля 54
55. Предписания архитекторов могут нарушаться по незнанию или умышленно • Упавшие тесты отсеют нарушения по незнанию • Обязательный апрув архитектора для PR в тестах и архитектуре отсеют недобросовестные нарушения 55 Архитектурные изменения не пройдут мимо архитектора
56. Личный опыт • 2 чел/нед разработчика • 2 чел/нед архитектора • 0,5 чел/нед девопса В «продакшне» несколько месяцев 56
57. Личный опыт, решённые проблемы • Актуализировали архитектуру • Привели к единым конвенциям • Нашли топики кафки с продьюсерами, но без подписчиков • Нашли неиспользуемые REST-зависимости в конфигах и коде • Актуализировали понимание внешних систем • Измерили и зафиксировали архитектурный техдолг • Переключили на API Gateway все необходимые зависимости • Убрали дублирование в конфигах 57
58. Как начать применять? 1. github.com/Byndyusoft/aact 2. Библиотека по работе с PlantUML (или аналогом) на вашем стэке 3. Маппинг вашего варианта InfractructureAsCode в термины архитектуры 4. Генерация и тесты 5. 💰💰💰 58
59. Спасибо! Руслан Сафин, технический директор Бындюсофт @razonrus github.com/ byndyusoft/aact @Белковые шахматы