Марк Ричардс — спикер GSAS, профессор Академии Apium и опытный практикующий архитектор программного обеспечения, занимающийся, проектированием, выстраиванием и внедрением микросервисов, сервис-ориентированных архитектур и распределенных систем с применением различных технологий. Он работает в отрасли с 1983 года и обладает значительным опытом и знаниями в области архитектуры приложений, интеграции и архитектуры предприятия. Марк — основатель DeveloperToArchitect.com, бесплатного веб-сайта, помогающего разработчику дорасти до архитектора программного обеспечения. Он является автором многочисленных технических книг и видеоматериалов, включая "Фундаментальный подход к программной архитектуре", серию видеоматериалов «Основы архитектуры программного обеспечения», а также нескольких книг и видеоматериалов по микросервисам и корпоративной передаче сообщений. Помимо практических консультаций, Марк также является докладчиком и преподавателем, выступал на сотнях конференций и митапов по всему миру по различным техническим темам, связанным с корпоративными системами. Давайте рассмотрим, каковы его основные рекомендации по архитектуре программного обеспечения.
Что для вас архитектура программного обеспечения?
Мой видение архитектуры программного обеспечения состоит из двух аспектов: архитектура программного обеспечения как структура и архитектура программного обеспечения как процесс. В структурном аспекте архитектуры программного обеспечения есть 4 измерения: характеристики архитектуры, компоненты архитектуры, стили архитектуры и архитектурные решения. Все эти четыре измерения необходимы для формирования структурного аспекта любой системы. Динамический аспект архитектуры программного обеспечения охватывает методы, а также "«soft skills»" — переговоры, фасилитацию и лидерство.
Какие 3 наиболее выигрышных «soft skills», по вашему мнению, необходимы архитекторам программного обеспечения?
Три лучших "'soft skills" для любого архитектора программного обеспечения — это ведение переговоров, фасилитация и лидерство. Ведение переговоров — необходимый навык для архитектора, поскольку почти каждое решение, которое вы принимаете как архитектор, будет оспариваться. Ваши решения будут оспариваться другими архитекторами, которые считают, что у них есть более эффективный вариант, чем у вас; ваши решения будут оспариваться стейкхолдерами, потому что они считают, что на реализацию вашего решения требуется слишком много времени, или решение слишком дорогое, или не соответствует целям бизнеса. Наконец, ваши решения будут оспариваться командами разработчиков, считающих, что у них есть лучшее решение. Все это требует от архитектора понимания внутреннего микроклимата предприятия и того, как ориентироваться в нем, чтобы ваши решения были одобрены и приняты.
Фасилитация (содействие) — еще один необходимый навык архитектора. Архитекторы не только сотрудничают с командами разработчиков, но и тесно взаимодействуют с различными стейкхолдерами, чтобы понять бизнес-факторы, объяснить важные характеристики архитектуры, описать архитектурные решения и так далее. Все эти собрания и встречи требуют острого чувства локтя и навыков лидерства на этих встречах, чтобы все шло по плану.
Наконец, лидерство — еще один важный навык, поскольку архитектор отвечает за руководство и управление командой разработчиков в процессе реализации архитектуры. Они выступают в роли проводника, наставника, тренера и координатора, чтобы убедиться, что команда идет по плану и работает так же гладко, как хорошо смазанная машина, и быть рядом, когда команде требуются разъяснения или возникают вопросы и проблемы, связанные с архитектурой.
Каковы 3 основные обязанности архитектора в компании?
Три основные обязанности архитектора программного обеспечения заключаются в следующем:
1) Понимание потребностей бизнеса и определение основных архитектурных характеристик, необходимых для системы.
2) Принимать решения по архитектуре, обосновывать эти решения и эффективно доносить их до пользователей.
3) Руководить и направлять команды разработчиков и способствовать сотрудничеству между специалистами, занятыми архитектурой и разработкой.
Каковы основные атрибуты архитектуры программного обеспечения?
Хотя существуют буквально сотни возможных архитектурных характеристик, некоторые наиболее универсальные касаются таких факторов, как производительность, отзывчивость, доступность, отказоустойчивость, гибкость, надежность, безопасность, совместимость, масштабируемость, эластичность, целостность данных и реализуемость. Однако важно понимать, что не существует атрибутов архитектуры программного обеспечения, которые фигурировали бы в любой конкретной системы. Каждая система, а точнее, каждая часть системы, имеет свои собственные архитектурные характеристики ("-ilities"), основанные на том, что важно для бизнеса для данной конкретной системы. Вы просто не можете сказать: «Каждая система должна быть нацелена на производительность», когда на самом деле производительность может и не играть определяющей роли.
Однако есть некоторые общие неявные характеристики архитектуры, которые присущи любой конкретной системе — те атрибуты, которые подразумеваются. К таким общим неявным характеристикам относятся осуществимость, безопасность, надежность и ремонтопригодность. Эти неявные характеристики выходят на передний план, когда они критичны для успеха системы. Например, рассмотрим ремонтопригодность. Этот атрибут остается неявной характеристикой до тех пор, пока не возникнет конкретная бизнес-потребность: например, очень быстрый выход на рынок. В этом случае скорость развёртывания новых функций или исправления ошибок является критически важной для успеха приложения, и поэтому ремонтопригодность становится движущей (или явной) характеристикой, а не неявной.
Что на ваш взгляд важнее – инновации или прагматизм?
Вторым по важности советом, который я получил, когда только стал архитектором, был следующий: надо оставаться прагматиком, но в то же время быть дальновидным. Прагматик – это человек, практикующий «разумный и реалистичный подход к делу, основанный на практических, а не теоретических соображениях», в то время как дальновидный человек – это «думающий о будущем или планирующий его творчески или мудро». Оба эти качества необходимы архитектору программного обеспечения, и стремление их уравновесить, хотя это и трудно, является одним из ключей к успешной и эффективной работе архитектора.
Каковы ваши представления о производительности и отзывчивости?
Хотя оба понятия связаны со скоростью работы системы, отзывчивость и производительность – это две разные вещи. Отзывчивость — это скорость получения обратной связи или ответа конечным пользователем, в то время как производительность — это скорость обработки информации системой.
Чтобы проиллюстрировать разницу, предположим, что пользователь хочет оставить на сайте комментарий о конкретном продукте или услуге, на обработку которого требуется 3 секунды. Если предположить, что задержка в сети составляет 50 мс, (столько времени требуется системе, чтобы достучаться до сервиса), то при использовании синхронных протоколов связи (таких как REST) приведет к тому, что время отклика составит 3100 мс (3000 мс на публикацию комментария, 100 мс на задержку в пути). Однако тот же самый запрос с использованием асинхронного протокола, реализующего обмен сообщениями, займет всего 25 мс (25 мс на отправку в очередь, затем управление возвращается обратно пользователю). На публикацию комментария уйдет еще 3025 мс, но пользователь не будет ждать, пока комментарий будет опубликован. Это хороший пример отзывчивости, потому что ничего не было сделано для устранения проблем производительности, связанных с публикацией комментариев.
Компромиссом в этом сценарии, конечно, является обработка ошибок.
Какие тенденции в архитектуре программного обеспечения вы заметили в последнее время?
Одна из тенденций в архитектуре программного обеспечения, которую я заметил в последнее время — это движение к средам с низким содержанием кода/без кода. Я считаю, что причиной этой тенденции является необходимость для компаний быстрее реагировать на изменения на рынке, а написание и тестирование кода просто занимает слишком много времени. Однако у этой тенденции есть много отрицательных сторон, включая так называемую «ловушку последних 10%». Среда с low code/no code хороша тем, что позволяет быстро достичь 90%, но последние 10% усилий — это то, что убивает большинство таких инициатив, в основном из-за специфических потребностей пользователей или функциональности, которые не поддерживаются средой с low code/no code.
Также я заметил тенденцию (наконец-то!): компании уделяют больше внимания поддержке архитектуры в рамках повседневной деятельности в процессе разработки, а не как отдельного участка работ, которая выполняется в начале проекта. Сейчас компании осознают преимущества эволюционной и поступательно развиваемой архитектуры, позволяя первоначальной архитектуре обрести форму в процессе реализации, когда детали становятся более понятными и реализуемыми. Для этого архитектура должна быть гибкой, чтобы её можно было адаптировать к частым изменениям.
Наконец, я заметил тенденцию к снижению популярности чистых микросервисов. Все больше компаний, похоже, ставят под сомнение чисто микросервисный архитектурный стиль, отдавая предпочтение более гибридным архитектурам, сочетая сервис-ориентированную архитектуру и микросервисы, чтобы сформировать жестко ограниченные контексты только в тех частях системы, где это целесообразно.
Верите ли вы, что в архитектуре программного обеспечения существуют «серебряные пули»?
Я не верю. В нашей книге «Основы архитектуры программного обеспечения» мы с Нилом Фордом ввели «Первый закон архитектуры программного обеспечения», который гласит: «Все в архитектуре программного обеспечения соткано из компромиссов». Вот почему архитекторы обычно отвечают на все вопросы словами «это зависит от ситуации». Тем не менее, я считаю, что существуют некоторые важные практики в рамках процесса архитектуры программного обеспечения, такие как «всегда анализировать компромиссы» и «фокусироваться на том, «зачем», а не на том, «как»».
Каково ваше мнение об эластичности в сравнении с масштабируемостью?
Хотя и эластичность, и масштабируемость относятся к сохранению времени отклика при увеличении количества запросов к системе, они различаются с точки зрения архитектуры. Масштабируемость — это обеспечение стабильного времени отклика и способности к устойчивому росту системы с течением времени, в то время как эластичность — это способность обрабатывать мгновенные скачки пользовательской нагрузки (например, системы продажи билетов на концерты и аукционные системы, такие как eBay). Эластичность также связана с MTTS — средним временем до старта. Чем больше сервис (или система), тем медленнее он будет реагировать на всплеск пользовательской нагрузки или количества запросов из-за того, как много времени требуется для запуска дополнительных экземпляров сервиса. Рассмотрим три основных стиля архитектуры — монолитная (одно развертывание) архитектура, архитектура на основе сервисов и микросервисы. Монолитные архитектуры плохо масштабируются, в то время как сервис-ориентированные архитектуры и микросервисные архитектуры — хорошо. Однако с точки зрения эластичности только микросервисы качественно поддерживают такой подход, благодаря одноцелевой, детализированной природе сервисов (MTTS очень низкий).
Не могли бы вы поделиться своими соображениями относительно паттернов архитектуры программного обеспечения?
Когда я впервые начал публично говорить о таких архитектурах, как многослойная монолитная архитектура, микросервисы, сервис-ориентированная архитектура основе сервисов, событийно-управляемая архитектура, пространственная архитектура, конвейерная архитектура и архитектура микроядра, я называл эти вещи архитектурными паттернами. Это вызвало некоторую путаницу в отрасли, потому что люди спрашивали: «Как эти паттерны связаны с другими паттернами, такими как CQRS (Command Query Responsibility Segregation), паттерн шлюза, паттерн адаптера, паттерн «слой защиты от повреждений» и т.д.»? У меня никогда не было качественного ответа, обычно я парировал, что архитектуры, о которых я говорил, были более «высокоуровневыми» паттернами. Несколько лет назад я начал называть такие вещи, как микросервисы, микроядро, событийно-управляемые, пространственно-ориентированные и т.д. стилями архитектуры, чтобы отличить их от базовых архитектурных моделей.
Таким образом, архитектурный стиль описывает способ построения системы в целом (например, микросервисы, многослойный монолит и так далее), в то время как архитектурные паттерны — это способы описания определенных и специфических архитектурных аспектов этой общей структуры. Например, архитектурный паттерн CQRS можно применить к любому архитектурному стилю — другими словами, он не меняет общую форму архитектуры. То же самое верно и для любого другого архитектурного паттерна — любой из них применим для лучшего описания основных деталей общего архитектурного стиля, который вы используете.
Какие рекомендации по архитектуре программного обеспечения вы бы дали крупным международным компаниям?
Рекомендация номер один, которую я бы дал крупным международным компаниям в отношении архитектуры программного обеспечения, такова: убедиться, что вы определили (и постоянно анализируете) характеристики архитектуры ("-способности"), которые необходимы для данной конкретной системы. Вы просто не сможете создать успешную и функционирующую архитектуру, если у вас нет нужных архитектурных характеристик. Является ли масштабируемость вашей самой важной задачей? Производительность, целостность данных, доступность и отказоустойчивость системы или безопасность? Каждый архитектурный стиль диктует свой собственный набор архитектурных характеристик. Если масштабируемость и отказоустойчивость — ваши проблемы номер один, а у вас традиционное многоуровневое монолитное приложение, то оно рано или поздно выйдет из строя, независимо от функциональности этой системы.
Вывод необходимых характеристик архитектуры из потребностей бизнеса является ключевым моментом. Если бизнес осваивает крупные приобретения, а вы концентрируетесь на производительности, вы, скорее всего, потерпите неудачу — важны совместимость, расширяемость и масштабируемость. Если бизнесу требуется кратчайшее время выхода на рынок, чтобы новые функции и исправления ошибок доходили до клиентов как можно быстрее, а вы концентрируетесь на масштабируемости, вы потерпите неудачу — важна гибкость.
Какие рекомендации по архитектуре программного обеспечения вы бы дали стартапам?
Что касается стартапов и архитектуры, моя рекомендация — сосредоточить усилия в области архитектуры на расширяемости, адаптивности и изменениях (гибкости). Используя проектирование, ориентированное на домен, начните с простого модульного монолита, затем переведите эти модули в доменные сервисы, используя архитектуру на основе сервисов, а затем переведите доменные сервисы, требующие большей масштабируемости, пропускной способности и гибкости, в микросервисы, если это необходимо. Такая эволюционная прогрессия позволяет стартапам быстро развить функциональность, а затем развивать архитектуру по мере того, как вы узнаете больше о потребностях бизнеса и его направлении.
Каковы основные проблемы в архитектуре программного обеспечения?
Одной из основных проблем, которую я вижу в архитектуре программного обеспечения, является продолжающаяся практика «ставить телегу впереди лошади» — принятие решений и выбор архитектуры без определения потребностей бизнеса через характеристики архитектуры и проведения надлежащего и полного анализа компромиссов. Слишком часто мы «вскакиваем на подножку» определенной тенденции, платформы, продукта или технологии, не анализируя компромиссные последствия такого выбора. Например, многие компании переходят на микросервисы, не проанализировав, нужны они им или нет, или начинают внедрять квантовые вычисления или AI/ML без полного понимания последствий этих областей и того, нужны они им или нет.
Ваш путь в архитектуре программного обеспечения: усвоенные уроки?
Мои уроки:
1) Soft skills (навыки работы с людьми) имеют большое значение в архитектуре программного обеспечения — они составляют 50% от того, чтобы быть эффективным архитектором программного обеспечения.
2) Всегда помните об ограничениях проекта и бизнеса при создании и анализе архитектуры программного обеспечения (стоимость, время, бюджет, уровень квалификации и т.д.).
3) Не поддавайтесь хайпу как архитектор программного обеспечения — останавливайтесь, анализируйте компромиссы, изучайте тенденции и подходите к новым технологиям с осторожностью.
4) Больше фокусируйтесь на «зачем», а не на «как» — вот что действительно важно в архитектуре программного обеспечения.
5) Распространение знаний более ценно, чем индивидуальный вклад.
Если же вы хотите больше узнать про архитектуру программного обеспечения, то вашему вниманию мы предлагаем книгу Марка Ричардса и Нила Форда «Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы»:
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Архитектура
Интервью с Марком Ричардсом: основные рекомендации по архитектуре программного обеспечения
Что для вас архитектура программного обеспечения?
Мой видение архитектуры программного обеспечения состоит из двух аспектов: архитектура программного обеспечения как структура и архитектура программного обеспечения как процесс. В структурном аспекте архитектуры программного обеспечения есть 4 измерения: характеристики архитектуры, компоненты архитектуры, стили архитектуры и архитектурные решения. Все эти четыре измерения необходимы для формирования структурного аспекта любой системы. Динамический аспект архитектуры программного обеспечения охватывает методы, а также "«soft skills»" — переговоры, фасилитацию и лидерство.
Какие 3 наиболее выигрышных «soft skills», по вашему мнению, необходимы архитекторам программного обеспечения?
Три лучших "'soft skills" для любого архитектора программного обеспечения — это ведение переговоров, фасилитация и лидерство. Ведение переговоров — необходимый навык для архитектора, поскольку почти каждое решение, которое вы принимаете как архитектор, будет оспариваться. Ваши решения будут оспариваться другими архитекторами, которые считают, что у них есть более эффективный вариант, чем у вас; ваши решения будут оспариваться стейкхолдерами, потому что они считают, что на реализацию вашего решения требуется слишком много времени, или решение слишком дорогое, или не соответствует целям бизнеса. Наконец, ваши решения будут оспариваться командами разработчиков, считающих, что у них есть лучшее решение. Все это требует от архитектора понимания внутреннего микроклимата предприятия и того, как ориентироваться в нем, чтобы ваши решения были одобрены и приняты.
Фасилитация (содействие) — еще один необходимый навык архитектора. Архитекторы не только сотрудничают с командами разработчиков, но и тесно взаимодействуют с различными стейкхолдерами, чтобы понять бизнес-факторы, объяснить важные характеристики архитектуры, описать архитектурные решения и так далее. Все эти собрания и встречи требуют острого чувства локтя и навыков лидерства на этих встречах, чтобы все шло по плану.
Наконец, лидерство — еще один важный навык, поскольку архитектор отвечает за руководство и управление командой разработчиков в процессе реализации архитектуры. Они выступают в роли проводника, наставника, тренера и координатора, чтобы убедиться, что команда идет по плану и работает так же гладко, как хорошо смазанная машина, и быть рядом, когда команде требуются разъяснения или возникают вопросы и проблемы, связанные с архитектурой.
Каковы 3 основные обязанности архитектора в компании?
Три основные обязанности архитектора программного обеспечения заключаются в следующем:
1) Понимание потребностей бизнеса и определение основных архитектурных характеристик, необходимых для системы.
2) Принимать решения по архитектуре, обосновывать эти решения и эффективно доносить их до пользователей.
3) Руководить и направлять команды разработчиков и способствовать сотрудничеству между специалистами, занятыми архитектурой и разработкой.
Каковы основные атрибуты архитектуры программного обеспечения?
Хотя существуют буквально сотни возможных архитектурных характеристик, некоторые наиболее универсальные касаются таких факторов, как производительность, отзывчивость, доступность, отказоустойчивость, гибкость, надежность, безопасность, совместимость, масштабируемость, эластичность, целостность данных и реализуемость. Однако важно понимать, что не существует атрибутов архитектуры программного обеспечения, которые фигурировали бы в любой конкретной системы. Каждая система, а точнее, каждая часть системы, имеет свои собственные архитектурные характеристики ("-ilities"), основанные на том, что важно для бизнеса для данной конкретной системы. Вы просто не можете сказать: «Каждая система должна быть нацелена на производительность», когда на самом деле производительность может и не играть определяющей роли.
Однако есть некоторые общие неявные характеристики архитектуры, которые присущи любой конкретной системе — те атрибуты, которые подразумеваются. К таким общим неявным характеристикам относятся осуществимость, безопасность, надежность и ремонтопригодность. Эти неявные характеристики выходят на передний план, когда они критичны для успеха системы. Например, рассмотрим ремонтопригодность. Этот атрибут остается неявной характеристикой до тех пор, пока не возникнет конкретная бизнес-потребность: например, очень быстрый выход на рынок. В этом случае скорость развёртывания новых функций или исправления ошибок является критически важной для успеха приложения, и поэтому ремонтопригодность становится движущей (или явной) характеристикой, а не неявной.
Что на ваш взгляд важнее – инновации или прагматизм?
Вторым по важности советом, который я получил, когда только стал архитектором, был следующий: надо оставаться прагматиком, но в то же время быть дальновидным. Прагматик – это человек, практикующий «разумный и реалистичный подход к делу, основанный на практических, а не теоретических соображениях», в то время как дальновидный человек – это «думающий о будущем или планирующий его творчески или мудро». Оба эти качества необходимы архитектору программного обеспечения, и стремление их уравновесить, хотя это и трудно, является одним из ключей к успешной и эффективной работе архитектора.
Каковы ваши представления о производительности и отзывчивости?
Хотя оба понятия связаны со скоростью работы системы, отзывчивость и производительность – это две разные вещи. Отзывчивость — это скорость получения обратной связи или ответа конечным пользователем, в то время как производительность — это скорость обработки информации системой.
Чтобы проиллюстрировать разницу, предположим, что пользователь хочет оставить на сайте комментарий о конкретном продукте или услуге, на обработку которого требуется 3 секунды. Если предположить, что задержка в сети составляет 50 мс, (столько времени требуется системе, чтобы достучаться до сервиса), то при использовании синхронных протоколов связи (таких как REST) приведет к тому, что время отклика составит 3100 мс (3000 мс на публикацию комментария, 100 мс на задержку в пути). Однако тот же самый запрос с использованием асинхронного протокола, реализующего обмен сообщениями, займет всего 25 мс (25 мс на отправку в очередь, затем управление возвращается обратно пользователю). На публикацию комментария уйдет еще 3025 мс, но пользователь не будет ждать, пока комментарий будет опубликован. Это хороший пример отзывчивости, потому что ничего не было сделано для устранения проблем производительности, связанных с публикацией комментариев.
Компромиссом в этом сценарии, конечно, является обработка ошибок.
Какие тенденции в архитектуре программного обеспечения вы заметили в последнее время?
Одна из тенденций в архитектуре программного обеспечения, которую я заметил в последнее время — это движение к средам с низким содержанием кода/без кода. Я считаю, что причиной этой тенденции является необходимость для компаний быстрее реагировать на изменения на рынке, а написание и тестирование кода просто занимает слишком много времени. Однако у этой тенденции есть много отрицательных сторон, включая так называемую «ловушку последних 10%». Среда с low code/no code хороша тем, что позволяет быстро достичь 90%, но последние 10% усилий — это то, что убивает большинство таких инициатив, в основном из-за специфических потребностей пользователей или функциональности, которые не поддерживаются средой с low code/no code.
Также я заметил тенденцию (наконец-то!): компании уделяют больше внимания поддержке архитектуры в рамках повседневной деятельности в процессе разработки, а не как отдельного участка работ, которая выполняется в начале проекта. Сейчас компании осознают преимущества эволюционной и поступательно развиваемой архитектуры, позволяя первоначальной архитектуре обрести форму в процессе реализации, когда детали становятся более понятными и реализуемыми. Для этого архитектура должна быть гибкой, чтобы её можно было адаптировать к частым изменениям.
Наконец, я заметил тенденцию к снижению популярности чистых микросервисов. Все больше компаний, похоже, ставят под сомнение чисто микросервисный архитектурный стиль, отдавая предпочтение более гибридным архитектурам, сочетая сервис-ориентированную архитектуру и микросервисы, чтобы сформировать жестко ограниченные контексты только в тех частях системы, где это целесообразно.
Верите ли вы, что в архитектуре программного обеспечения существуют «серебряные пули»?
Я не верю. В нашей книге «Основы архитектуры программного обеспечения» мы с Нилом Фордом ввели «Первый закон архитектуры программного обеспечения», который гласит: «Все в архитектуре программного обеспечения соткано из компромиссов». Вот почему архитекторы обычно отвечают на все вопросы словами «это зависит от ситуации». Тем не менее, я считаю, что существуют некоторые важные практики в рамках процесса архитектуры программного обеспечения, такие как «всегда анализировать компромиссы» и «фокусироваться на том, «зачем», а не на том, «как»».
Каково ваше мнение об эластичности в сравнении с масштабируемостью?
Хотя и эластичность, и масштабируемость относятся к сохранению времени отклика при увеличении количества запросов к системе, они различаются с точки зрения архитектуры. Масштабируемость — это обеспечение стабильного времени отклика и способности к устойчивому росту системы с течением времени, в то время как эластичность — это способность обрабатывать мгновенные скачки пользовательской нагрузки (например, системы продажи билетов на концерты и аукционные системы, такие как eBay). Эластичность также связана с MTTS — средним временем до старта. Чем больше сервис (или система), тем медленнее он будет реагировать на всплеск пользовательской нагрузки или количества запросов из-за того, как много времени требуется для запуска дополнительных экземпляров сервиса. Рассмотрим три основных стиля архитектуры — монолитная (одно развертывание) архитектура, архитектура на основе сервисов и микросервисы. Монолитные архитектуры плохо масштабируются, в то время как сервис-ориентированные архитектуры и микросервисные архитектуры — хорошо. Однако с точки зрения эластичности только микросервисы качественно поддерживают такой подход, благодаря одноцелевой, детализированной природе сервисов (MTTS очень низкий).
Не могли бы вы поделиться своими соображениями относительно паттернов архитектуры программного обеспечения?
Когда я впервые начал публично говорить о таких архитектурах, как многослойная монолитная архитектура, микросервисы, сервис-ориентированная архитектура основе сервисов, событийно-управляемая архитектура, пространственная архитектура, конвейерная архитектура и архитектура микроядра, я называл эти вещи архитектурными паттернами. Это вызвало некоторую путаницу в отрасли, потому что люди спрашивали: «Как эти паттерны связаны с другими паттернами, такими как CQRS (Command Query Responsibility Segregation), паттерн шлюза, паттерн адаптера, паттерн «слой защиты от повреждений» и т.д.»? У меня никогда не было качественного ответа, обычно я парировал, что архитектуры, о которых я говорил, были более «высокоуровневыми» паттернами. Несколько лет назад я начал называть такие вещи, как микросервисы, микроядро, событийно-управляемые, пространственно-ориентированные и т.д. стилями архитектуры, чтобы отличить их от базовых архитектурных моделей.
Таким образом, архитектурный стиль описывает способ построения системы в целом (например, микросервисы, многослойный монолит и так далее), в то время как архитектурные паттерны — это способы описания определенных и специфических архитектурных аспектов этой общей структуры. Например, архитектурный паттерн CQRS можно применить к любому архитектурному стилю — другими словами, он не меняет общую форму архитектуры. То же самое верно и для любого другого архитектурного паттерна — любой из них применим для лучшего описания основных деталей общего архитектурного стиля, который вы используете.
Какие рекомендации по архитектуре программного обеспечения вы бы дали крупным международным компаниям?
Рекомендация номер один, которую я бы дал крупным международным компаниям в отношении архитектуры программного обеспечения, такова: убедиться, что вы определили (и постоянно анализируете) характеристики архитектуры ("-способности"), которые необходимы для данной конкретной системы. Вы просто не сможете создать успешную и функционирующую архитектуру, если у вас нет нужных архитектурных характеристик. Является ли масштабируемость вашей самой важной задачей? Производительность, целостность данных, доступность и отказоустойчивость системы или безопасность? Каждый архитектурный стиль диктует свой собственный набор архитектурных характеристик. Если масштабируемость и отказоустойчивость — ваши проблемы номер один, а у вас традиционное многоуровневое монолитное приложение, то оно рано или поздно выйдет из строя, независимо от функциональности этой системы.
Вывод необходимых характеристик архитектуры из потребностей бизнеса является ключевым моментом. Если бизнес осваивает крупные приобретения, а вы концентрируетесь на производительности, вы, скорее всего, потерпите неудачу — важны совместимость, расширяемость и масштабируемость. Если бизнесу требуется кратчайшее время выхода на рынок, чтобы новые функции и исправления ошибок доходили до клиентов как можно быстрее, а вы концентрируетесь на масштабируемости, вы потерпите неудачу — важна гибкость.
Какие рекомендации по архитектуре программного обеспечения вы бы дали стартапам?
Что касается стартапов и архитектуры, моя рекомендация — сосредоточить усилия в области архитектуры на расширяемости, адаптивности и изменениях (гибкости). Используя проектирование, ориентированное на домен, начните с простого модульного монолита, затем переведите эти модули в доменные сервисы, используя архитектуру на основе сервисов, а затем переведите доменные сервисы, требующие большей масштабируемости, пропускной способности и гибкости, в микросервисы, если это необходимо. Такая эволюционная прогрессия позволяет стартапам быстро развить функциональность, а затем развивать архитектуру по мере того, как вы узнаете больше о потребностях бизнеса и его направлении.
Каковы основные проблемы в архитектуре программного обеспечения?
Одной из основных проблем, которую я вижу в архитектуре программного обеспечения, является продолжающаяся практика «ставить телегу впереди лошади» — принятие решений и выбор архитектуры без определения потребностей бизнеса через характеристики архитектуры и проведения надлежащего и полного анализа компромиссов. Слишком часто мы «вскакиваем на подножку» определенной тенденции, платформы, продукта или технологии, не анализируя компромиссные последствия такого выбора. Например, многие компании переходят на микросервисы, не проанализировав, нужны они им или нет, или начинают внедрять квантовые вычисления или AI/ML без полного понимания последствий этих областей и того, нужны они им или нет.
Ваш путь в архитектуре программного обеспечения: усвоенные уроки?
Мои уроки:
1) Soft skills (навыки работы с людьми) имеют большое значение в архитектуре программного обеспечения — они составляют 50% от того, чтобы быть эффективным архитектором программного обеспечения.
2) Всегда помните об ограничениях проекта и бизнеса при создании и анализе архитектуры программного обеспечения (стоимость, время, бюджет, уровень квалификации и т.д.).
3) Не поддавайтесь хайпу как архитектор программного обеспечения — останавливайтесь, анализируйте компромиссы, изучайте тенденции и подходите к новым технологиям с осторожностью.
4) Больше фокусируйтесь на «зачем», а не на «как» — вот что действительно важно в архитектуре программного обеспечения.
5) Распространение знаний более ценно, чем индивидуальный вклад.
Если же вы хотите больше узнать про архитектуру программного обеспечения, то вашему вниманию мы предлагаем книгу Марка Ричардса и Нила Форда «Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы»:» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Архитектура
