«Архитектура с эволюционным развитием поддерживает управляемые, постепенные и последовательные изменения сразу в нескольких направлениях».

Из книги «Эволюционная архитектура. Поддержка непрерывных изменений»

Были времена, когда вносить любое изменение в программную архитектуру было крайне дорого. Поэтому после того, как архитектура уже определена и построена, её старались не трогать. Но вот наступили времена облачных вычислений – и теперь дороже и рискованнее стало, наоборот, ничего не менять и сохранять стабильность.

Также формировались новые рабочие процессы. Многие избрали Agile в качестве де-факто стандартной практики. В своё время было принято создавать системы по водопадной модели, когда на проектирование системы уходили месяцы, а на реализацию – годы. При Agile-подходе системы проектируются и строятся постепенно. В такой системе не предусмотрена точка окончательной готовности, она просто постоянно улучшается.

Часто Agile понимают как практику разработки ПО, но она не менее важна и на уровне архитектуры. У облачных архитектур также не бывает окончательной готовности. Архитектура, как и программное обеспечение, может считаться непрерывной.


Источник иллюстрации: continuous-architecture.org

Изменения – ещё не значит хаос. Архитектура всё равно должна быть предсказуемой.

Предсказуемость можно обеспечить, придерживаясь следующих практик:
• Отдавая приоритет архитектурным соображениям,
• Понимая, в каких измерениях развиваются бизнес и индустрия,
• Добавляя функции пригодности, которые помогают не выходить за рамки.

Приоритет архитектурным соображениям

Важно выбирать те проблемы, которые наиболее важны с точки зрения бизнеса, и правильно распределять внимание по зонам ответственности. Здесь есть из чего выбрать. Можно бесконечно пытаться создать идеальную архитектуру, которая бы решала все проблемы. Но в данном случае ключевое умение – понимать, чему отдать приоритет.

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

Понимание измерений, влияющих на архитектуру

«Выживает не самый сильный из видов и не самый умный, а тот, который лучше всех реагирует на изменения»

Чарльз Дарвин

В архитектурных диаграммах мир рассматривается в 2D. Такая диаграмма – это мгновенный снимок идеального мира. Эволюционная архитектура – это практика, при которой учитывается целый спектр измерений, касающихся архитектуры.

Чтобы создать эволюционную архитектуру, необходимо учитывать и другие силы. Есть множество измерений, которые влияют на архитектуру и на то, насколько она поддаётся эволюции.

На следующей диаграмме показаны некоторые важные измерения:


Как видно из диаграммы, в рамках любого проекта конкурирует сразу несколько сил, причём, в любой момент времени. Если знаешь о них и умеешь их визуализировать, то ты и вся команда могут правильно продумать подходящую архитектуру.

Функции пригодности

Функции пригодности – это страховка для архитектуры. Они помогают итеративно вносить изменения и при этом сохранять уверенность, что архитектура не деградирует. В свою очередь, если бизнес доверяет архитектуре, это помогает решать многие проблемы.

Есть много типов функций приспособленности, которые можно рассмотреть; сравнительно широкие категории, о которых мы поговорим ниже – это «триггерные» (triggered) и непрерывные (continual).

Триггерные функции

Функции пригодности, обычно именуемые триггерными – это автоматические операции сканирования системы, хорошо дополняющие практику непрерывной доставки, а также входящие в инструментарий DevSecOps. Эти функции срабатывают, когда в систему вносятся изменения.

К числу таких функций могут относиться:
• Тесты программного обеспечения,
• Сканирование качества кода,
• Сканирование безопасности,
• Интеграционные тесты.

Непрерывные функции

Хороший пример непрерывной функции – обезьяньи скрипты (monkey scripts), применяемые в Simian Army у Netflix. Наиболее известный из них — Chaos Monkey, но также заслуживает упоминания Conformity Monkey, находящий экземпляры, эксплуатация которых идёт не так как надо – и останавливающий их.

Возможно, вам не подойдёт такая агрессивная политика, как в Netflix, и вы не захотите останавливать сервисы, работающие в продакшене. Но можно настроить такие скрипты, которые непрерывно собирали бы информацию. Далее на основе полученной информации можно оборудовать дашборды, инициировать уведомления для команд, а также постепенно генерировать отчёты. Нужен способ, чтобы долгосрочно наблюдать, вся ли работа идёт в соответствии с архитектурными правилами, а если не вся – сообщать об этом ответственным людям.

Относительность архитектуры

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

В качестве примера рассмотрим интеграционные тесты в микросервисной архитектуре. Когда в микросервисе развёртывается новое изменение, либо изменение вносится в масштабах всей экосистемы – например, мы меняем AWS API Gateway на Kong — проводятся интеграционные тесты, позволяющие убедиться, что архитектурные соображения по-прежнему соблюдаются.

На практике

При эволюционной архитектуре внесение изменений – дело первостепенной важности. Изменения приветствуются.

При внедрении эволюционной архитектуры на практике можно исследовать такие паттерны как gitops, при которых для изменения архитектуры достаточно всего лишь изменить конфигурационный файл в репозитории на основе git.


Источник иллюстрации: blogs.vmware.com

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

Другая практика, способствующая эволюционной архитектуре – это обеспечение надёжности сайта (SRE). SRE упрощает наблюдение за системами, добиться прозрачности в пределах всех систем, создаваемых командами. Есть у SRE и другие достоинства – например, возможность настроить оповещения о любых признаках деградации архитектуры.


Источник иллюстрации: www.comparethecloud.net

Как только всё это будет у вас настроено, вы сможете позволить командам работать автономнее. У вас уже есть функции пригодности, поэтому вы можете быть уверены, что вносимые изменения не приведут к деградации архитектуры. Благодаря SRE вся архитектура остаётся прозрачной.

Заключение

Эволюционная архитектура сегодня – необходимость. Именно эволюционная составляющая обеспечивает устойчивость архитектуры при внесении изменений. Если вы создаёте архитектуру, в которой разрешены постоянные изменения, это ещё не означает, что вы допускаете хаос. Можно использовать целый спектр практик, позволяющих сохранять архитектуру предсказуемой.

При организации архитектуры большого предприятия одна из ваших целей – гарантировать, что каждая из команд понимает свою часть архитектуры, а также, что людям комфортно выдвигать новые идеи, не опасаясь изменений.