Существует множество определений термина "Архитектура ПО", от устаревших и неформальных до слишком абстрактных и претендующих на остроумие. К примеру, можно упомянуть сайт Института Программной Инженерии (SEI) Университета Карнеги-Меллона, в электронной библиотеке которого есть соответствующий документ.

Далее я дам свое определение, чтобы всех окончательно запутать (нет).

Архитектура - набор ключевых решений при проектировании системы, удовлетворяющих следующим критериям:

• Абстрактность

• Ограниченность

• Изменяемость

• Имеют критерии качества

Абстрактность

Архитектура (в идеале) абстрактна и не зависит от реализации: протоколов, языков программирования, библиотек и т. д.

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

Иногда при написании документации (например по модели C4), можно увидеть названия протоколов и форматов файлов на уровнях контейнеров и компонентов. Тут решает только здравый смысл.

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

Ограниченность

Архитектура ограничена архитектурным стилем.

Это следует из определения архитектурного стиля как набора ограничений, наложенных на архитектуру.

Более строгое определение можно найти в диссертации автора REST и одного из ключевых разработчиков HTTP Роя Филдинга:

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

Архитектурный стиль - это согласованный набор архитектурных ограничений, которые ограничивают роли/особенности архитектурных элементов и разрешенные отношения между этими элементами в любой архитектуре, соответствующей этому стилю.

Приведу пример некой системы, имеющей следующую архитектуру:

Эта архитектура соответствует стилю N-Tier Architecture и ограничена им. Некоторые ограничения:

• Слои явно выражены

• Каждый слой имеет свой функционал

• Верхний слой видит нижний, но не наоборот (на картинке выше левый слой видит правый, а стрелками показано направление данных, поэтому стрелки влево у Cache не должны смущать)

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

Изменяемость

Архитектура меняется, "до" и "после".

До. Архитектура предполагает последовательность шагов, по которым она будет реализовываться. Самый очевидный пример - миграция.

Например, у нас есть система в дата-центре, и мы хотим перенести ее в облако. Существуют следующие стратегии миграции:

• Rehosting. Перенос без изменений. Если у нас был PostgreSQL, то он переносится на виртуальную машину без изменений.

• Replatforming. Перенос с небольшими оптимизациями, предоставляемыми облачным провайдером. База из PostgreSQL мигрируется на managed service (AWS RDS).

• Repurchasing. Выкидываем и покупаем другой готовый.

• Refactoring / Re-architecting. Переписываем, используя все возможности облака. Старый монолит переписываем на serverless и lambda.

• Retire. Избавляемся от старой системы. Остроумно.

• Retain. Ничего не делаем. Тоже остроумно.

Часто при переносе в облако сперва мигрирует по rehosting и replatforming, а затем начинают переписывать компонент за компонентом по refactoring и re-architecting.

Архитектура должна включать в себя все эти шаги.

После. Мы должны иметь ответы на вопросы вроде:

• Как будет происходить масштабирование? Что поменяется, если нагрузка вырастет на порядок или на два порядка?

• Как будет осуществляться добавление нового функционала?

• Какие функции, если таковые имеются, будут реализованы в обозримом будущем?

• От чего в дальнейшем захотят избавиться?

Имеет критерии качества

Мировой рынок облаков разделяется между тремя компаниями, которые занимают большую его часть. У всех трех компаний есть Well-Architected Framework - набор правил, описывающий принципы и практики разработки приложений:

• AWS (Amazon Web Services)

• Microsoft Azure

• GCP (Google Cloud Platform)

Эти три документа являются отличными примерами критериев качества для архитектуры, процессов и не только.

Относительно архитектуры можно привести несколько примеров:

• Проектируйте приложения так, чтобы они легко масштабировались и имели слабые связи друг с другом. Это позволит регулярно обновлять их компоненты. Автоматическое развертывание небольших изменений уменьшает масштаб возможных проблем и позволяет быстро откатить их в случае возникновения проблем. (AWS, Operational excellence - Make frequent, small, reversible changes)

• Реализуйте принцип наименьших привилегий и обеспечьте разделение обязанностей для работы с ресурсами. Управляйте идентификацией централизовано и стремитесь к устранению зависимостей от долгосрочных статических учетных данных. (AWS, Security - Implement a strong identity foundation)

• Используйте много маленьких серверов вместо одного большого. Это снизит влияние одного сбоя на работу всей системы. Избавьтесь от единой точки отказа. (AWS, Reliability - Scale horizontally to increase aggregate workload availability)

• Развертывание в нескольких регионах позволит вам снизить задержки (latency) и улучшить качество обслуживания клиентов при минимальных затратах. (AWS, Performance - Go global in minutes)

• Платите только за ресурсы, которые вам нужны, и увеличивайте или уменьшайте их потребление в зависимости от необходимости. (AWS, Cost Optimization - Adopt a consumption model).

Также от архитектуры зависят некоторые практики Well-Architected Framework. Например, частые обновления относятся к DevOps, а не к архитектуре, но они невозможны для некоторых архитектурных решений.

Раскрою эту тему подробней.

Если релизы делаются часто, по несколько раз в день, то обычно система не может быть остановлена во время обновления - она должна обновляться незаметно для пользователя. Этого можно добиться с помощью стратегий обновления (Deployment strategies, AWS Elastic Beanstalk deployment strategies) blue/green, rolling, канареечный деплой и некоторые других. Эти стратегии разворачивают новую версию бесшовно, но требуют обратной совместимости, чтобы и новая и старая версии могли работать одновременно.

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

Если же архитектура подразумевает сложную логику в базе данных, то на бесшовном обновлении можно поставить крест - сохранение обратной совместимости будет дороже изменений, ради которых происходит обновление.

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

Эпилог

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