Принципы проектирования зоны приземления Azure

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

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

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

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

Влияние отклонений проектирования

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

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

Демократизация подписок

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

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

2. Используйте подписки для отдельных сред приложений. Подписки также должны использоваться для управления и разделения сред в течение жизненного цикла разработки программного обеспечения (SDLC), таких как разработка, тестирование и производство. Это разделение улучшает управление, снижает риск и поддерживает согласованное управление рабочими нагрузками. Следуйте инструкциям по управлению средами разработки приложений в целевых зонах Azure.

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

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

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

Влияние отклонения

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

• Несоответствие операционной модели. Схема концептуальной архитектуры целевой зоны Azure предполагает определенную группу управления и иерархию подписок для всех подписок управления операциями. Эта иерархия может не соответствовать подходу к операциям. По мере роста и развития вашей организации может измениться операционная модель. Перемещение ресурсов в отдельные подписки может привести к сложным техническим миграциям. Ознакомьтесь с руководством по выравниванию перед фиксацией подхода.

• Отсутствие процесса и автоматизации виртуальных подписок. Если вы не предоставите процесс подписки и связанную автоматизацию, независимо от того, происходит ли это в режиме самообслуживания или нет, команды приложений и служб будут задержаны в предоставлении ценности для вашей организации, пока для них создаются подписки и размещаются в соответствующей группе управления в иерархии. Если процесс получения новых подписок сложный и занимает много времени, команды приложений и служб могут выбрать создание подписок самостоятельно, используя альтернативные учетные записи для выставления счетов, а также, возможно, в неуправляемых или неконтролируемых клиентах Microsoft Entra, что означает появление теневого ИТ.

Управление на основе политик

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

Дополнительные сведения об использовании политики Azure см. в статье "Внедрение защищений, управляемых политикой".

Влияние отклонения

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

Единая плоскость контроля и управления

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

Влияние отклонения

Повышенная сложность интеграции. Мультивендорный подход к плоскостям управления и контроля может усложнить интеграцию и поддержку функций. Замена отдельных компонентов для достижения дизайна «лучший в своём классе» или инструментария для мультивендорных операций имеет ограничения и может вызвать непреднамеренные ошибки из-за присущих зависимостей.

Если вы приносите существующие инвестиции в инструменты в операционную деятельность, безопасность или управление процессами, просмотрите службы Azure и все зависимости.

Модель службы, ориентированной на приложение

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

Независимо от модели службы, старайтесь обеспечить безопасную среду для всех приложений, развертываемых на платформе Azure.

Влияние отклонения

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

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

• Разработка и тестирование и производство — это еще один распространенный подход, который следует учитывать организациям. Дополнительные сведения см. в статье "Как управлять целевыми зонами для нагрузки dev/test/production" в архитектуре целевых зон Azure.

Согласование с собственным дизайном и дорожной картой Azure

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

Влияние отклонения

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

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

Дальнейшие шаги

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

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