2022-10-25: ArchDays - архитектура и мышление архитекторов

Материал из MaksWiki
Перейти к: навигация, поиск
О других конференциях

В пятницу, 21.10.2022 прошла однодневная ArchDays. Конференция первый раз прошла в 2019, потом два года проходила в online-формате, а сейчас - снова в offline. Отмечу, конференция имеет свое лицо и отчетливый фокус на архитектуре и работе архитектора. Доклады по этой теме есть на Highload, но там больше фокуса на public web и высоконагруженные приложения, что вполне естественно для конференции. А на ArchDays речь идет больше про enterprise и связанные с этим темы, которые на Highload не слишком широко представлены. При этом в докладах на ArchDays больше фокус на объяснений базовых вещей. Для кого-то этот материал очевиден, а для других - является ценным. А еще было несколько докладов, посвященных мышлению архитектора и способам принятия архитектурных решений, и это, на мой взгляд, очень позитивно отличает конференцию в хорошую сторону.

Участников было относительно немного, на сайте 700, но это с онлайн, а присутствовало, по-моему, 200-300. Впрочем я могу ошибаться. Было 4 параллельных трека докладов. Большинство презентаций уже доступны в программе конференции, так что думаю, остальные тоже скоро появятся.

Я, как обычно, вел заметки с докладов на своем телеграмм-канале, а теперь их собираю в отчет. Особо хочу отметить доклад Дмитрия Таболича про мышление архитектора. Другие доклады тоже были интересными, я очень рад, что побывал на конференции. И я слышал лишь четверть от всех докладов..

Сергей Харламов. Архитектура масштабирования: ускоряем обработку и повышаем доступность данных

В современных распределенных системах транзакционность ACID на уровне системы, а не отдельной ноды или процесса практически не поддерживается, фокус на высокой доступности на смену ACID пришел BASE: Base Availability при сбоях, Soft state вместо acid-консистентности, Eventual consistency согласованность в будущем. При этом такие решения часто реализуются поверх старого RDBMS, которое используется как базовое хранилище в legacy-системах, от которых не отказываются.

Для достижения используются различные механизмы: репликация баз данных; разные виды кеширования, при которых кэш работает как промежуточная БД, организованная по-другому, чем исходная; стриминг CQRS; CDC (Change Data Capture). Эти механизмы могут быть доступны в виде готовых решений, для других в БД предусмотрены точки расширения, третьи реализуются на уровне кода приложения. Засада в том, что в этих механизмах нужно разбираться для разбора инцидентов пользователей, и так же для понимания рисков при падении и последующем восстановлении. Эти решения - не внутреннее дело разработки.

В докладе был обзор шаблонов и разбор плюсов и побочных эффектов. Но рассказывать текстом - бесполезно, надо смотреть схемы на слайдах, так что смотрите презентацию.

Максим Юнусов. Изобретение архитектурного решения

Начат с классической ситуации: получив требования по времени отклика под нагрузкой и доступность сервиса с намеком, что для этого сервис должен масштабироваться, Архитектор выдает решение: PostgreSQL + хореография на событиях + Apache Kafka. Вопрос: как решение связано с исходными требованиями?

И дальше был разбор предлагаемого порождения решений. Для начала посмотрим, что предлагают методологии: TOGAF, SEI, ADR. Интересно, что они все исходят из того, что должны быть стандартные решения, и задача выбора состоит лишь во взвешивании вариантов. Различается косметика, подходы к принятию и документированию этих решений. И это - печально.

Поэтому предлагается посмотреть на смежные области, а именно на ТРИЗ. Там много интересного и полезного.

  • Исходное описание - лишь описание ситуации, в ней пока не выявлено противоречие. Необходимо до этого довести, получить задачу.
  • Противоречия бывают двух видов: противоречат два нефункциональных требования или нефункциональное требование противоречит архитектурному принципу.
  • Для нефункциональных требований нужна заинтересованная сторона - кто заинтересован в его исполнении.
  • Нефункциональное требование стоит подвергать сомнению. Действительно ли доступность сайта ниже 99.99 или время отклика более 0.1c приведет к оттоку пользователей (если это указали как основание требования). Может быть, требование можно ослабить или вообще снять?
  • Решать противоречия следует, только если требования реально актуальны. Иначе будет overdesign, необоснованно сложное решение.
  • Архитектурные принципы и ограничения тоже стоит подвергать сомнению.
  • Антипаттерн, если в задаче не должно быть заложен подход к решению, когда сразу говорят, что из требований следует необходимость масштабировать сервиса на кластер
  • Антипаттерн, если свобода сведена к свободе выбора из известного. А именно это предлагают методологии.

Разрешение противоречия

  • Идеальное решение без ограничений
  • Вводим ограничения до потери качества
  • Формулируем физическое противоречие

Пример: архив должен создаваться для обеспечения надежности и НЕ должен создаваться, так как деградирует время отклика. Решаем

  • во времени: делаем архив, когда низкая нагрузка
  • в пространстве: делаем с отдельной ноды БД, которая для этого
  • в структуре: две базы данных: для записи и для архива
  • взаимодействия: приостанавливаем процесс архивирования при интенсивных запросах
  • Архив как идеальный объект, архивирование без архива. Например, если архив нужен для отката - делаем откат иным образом, откручивая обработку событий назад.

Евгений Лукьянов. Как Event Storming, DDD и чистая архитектура помогают запустить стартап

Реальная история стартапа в области здоровья, в котором много алгоритмики и ML. На первом шаге была проверка алгоритмов, потом - проверка концепции на знакомых с интерфейсом на чат-боте. При этом разработку вел один человек на python, и получился сложный, взаимно-перевязанный код из множества сервисов, который очень сложно дальше дорабатывать. В некоторый момент потребовалось научиться вести разработку командой, а для этого потребовалось разобраться и упростить то, что сделано, обеспечить возможность подключения новичков. А потом был следующий этап - проверка спроса на сервис с партнерами, и там был следующий такт изменений.

На первом этапе

  • Event Storming, чтобы разобраться, что делает приложение. Он показал, что основной разработчик не слишком представляет.
  • Шаг к гексагональной архитектуре
  • Внедрили тактические паттерны DDD: сбор бизнес-логики в агрегаты, Value-object, большие сервисы разбили на UseCase.
  • Сделали референсный проект для погружения новичков.

На втором этапе

  • Научили аналитиков пользоваться Event storming. Получились ограниченные контексты, области поделились. И в контекстах можно менять технологии.
  • Нарисовали интерфейсы, отдали партнерам на тестирование.
  • Типизация стандартных решений позволила включать новичков на локальные задачи. У новичка на следующий день есть сделанная простая задача. Разделение по квалификации.
  • Прогнозирование. Сложный агрегат - 2 недели, простой два дня, объект-значение 6 часов, usecase 3 часа. За счет типизации решений.
  • Trunk Based Development. Без веток. Потому что решение конфликтов было дорогим. Но Trunk based - невозможен без автоматики и хорошего тестирования.
  • Тесты - есть заранее подготовленные данные окружения для запуска теста.
  • Локальная сборка экономит деньги. Build-server - предохранитель.
  • TDD для сложных мест
  • Начали допускать тех.долг на этапах апробации решений
  • Ограничили свободу - типовые узлы уже изготовлены, используешь их.

Книга: Accelerate: The Science of Lean Software Development and DevOps. Jez Humble, Gene Kim, Nicole Forsgren.

Геннадий Круглов. SAGA — эволюция и новые смыслы

Сообщество архитекторов решило разобраться, что же такое SAGA, и в докладе представлен результат этого. К сожалению, не впечатляющий. Начали от базовых понятий, подняли статьи 1980-х о том, что же такое - транзакции, какие у них свойства (ACID) и какие проблемы. Одна из них - long life transaction при распределенных системах, которые при формальной реализации ведут к эскалации блокировок. И потому предложено делать промежуточный коммиты внутри транзакции, разбивая их на малые участки, после которых бизнес-консистентности нет, а SAGA - концептуальный способ восстановления этой консистентности, тоже предложенный давно, в 1986. За счет того, что есть управляющая часть, которая в случае прерывания в неконсистентном состоянии либо откатывает шаги, для чего должны быть предусмотрены средства отката, либо проталкивает до завершения, если для этого есть средства. Собственно, все.

Как это реализуется - было за пределами доклада, хотя были ссылки на статьи Microsoft, Red Hat, AWS, Camunda. В общем, жаль, что содержание ограничилось этим. Я тут хочу отметить, что в сентябре был доклад Филиппа Дельгадо "Микросервисы через боль и превозмогание" на Saint Highload (кому интересно - мой конспект), где в числе прочего он говорил про SAGA, пунктиром обозначив минимум четыре шаблона реализации. И я надеялся услышать на докладе про шаблоны и концепты более детально, а получилась лишь историческая справка про статьи 1980-х о транзакциях и SAGA.

Дмитрий Таболич. Майндшифт или мысли, как Архитектор

Очень крутой доклад про отличие мышления архитектора от мышления инженера-разработчика. Это первый сдвиг мышления, касающийся именно технологического стека. Дальше добавляются другие аспекты: business focus, governance, strategy, но начало - именно в сдвиге мышления по техническим вопросам. Если кратко, то для каждой задачи архитектор смотрит спектр вариантов решений и ответственно делает выбор с учетом контекста конкретного проекта. Это достаточно абстрактно, поэтому в докладе это иллюстрировано большим количеством кейсов.

  • Есть задача от проджекта. Инженер: давайте сделаем. Архитектор: какие ограничения?
  • Silver bullet. Инженер: я много раз делал, и сделаю еще раз на своем опыте. Архитектор: для начала смотрим альтернативы индустрии, потом - выбираем. Если решение одно - значит нет ни одного.
  • Документируй. Инженер: хороший код self-explained. Архитектор: очевидно, необходимо описывать ключевые решения, вопрос не стоит. И надо быть готовым
  • Task-driven mindset. Инженеру важна четкая постановка задачи - что сделать. Для архитектора - зачем делаем, какую проблему решаем
  • CV-driven mindset. Инженер: давайте втащим фреймворк. Архитектор: многофакторная оценка уместности - безопасность, скиллы команды и т.п. Вопрос не торможения, а именно многоаспектной оценки.
  • Язык бэкенда и фронтенда. Инженер - только на техническом языке структуры приложения. Архитектор - много viewpoint, в том числе - на языке бизнес-стейкхолдеров, на языке безопасников и так далее.
  • Копипаст. Инженер: посмотрим на stackoverflow и заберем готовый кусок не разбираясь. Архитектор: решения надо смотреть, но надо смотреть несколько и анализировать уместность, делая выбор.
  • Призма мышления. Инженер: сужаем область понимания на задачу. Архитектор: включение задачи в большую систему и влияние на нее.
  • Роль или функция? Инженер: играл роль архитектора в своей команде - значит архитектор. Архитектор: может играть эту роль НЕ ТОЛЬКО в своем проекте, где есть многолетний опыт, может быстро разбираться в других проектах.
  • Я-эксперт. Инженер: отслеживаешь развитие своей платформы, своих технологий. Архитектор - смотришь на множество технологий, на варианты построения решений.
  • HERO. Инженер: выбрана технология, и дальше много усилий, чтобы заставить работать, даже если она не подходит. Например, сначала выбрать JVM для serverless и бороться с долгим стартом JVM. Архитектор: оценивает решения в контексте проекта.
  • Тот самый YAGNI. Мы решили выбрать Mongo, потому что там - транзакции, хотя они и не нужны. Архитектор - обоснованные решения в контексте конкретного проекта, а не вообще
  • IT works on my machine: Инженер: у меня все работает. Архитектор - что DevOps процесс позволяет
  • Все по Scrum. Инженер: о следующей функциональности посмотрим в следующем спринте. Архитектор: видим контекст вперед, не привязываем решения к моменту.
  • Ответственность. Инженер: склонен передать ответственность на коллективное принятие решений. Архитектор - не просто принимает решения, но и несет ответственность за принятые решения.

И с заключении книги:

  • 97 Things Every Software Architect Should Know и
  • BTABoЛ 3.0: Business Technology Architecture Body of Knowledge

В комментариях было обсуждение с Филиппом Дельгядо. Его тезис - что доклад не про разницу мышления между разработчиком-инженером и архитектором, а про разницу мышления между кодером и инженером, он отказывает в в звании инженера тем, кто решая задачу не думает, зачем ее делать и демонстрирует другие другие приведенные в докладе способы мышления, характерные для инженера. И второй - что даже простые задачи нельзя решать, не отвечая на вопрос "зачем", это ведет к резкому увеличению стоимости проекта и падению качества.

Тезисы понятные, но у меня есть возражения.

  • Во-первых, по моему опыту, решить задачу, не спрашивая зачем - можно, и в большинстве случаев получаются приемлемые результаты. При этом, естественно, ты учишь спрашивать "зачем" и многим другим вещам, потому что спросить - просто и потери от того, что не спросил - действительно большие, жалко. Но в целом ситуация не катастрофическая, если в команде только 1-2 человека спрашивают "зачем".
  • Во-вторых, нет такой позиции - "кодер", и квалификацию такую тоже нельзя присваивать, это слово имеет негативные коннотации и демотивирует. Так что мы имеем разработчика, и с точки зрения общепринятого словоупотребления, это - частный случай инженерной позиции: человек, решающий технические задачи.
  • В-третьих, то, что в докладе разнесли линейки развития разработчиков и архитекторов, в целом, правильно и соответствует сложным сеткам специализаций, например, SFIA. Хотя я знаю компании, где архитекторов считают старшими ступенями в развитии разработчиков, так тоже можно.

Но в целом это - оттенки смысла, а не принципиальные разногласия, по-моему.

Денис Котов из Tinkoff. BPM(N,S, engine) — нужны или нет?

Интересный доклад о месте BPM-схем и движков, которые их реализуют. Тезис состоит в том, что если у вас есть хороший BPM-движок, то вы из коробки имеет мощное средство реализации процессов, которое берет на себя не только задачу выполнения экземпляра процесса для конкретной ситуации, но так же отработку особых ситуаций, перезапуск или откат процесса, миграцию экземпляров при появлении новых версий версий описания и мониторинг. При этом у вас из коробки есть таймеры, напоминания, уведомления, механизмы прерываний по событиям и многое другое, и вам нужно лишь реализовывать конкретные шаги, которые может делать конкретная автоматизированная система или человек. Процессы, которые реализует BPMN - гораздо мощнее, чем те, которые дает State machine, процесс имеет много состояний. Это Денис показывал на примере регистрации ИП, которая начиналась с 10+ последовательных шагов, которые действительно просто реализовать на State machine, и за полтора года развития превратилась в сложную схему, в которой около 11 переменных-состояний.

Вопрос в том, где взять этот хороший BPMN-движок, который все это дает из коробки. Начинали они с использования IBM process designer, который всем хорош, только безнадежно отстал по технологиям: Java 6 и никакой интеграции с современными CI/CD и системами тестирования. Потом делали свою State machine, это жило, но с ростом числа процессов, команды и без визуализации и многих других поддерживающих сервисов было сложно. Cейчас - Kotlin как язык, Camunda как движок, Spring для обвязки и Kafka для интеграций. Плюс свое решение на Prometheus и Grafana для мониторинга.

Есть нюанс про уместность использования. Маркетологи успешно продают BPM-решения как серебряную пулю для всего. А сейчас еще идет аккуратное брендирование этих движков под LowCode, когда люди смогут тыкать мышкой без программистов. Это все - маркетинг. Уместно применение для реально сложных процессов, где много взаимодействия людей и систем, и которые разворачиваются во времени. И есть ограничения по нагрузке, 1-10 млн. инстансов ежедневно. А camunda 8 позволяет нагрузку 100 млн. инстансов ежедневно и более. Но все равно, не стоит делать через эти схемы сценарии, поддерживающие поведение пользователей на сайте с реакцией на его клики.

А еще BPMN - сложен, 15 абстракций и 500 графических конструкций. Поэтому для простых задач его использовать не надо, надо использовать Workflow engine, которых много - Temporal, Cadence и так далее. Там всего пара абстракций, и гораздо меньше графических конструкций и для большого количества задач этого достаточно.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.