...сложно не облажаться в будущем.

С Вами снова Владимир и меня все еще зовут девопс.

Немного контекста: я живу в Санкт-Петербурге и работаю в большой компании с крайне бюрократической структурой управления, в которой девопс – это драйвер, лидер и на-все-руки-мастер.

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

Введение

В идеальном мире есть 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 по решению конкретной локальной задачи.

Комментарии (9)


  1. progchip666
    07.11.2022 21:34
    +1

    Как то неожиданно всё оборвалось на полуслове...

    Тем не менее поставил плюс за оригинальность и неплохое оформление.


  1. Dekmabot
    07.11.2022 21:37
    +3

    Зачем вы всем рассказали, что проектировать может и обычный инженер, а не только специально обученный сертифицированный Нострадамус)


    1. progchip666
      07.11.2022 22:10
      +1

      Вы хотели сказать "Пирожки печь"? :)


  1. Ivan22
    07.11.2022 22:49
    +10

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


  1. moonster
    07.11.2022 23:11

    А если потом получится фигня - можно свалить на исполнителей.


    1. Ivan22
      08.11.2022 13:14
      +1

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


  1. daniilgorbenko
    08.11.2022 08:05

    Как по мне, статья действительно описывает основные "болезненные" моменты, которые возникают на этапе проектирования.

    Спасибо!


  1. mixsture
    08.11.2022 13:44

    Особенно весело, когда в диаграммах одновременно квадраты означают:
    помещения
    процессы
    станки
    материалы/продукцию
    клиента/поставщика

    «Попробуй прочитать правильно с первого раза» :)


  1. Arseniy_Maslov
    09.11.2022 21:34

    А можно взять C4model и описать первые 3 уровня.