Написать архитектуру продукта — это не сложно
…сложно не облажаться в будущем.
С Вами снова Владимир и меня все еще зовут девопс.
Немного контекста: я живу в Санкт-Петербурге и работаю в большой компании с крайне бюрократической структурой управления, в которой девопс — это драйвер, лидер и на-все-руки-мастер.
Сегодня делюсь свежеобретенным представлением о создании архитектуры нового проекта или реконфигурации нового.
Введение
В идеальном мире есть solution architect, business architect, infrastructure architect, тех-лид, тим-лид, ПМ, ПО и орда системных аналитиков. Однако если их нет, это не повод отчаиваться больше, чем на полтора часа.
Дисклеймер
Заранее оговорюсь, я не solution architect и все изложенное — это путь самурая без меча, но с мечом
Кажется, что проектировщиком системы должен быть один человек (вопреки всяким аджайлам), ибо Java-разработчик хочет ведра RAM, devops — энтерпрайзные облака с кубами и бд as service, иб — перерезанный сетевой кабель, а стекхолдеры седеют от таких «хотелок» и судорожно хватаются за сердце кошелек.
Стартуем, как правило, от бизнес-потребности — другими словами, задаемся вопросами: что бизнес хочет сделать и какую задачу решить?
Бизнес-потребность приезжает в таком виде:
• Бизнес хочет печь пирожки. Пока для себя, потом, может быть, и на продажу.
• Бизнес хочет печь пирожки с разной начинкой и возможность ее поменять.
• Бизнес хочет попробовать пирожки в небольшом объеме. И только потом строить пирожковый завод.
• Бизнес хочет что-то еще, но не совсем понимает что.
• Бизнес надеется на нашу экспертизу, мы ж не первый день «кухарим».
• Бизнес не знает, сколько будет выпекать, надеется выйти на тысячу в секунду. Но не сразу.
Попробуем разобраться в этих запросах и декомпозировать разработку архитектуры.
Легенда картинок
Разные цвета — условные логические слои:
синий — разработка
зеленый — CI
желтый — CD\артефакт
красный — конечный релиз
серый — закладываем, сразу не реализуем
LVL 1. Что делать?
Итак, попробуем написать ОАР (общее архитектурное решение) для пирожков.
Следует выяснить, как выглядит конечный продукт, где он существует и его опции.
Фактически имеются две сущности — пирожок и место, где его сделают, то есть кухня.
Опции пирожка — тесто и начинка, опции кухни — расположение.
Бизнес архитектура
Определив базовые понятия, можем переходить к процессам, которые должны обеспечить доставку пирожка в магазин.
Перевод для айтишников-айтишников
Общими логическими сущностями следует описать бизнес-запрос. Бизнес хочет сайт? Сайт состоит из: web-front, web-back, db, fileserver.
LVL 2. Как делать?
Разбор, какие логические потоки и опции нам нужны для «success backing».
Где и как собирается пирожок (варианты со скриптом «мешок с костями» отметаем сразу) и как, собственно, его испечь. Проще говоря, кто будет выполнять действия, отмеченные в предыдущем пункте.
Имеются три сущности: заготовка пирожка, кухня и пирожок.
Создается описание, какие функции выполняют сущности для реализации бизнес-запроса.
Прикладная архитектура
Желательно-обязательно заранее заложить возможность масштабирования. Благо, век «избыточных технологий» уходит. Очевидно, что на первых порах будет выпекаться десяток одинаковых пирожков в час, но предусматривается возможность, что их будет тысяча в секунду и с разным составом.
Перевод для айтишников-айтишников
Техническое описание логических сущностей:
fileserver – хранит файлы
db – лежат прочие данные, возможно логика и т.д.
плюс описывание общего функционала (например – авторизация на web-front, web-back пишет в db, в db ряд триггеров)
LVL 3. Где делать?
Девопс-мякотка. Люблю это дело, даже сейчас слюнки потекли. Самое сложное на этом этапе — удержаться. Заранее можно предсказать рассчитать нагрузку на инфраструктуру на определенном этапе, от этого и отталкиваемся. Понятно, что для 10 пирожков в час достаточно одной духовки, при 50 пирожках в час можно докупить еще две духовки, но на 100 и более — стоит задумываться о промышленном решении.
Описание физической структуры с потоками данных и техническими решениями.
Техническая архитектура
Следует разделять «надо» от «хочется». На этапе подготовки MVP, т.е. пирожка-пробника, нет необходимости строить завод, однако технология приготовления пирожка должна предусматривать возможность поставить все итерации на конвейерный процесс.
С возможностью дополнения выполняющихся потоков и процессов, а не изменения «рецептуры». Конечно, если такой вариант есть.
Имея понимание, сколько, где и каких мощностей необходимо, можно планировать бюджет.
Перевод для айтишников-айтишников
Расписываем потоки данных между сущностями web-front, web-back, db, fileserver и, исходя из потребностей прикладной архитектуры, планируем, какие технологии где работают и резервирование ключевых узлов.
Рискую навлечь гнев и крики «сжечь еретика», но очевидно, что для MVP понадобится в разы меньше инфры, куда можно деплоить руками, чем для условно рыночного решения. Например, на схеме можно заменить «духовка» на «ВМ», а «духовой шкаф» на «k8s». Помните, что молоток – для гвоздей, а кувалда +4 с увеличенным критом – для зомбиапокалипсиса.
Если вы можете сразу определить где использовать read-only DB, где web-socket или http-сессии, то поздравляю, Вы великолепны!
LVL 4. Поддержка.
Диверсификация и предупреждение рисков.
В нашей ситуации нужны запасы теста и начинки, обслуживание духовки (в идеале — подменный вариант), пожарная сигнализация, свой человек в санэпиднадзоре и понимание, что делать, если вместо пирожков с вишневым вареньем получаются пирожки с отечественным кинематографом.
Не стоит забывать про процесс кормления пирожками тестовой группы манекенов.
Так же ввиду того, что все, что до стадии «Пирожок», не должно общаться с пирожковыми пользователями — нужно повесить табличку «посто-ронним В!» на кухню и внутренние помещения, а в магазине открываем дверь с баннером «Добро пожаловать!».
Архитектура пайплайнаПеревод для айтишников-айтишников
Оснастить ключевые ноды бекапами, раскинуть мониторинг и логирование по нодам, опубликоваться и потирать пузико. Вздрогнуть и вспоминить, что забыли про инфобез: выделять тест и прод зоны, если часть сервиса торчит в чистые интернеты — предусматреть защиту пространства, как минимум — выделить сегмент dmz. И всегда разделять app и db по разным подсетям.
Желательно сразу записать таску в беклог про поднять SonarQube, SAST и DAST, WAF-ы и прочие радости, кои пригодятся в ближайшем будущем для написания хорошего кода
Итого.
Методологий создания архитектуры ПО — масса. Изучение оных, как и детальный разбор архитектуры с акцентами на быстродействие, api, ui\ux и прочие тонкости — предмет работы отдельного специалиста и не одного. Да и сам процесс весьма сложный и требует высокоуровневого знания большого стека технологий.
Описанный же подход позволяет декомпозировать общий бизнес-запрос и предупредить потенциальные проблемы в разработке как tech-flow, так и business flow, пользуясь логикой и читая в гугле best practice по решению конкретной локальной задачи.
