TOGAF и микросервисная архитектура

Введение

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

Несмотря на то, что многие характеристики MSA аналогичны сервис-ориентированной архитектуре (SOA), этот документ сосредоточен исключительно на MSA. Читателям, ищущим рекомендации по SOA, следует обратиться к Руководству серии TOGAF®: Использование структуры TOGAF® для определения и управления сервис-ориентированной архитектурой.

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

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

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

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

Определение микросервисной архитектуры

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

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

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

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

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

Каждое подразделение в организации имеет разные потребности в решениях – гибкость и время выхода на рынок, а также темпы изменений. Модульный подход к решениям позволяет организации обеспечить гибкость как для краткосрочных, так и для долгосрочных потребностей. Преимущества модульных решений, таких как микросервисы, более подробно описаны в других документах, опубликованных The Open Group, таких как The Open Group White Paper: Microservices Architecture.

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

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

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

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

В мире распределенного гибридного облака роль корпоративной архитектуры заключается в разработке, развитии и распространении повторно используемых ресурсов, таких как эталонные архитектуры, шаблоны, DevOps-процессы и управление сервисами. Эти активы способны обеспечивать управление как традиционными, так и облачными платформами. Хотя управление может быть централизованным, успешные и гибкие предприятия чаще придерживаются децентрализованного подхода к управлению, где каждый поток создания ценности для бизнеса стимулирует инновации от самостоятельных команд, объединяющих представителей бизнеса и ИТ в интегрированных подразделениях.

Далее приведен краткий обзор последствий распределенных архитектур для каждого из доменов корпоративной архитектуры. Подробное описание каждого из них содержится в соответствующих разделах данного документа.

Следует отметить, что в данном контексте архитектура микросервисов рассматривается как стиль архитектуры, поддерживаемый корпоративной архитектурой, и поэтому не охватывает архитектуру предприятия в целом.

Последствия для бизнес-архитектуры

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

Последствия для архитектуры данных

Распределенные архитектуры, в частности MSA, часто приводят к увеличению количества копий данных по сравнению с централизованными решениями. Для обеспечения определенных нефункциональных требований, таких как время отклика и целевые показатели доступности, может потребоваться копирование данных в несколько хранилищ данных (например, хранилище операционных данных микросервиса, кэш, хранилище данных аналитики). Это связано с тем, что необходимо устранить недостаток доступности и задержку, возникающую от зависимостей, чтобы они не оказывали негативное влияние на общую производительность и доступность, а также на удобство работы с приложениями, зависящими от микросервиса. Таким образом, архитектура данных и управление становятся более сложными по мере развития требований к интеграции, обмену сообщениями и аналитическим данным, связанным с этими микросервисами.

Последствия для архитектуры приложений

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

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

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

Последствия для технологической архитектуры

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

Микросервисы могут работать на бессерверных и контейнерных платформах, но каждый вариант развертывания имеет преимущества и недостатки. С ростом спроса на управляемые облачные услуги, возможность выбора оптимальных технологий без необходимости нанимать эксперта для управления полным стеком снижает риск благодаря доверительным отношениям с поставщиками облачных услуг.

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

В этом документе основное внимание будет уделено только уровню микросервисов архитектуры, поэтому актуальна только часть ADM. Ниже для каждого этапа TOGAF ADM описывается, что следует учитывать архитектору, особенно при применении MSA, и как это влияет на результаты этапа. Короче говоря, здесь объясняется, как использовать стандарт TOGAF для выполнения MSA.

Это не отдельное описание. Оно предполагает знание стандарта TOGAF и исключает все, что не связано с MSA. Архитектор может найти всю необходимую информацию на веб-сайте The Open Group TOGAF Standard.

Предварительный этап

На этом этапе TOGAF готовит предприятие к определению целей и задач архитектуры в контексте всей организации. Микросервисная архитектура обеспечивает уровень обслуживания и связанную инфраструктуру для этих услуг. Фокус MSA обычно направлен на технологические возможности предприятия и играет ключевую роль в создании надежных и масштабируемых возможностей. Данный документ предоставляет информацию о MSA, в то время как информация о разработке архитектуры предприятия доступна в других ресурсах, таких как Руководство серии TOGAF® по использованию структуры TOGAF® для управления сервис-ориентированными архитектурами.

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

Структура TOGAF предоставляет систематический подход к разработке архитектуры, который можно успешно применить и к MSA, хотя некоторые аспекты будут иметь особое значение на различных этапах. Начальная фаза гарантирует наличие необходимых навыков, возможностей и управления для успешной реализации MSA. Каждый цикл этапов от A до H приносит прирост к архитектуре, а управление требованиями становится непрерывным этапом для сбора всех необходимых требований MSA и обеспечения гибкого подхода к архитектуре. Важно отметить, что цикл разработки MSA обычно короткий и измеряется неделями, а не месяцами.

На начальном этапе архитектор учитывает принципы проектирования сервисов, характерные для MSA: независимость, самостоятельность и единственная обязанность. Это решение критически важно даже в случае, если предприятие уже ориентировано на услуги. Оно оказывает влияние на стратегию управления и поддержки, а также на содержание исходного репозитория архитектуры.

Принципы MSA

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

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

Ключевые принципы архитектуры, основанной на микросервисах, перечислены в официальном документе The Open Group: Архитектура микросервисов. Я не буду перечислять все эти принципы, но как пример можно привести принцип независимости сервисов, поскольку он является фундаментальным и отличает MSA от SOA, в рамках которой она функционирует.

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

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

Оценка зрелости и готовности

Для успешной разработки и внедрения распределенной архитектуры микросервисов (MSA) необходимо, чтобы предприятие уже было готово к переходу к сервис-ориентированной модели. Оценка зрелости SOA на начальном этапе с применением модели зрелости интеграции сервисов открытой группы (OSIMM), описанная в справочнике по SOA, играет важную роль в анализе организационного контекста для разработки архитектуры предприятия. Помимо этого, необходимо учитывать и другие аспекты, связанные с реализацией MSA.

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

В контексте MSA, термин «разогрев» относится к способности команды самостоятельно контролировать весь жизненный цикл микросервиса, включая разработку архитектуры, выбор технологии и процессы разработки / развертывания. Чтобы обеспечить эффективное развитие и развертывание компонентов в распределенной архитектуре микросервисов, важно обеспечить независимость сервисов MSA. Команды должны иметь возможность выбирать оптимальные технологии и решения, наиболее подходящие для их проектов, при этом соблюдая общие ограничения, установленные архитектурным управлением предприятия.

Соображения относительно жизненного цикла микросервиса и владения командой

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

Методологии Agile / DevOps

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

При внедрении любой новой идеи полезно начать с небольшого проекта и извлечь уроки перед тем, как масштабировать ее. Архитектор может пройти полный, но быстрый цикл TOGAF, не тратя много усилий на детальный анализ, чтобы определить пилотный проект. Успешная реализация этого проекта приведет к окончательному принятию принципа и устранению любых пробелов в оценке зрелости, выявленных в процессе. Конечно, в рамках этого обучающего процесса необходимо оценить организационные последствия распределенной архитектуры MSA.

Стратегия управления и поддержки архитектуры

TOGAF не стремится описывать все аспекты реализации и оперативного управления; он фокусируется на областях, которые непосредственно связаны с разрабатываемой архитектурой. Предполагается, что существует детальное управление этими областями. Предварительный этап включает подтверждение стратегии управления и поддержки архитектуры как части организационной модели архитектуры предприятия. Важно понимать, что требования к управлению распределенной архитектурой, такой как MSA, будут существенно отличаться от традиционных архитектур предприятия, даже тех, которые ориентированы на SOA. Чтобы эффективно функционировать, команда MSA должна следовать двум параллельным направлениям управления: принимать собственные управленческие решения по мере необходимости, применимые только к ней, но при этом оставаться в рамках ограничений, установленных для предприятия.

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

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

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

Для управления MSA, хотя я и не предписываю методологию DevOps, распределенный и быстро меняющийся набор микросервисов потребует следующих видов инструментов управления:

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

Для получения дополнительной информации о DevOps и MSA я рекомендую просмотреть технический документ The Open Group "Преимущества методологии DevOps для решений микросервисов". Общее представление о том, как управление MSA связано с архитектурой предприятия и управлением ИТ, представлено на следующем рисунке.

Эталонная модель управления MSA во многом идентична эталонной модели управления SOA, за исключением того, что она ограничена процессами MSA. Это изображено на следующем рисунке.

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

Репозиторий исходной архитектуры и эталонная архитектура MSA

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

Репозиторий архитектуры может содержать множество артефактов, выходящих за рамки MSA. На этом уровне основные артефакты, представляющие интерес для команды, — это те, которые идентифицируют уже разработанные микросервисы, происхождение этих сервисов и способы взаимодействия с ними. Хотя в прошлом репозитории сервисов в значительной степени были признаны неэффективными, существуют решения, позволяющие обеспечить такого рода обнаружение микросервисов и предотвратить дублирование усилий. Микросервисы доступны только через опубликованный API, который в настоящее время обычно управляется через структуру управления API, которая включает в себя как сервисные сетки, так и шлюзы API. Это развивается вместе с такими работами, как спецификации OpenAPI (OAS).

Как указано в других документах Thw Open Group по MSA, основное внимание будет уделяться тому, как MSA разрабатывается для удовлетворения требований конкретных бизнес-потребностей, в отличие от акцента на корпоративной интеграции аналогичной эталонной архитектуры SOA (ГОСТ Р ИСО/МЭК 18384-1-2017). Как отмечалось выше, MSA не является полной архитектурой предприятия; это архитектура, связанная только с уровнями, на которых находятся (микро)сервисы архитектуры.) Они описываются следующим образом:

Уровень операционных систем:
- Программы и данные операционных систем предприятия
- Новая и существующая инфраструктура, необходимая для поддержки SOA.
Уровень компонентов микросервиса:
- Программные компоненты, каждый из которых обеспечивает реализацию или «реализацию» микросервиса или работу с микросервисом и связывает контракт микросервиса с реализацией микросервиса на уровне операционных систем.
Уровень микросервисов
- Микросервисы с их описаниями, контрактами и политиками, а также контейнеры, содержащие компоненты микросервисов
- Микросервисы и программы, поддерживающие применение правил и работу процедур.
Уровень бизнес-процессов:
- Бизнес-процессы и композиции, в которых бизнес-процессы состоят из других бизнес-процессов и услуг.

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

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

Разделение и распределение ответственности: формирование архитектурной «команды»

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

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

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

Четкое определение миссии каждой команды: почему она существует, сфера ее ответственности и чего организация и архитектурная практика должны ожидать от команды.
Четкие цели для команды, включая измерения и ключевые показатели эффективности (KPI); важно обеспечить, чтобы меры и ключевые показатели эффективности команды не приводили к неправильному выбору технологий и архитектуры.
Команды должны всегда помнить об общих ограничениях и обязанностях, установленных командой архитектуры предприятия.
Взаимный обмен и распространение навыков, опыта и возможностей между командами среди остальных специалистов архитектурной практики должны настоятельно поощряться.
Определите, как члены команды и другие специалисты в области архитектуры будут вознаграждены за успех.
Вначале проведите оценку навыков по всей организации, чтобы определить распределение необходимых навыков для создания полнофункциональных команд.
Необходимые навыки и опыт необходимо тщательно оценить, а там, где их нет, приобрести.

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

Подводя итог, можно сказать, что при разработке предварительного этапа существует ряд методов, инструментов и справочных материалов, разработанных The Open Group, чтобы помочь команде архитектуры предприятия разработать MSA. К ним относятся:

Принципы: независимость от микросервисов.
Определение готовности организации к MSA: организация независимой команды, методологии Agile / DevOps.
Управление: эталонная модель управления открытой группы MSA
Адаптация эталонных архитектур к потребностям организации: эталонная архитектура MSA

Google Sites

Report abuse