Принципы проектирования для посадочных зон Azure
Концептуальная архитектура целевых зон Azure универсально применяется к любому процессу или реализации целевых зон. В основе архитектуры лежит набор основных принципов проектирования, которые служат компасом для последующих решений по проектированию в критически важных технических областях.
Принципы помогают стремиться к оптимальному проектированию целевой архитектуры. Если вы решили развернуть акселератор целевой зоны Azure или любую версию базы кода целевой зоны корпоративного масштаба, создайте архитектуру, применяя описанные здесь принципы проектирования.
Использование этих принципов в рамках реализации будет служить полезным руководством для реализации преимуществ облачных технологий. Эта облачная перспектива, часто называемая собственных облачных, представляет способы работы и технических возможностей вашей организации, которые устаревшие технологии подходы обычно не предлагают.
Влияние отклонений проектирования
Могут быть допустимые причины для отклонений от принципов, таких как в случае Tailwind Traders. Требования организации могут диктовать конкретные результаты или подходы к проектированию среды Azure. В этих случаях важно понимать влияние, которое будет иметь отклонение на проектирование и будущие операции. Тщательно рассмотрим компромиссы, описанные для каждого принципа.
В качестве общего правила следует подготовиться к балансировке требований и функциональных возможностей. Ваш путь к концептуальной архитектуре будет развиваться с течением времени по мере изменения требований и того, как вы будете учиться на своей реализации. Например, с помощью предварительных версий служб и принятия зависимостей в планах развития служб можно удалить технические блокировщики во время внедрения.
Демократизация подписок
Используйте подписки в качестве единицы управления и масштабирования для ускорения миграции приложений и разработки новых приложений. Приведите подписки в соответствие с бизнес-потребностями и приоритетами для поддержки бизнес-областей и владельцев портфеля. Предоставьте подписки бизнес-подразделениям для поддержки проектирования, разработки и тестирования новых рабочих нагрузок и миграции существующих рабочих нагрузок.
Чтобы организация эффективно работала в масштабе, поддерживает подписку с подходящей иерархией групп управления. Эта поддержка позволит эффективно управлять и упорядочивать подписку.
Влияние отклонения
Одним из способов реализации этого принципа является децентрализованные операции путем перехода их в бизнес-подразделения и группы рабочей нагрузки. Такой подход позволяет владельцам рабочих нагрузок получить больше контроля и автономии над своими рабочими нагрузками в пределах рамок, установленных платформенным фундаментом.
Клиентам, которым требуются централизованные операции, и которые не хотят делегировать управление рабочими средами группам рабочей нагрузки или бизнес-подразделениям, может потребоваться изменить проектирование их организации ресурсов и отойти от этого принципа.
Структура концептуальной архитектуры для целевых зон Azure предполагает определенную группу управления и иерархию подписок для всех подписок управления операциями. Это предположение может не соответствовать вашей модели управления .
По мере роста и развития вашей организации, ваша операционная модель может измениться. Это изменение может снова привести к миграции ресурсов в отдельные подписки, за которой последуют сложные технические миграции. Прежде чем выбрать подход, ознакомьтесь с руководством по выравниванию.
Управление на основе политик
Используйте политику Azure для обеспечения безопасности и обеспечения постоянного соответствия платформы вашей организации и приложений, развернутых на нем. Политика Azure также предоставляет владельцам приложений независимость и безопасный путь к облаку.
Влияние отклонения
Не используя политику Azure для создания ограничений в вашей среде, вы увеличиваете затраты на операции и управление соответствием требованиям. Политика Azure помогает ограничить и автоматизировать требуемое состояние соответствия в вашей среде.
В рамках рекомендаций по проектированию просмотрите , как использовать политику Azure в реализации целевой зоны.
Единая плоскость контроля и управления
Избегайте зависимости от уровней абстракции, таких как разработанные клиентом порталы или инструменты. Настоятельно рекомендуется иметь стабильный опыт для центральных операций и операций с рабочей нагрузкой.
Azure предоставляет унифицированную и согласованную среду управления, с ролевым доступом и контролем на основе политик. Это относится ко всем ресурсам Azure и каналам подготовки. С помощью Azure можно установить стандартный набор политик и элементов управления для управления всем корпоративным имуществом.
Влияние отклонения
Выбор подхода, предполагающего использование нескольких поставщиков для управления плоскостями управления и контроля, может привести к усложнению интеграции и поддержки функций. Замена отдельных компонентов для создания оптимального дизайна или инструментов для управления несколькими поставщиками может иметь ограничения и вызвать непредвиденные ошибки из-за присущих зависимостей.
Для клиентов, которые используют свои существующие инструменты для операций, безопасности или управления, мы рекомендуем провести оценку служб Azure и любых связанных зависимостей.
Модель службы, ориентированной на приложение
Сосредоточьтесь на миграциях, ориентированных на приложения и разработке, а не на миграции с чистой инфраструктурой, например перемещение виртуальных машин. Варианты проектирования не должны отличаться от старых и новых приложений, инфраструктуры как службы (IaaS) или платформы как службы (PaaS).
Независимо от модели службы, старайтесь обеспечить безопасную среду для всех приложений, развернутых на платформе Azure.
Влияние отклонения
Сегментирование рабочих нагрузок способом, отличающимся от вариантов реализации , для иерархии групп управления, может создать сложную структуру политики и управления доступом для управления средой. Примеры включают отклонение от организационной иерархической структуры или группировку по службам Azure. Этот компромисс приводит к риску непреднамеренного дублирования и исключений политики, что приводит к операционным и административным издержкам.
Другой распространенный подход, который рассматривают клиенты, — это использование посадочных зон для рабочих нагрузок разработки, тестирования и производства. Дополнительные сведения см. в разделе часто задаваемых вопросов, вопрос : «Как мы обрабатываем целевые зоны рабочей нагрузки „dev/test/production“ в архитектуре корпоративного масштаба?».
Согласование с собственным дизайном и дорожной картой Azure
По возможности используйте собственные службы и возможности платформы Azure. Выравнивайте этот подход с планами платформы Azure, чтобы обеспечить доступность новых возможностей в средах. Дорожные карты платформы Azure должны помочь в разработке стратегии миграции и концептуальной траектории посадочных зон Azure.
Влияние отклонения
Внедрение сторонних решений в среду Azure может создать зависимость от этих решений для предоставления поддержки функций и интеграции со службами Azure.
Иногда внедрение существующих инвестиций в сторонние решения в среду неизбежно. Рассмотрим этот принцип и его компромиссы тщательно, в соответствии с вашими требованиями.
Рекомендации
Будьте готовы к компромиссу с функциональными возможностями, потому что вряд ли все будет необходимо в день один. Используйте предварительные версии служб и ориентируйтесь на планы развития служб для устранения технических препятствий.
Помните, что не все аспекты требуемой операционной модели будут находиться в общедоступной доступности при использовании этого подхода.