...сложно не облажаться в будущем.
С Вами снова Владимир и меня все еще зовут девопс.
Немного контекста: я живу в Санкт-Петербурге и работаю в большой компании с крайне бюрократической структурой управления, в которой девопс – это драйвер, лидер и на-все-руки-мастер.
Сегодня делюсь свежеобретенным представлением о создании архитектуры нового проекта или реконфигурации старого.
Введение
В идеальном мире есть 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 по решению конкретной локальной задачи.
