Рекомендации независимых поставщиков программного обеспечения (ISV) для целевых зон Azure

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

Как независимому поставщику программного обеспечения (ISV), создающему и управляющему своим решением на платформе Azure, вам следует обратиться к следующим ресурсам при построении вашей среды Azure.

• Зоны высадки Azure: Предоставляет рекомендации для всей среды Azure.
• Azure Well-Architected Framework: предоставляет рекомендации по архитектуре, применимые ко всем рабочим нагрузкам.
• Проектирование мультитенантных решений в Azure. Предоставляет конкретные рекомендации по архитектуре для мультитенантных решений в Azure.

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

• Вы создаете программное обеспечение, которое клиенты развертывают в своих собственных подписках.
• У вас есть собственный уровень управления и использование сценариев автоматизации или программного обеспечения для развертывания и настройки ресурсов Azure для решений SaaS.
• Вы являетесь небольшим ISV или стартапом и хотите начать с наименьшей возможной стоимости, и вам может не захотеться изначально использовать такие службы, как Брандмауэр Azure и Защита от атак DDoS Azure.
• Вы - крупный SaaS ISV и планируете разделить приложение SaaS на несколько подписок для масштабирования. Вы также хотите сгруппировать подписки, чтобы они соответствовали вашим средам разработки, тестирования, промежуточной и рабочей среды.
• Операционная модель вашей организации отделяет роли корпоративной ИТ-команды и группы продуктов SaaS. Корпоративная ИТ-группа вашей организации может управлять такими ресурсами, как Microsoft Office 365 и Microsoft Teams, и ваша группа продуктов SaaS может отвечать за создание и эксплуатацию продукта SaaS (включая ее центральные компоненты платформы и удостоверений).

Модели развертывания поставщика программного обеспечения

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

Pure SaaS

В чистой модели SaaS программное обеспечение развертывается полностью только в подписках Azure. Конечные клиенты используют программное обеспечение без его развертывания в собственных подписках Azure. На следующей схеме пользователи используют чистое приложение SaaS, предоставляемое isV:

Примерами чистого программного обеспечения SaaS являются электронная почта как услуга, Kafka-as-service, cloud-data-warehouse-as-service и многие описания SaaS в Azure Marketplace.

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

Независимые поставщики программного обеспечения, создающие исключительно решения для SaaS, должны рассмотреть следующие вопросы:

• Должны ли все ресурсы Azure, составляющие наше решение SaaS, находиться в одной подписке Azure или секционироваться по нескольким подпискам Azure?
• Следует ли размещать каждого клиента в собственной выделенной подписке Azure или создавать ресурсы в одной или нескольких общих подписках?
• Как применить шаблон метки развертывания (единицы масштабирования) ко всем уровням нашего решения?
• Как мы можем использовать управление ресурсами Azure в мультитенантных решениях, чтобы избежать проблем масштабирования и ограничений по подписке Azure?

Внедренный клиентом

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

На следующей схеме поставщик программного обеспечения предоставляет пакет программного обеспечения или продукт каталога Azure Marketplace, а пользователи развертывают этот ресурс в собственных подписках Azure вместе с другими рабочими нагрузками:

Другой элемент рабочей нагрузки клиента на схеме может представлять собственную рабочую нагрузку клиента или другой продукт поставщика программного обеспечения, развернутый в подписке Azure. Клиенты часто развертывают несколько продуктов от разных независимых поставщиков программного обеспечения (ISV) в подписках Azure. Они объединяют эти отдельные продукты для создания решений. Например, клиент может развернуть продукт базы данных из одного поставщика программного обеспечения, сетевого виртуального устройства из другого поставщика программного обеспечения и веб-приложения из третьего поставщика программного обеспечения.

Примеры развернутых клиентом продуктов ISV включают множество образов виртуальных машин (таких как сетевые и виртуальные устройства хранилища) и приложения Azure в Azure Marketplace.

Для некоторых решений, развернутых клиентом, организация может предоставлять управление и обновления для решения, развернутого в подписках Azure конечного клиента с помощью Azure Lighthouse или управляемых приложений Azure. Поставщики программного обеспечения, интеграторы решений (SIs) и поставщики управляемых служб (MSPs) могут использовать эту стратегию, если она соответствует их конкретным потребностям.

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

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

Независимые поставщики программного обеспечения (НПО), создающие решения, которые развертываются клиентом, должны учитывать следующие вопросы:

• Должен ли клиент развернуть наше решение в собственной выделенной подписке или в существующей подписке, содержащей связанные рабочие нагрузки?
• Как клиенты должны установить сетевое подключение между существующими рабочими нагрузками (внутри и за пределами Azure) и нашим решением?
• Поддерживает ли наше решение механизмы проверки подлинности из идентификатора Microsoft Entra или требуются ли другие протоколы, такие как LDAP или Kerberos?
• Как уменьшить или устранить нарушения политики Azure, такие как конфликты между шаблонами решений и политиками Azure клиента?

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

Двойное развертывание SaaS

Некоторые решения SaaS взаимодействуют с ресурсами, развернутыми в подписках Azure клиентов или используют их. Эта модель развертывания иногда называется гибридной моделью двойного развертывания SaaS или SaaS. На следующей схеме поставщик программного обеспечения предоставляет размещенное решение SaaS, которое взаимодействует с ресурсами, развернутыми в подписке Azure конечного клиента:

Реальный пример двойного развертывания SaaS — Microsoft Power BI, служба SaaS, которая может опционально использовать локальный шлюз данных Power BI, развернутый на виртуальной машине в подписке Azure клиента.

К другим примерам сценариев двойного развертывания SaaS относятся:

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

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

Поставщикам программного обеспечения, создающим решения SaaS с несколькими моделями развертывания, следует учитывать следующие аспекты:

• Мы учли все аспекты создания как чистых SaaS, так и решений, развернутых клиентом?
• Какие компоненты нашего решения должны размещаться в наших подписках Azure и какие компоненты должны быть развернуты клиентом?
• Как мы можем обеспечить безопасное предоставление и взаимодействие с ресурсами, развернутыми в клиентских подписках Azure?

Принципы создания и реализации посадочной зоны Azure

Принципы проектирования зоны высадки Azure рекомендуют соответствовать местным возможностям платформы Azure, таким как Log Analytics, Azure Monitor и Брандмауэр Azure. Руководство по целевой зоне также предоставляет конкретные варианты реализации целевой зоны Azure.

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

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

Арендаторы Microsoft Entra

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

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

Для некоторых независимых поставщиков программного обеспечения SaaS одна команда управляет корпоративными ресурсами, а отдельная команда управляет решением SaaS. Это разделение может быть по операционным причинам или соответствовать нормативным требованиям. Возможно, ваша корпоративная ИТ-команда не может управлять подписками и ресурсами, связанными с SaaS, поэтому они не могут быть администраторами клиента Microsoft Entra. Если этот сценарий применяется к вам, рассмотрите возможность использования двух отдельных клиентов Microsoft Entra: одного клиента для корпоративных ИТ-ресурсов, таких как Office 365, и одного клиента для ресурсов Azure, составляющих решение SaaS.

Каждый клиент Microsoft Entra должен иметь собственное доменное имя. Если в вашей организации используется два клиента, можно выбрать имя contoso.com для корпоративного клиента Microsoft Entra и contoso-saas-ops.com клиента SaaS Microsoft Entra, как показано на следующей схеме.

Избегайте использования отдельных арендаторов Microsoft Entra для предварительной и рабочей среды. Вместо создания двух клиентов, таких как contoso-saas-ops-preprod.com и contoso-saas-ops-prod.com отдельных подписок Azure, следует создать один клиент Microsoft Entra. Группы управления и Azure RBAC можно использовать для управления доступом к подпискам и ресурсам в рамках этого отдельного клиента.

Дополнительные сведения о работе с несколькими клиентами Microsoft Entra см. в целевых зонах Azure и нескольких клиентах Microsoft Entra, а также в изоляции ресурсов с несколькими клиентами.

Группы управления

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

Группа управления верхнего уровня

Иерархия групп управления вложена в созданную Azure корневую группу управления клиентом . Вы не используете корневую группу клиента напрямую.

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

В качестве поставщика программного обеспечения SaaS у вас может быть один продукт SaaS или у вас может быть несколько отдельных продуктов SaaS или бизнес-линий. Хотя вы обычно должны использовать тот же клиент Microsoft Entra для управления ресурсами Azure во всех продуктах (как описано в разделе клиентов Microsoft Entra ), в некоторых сценариях можно развернуть несколько иерархий групп управления.

Рассмотрим, насколько независимы ваши продукты друг от друга, и спросите себя:

• Все ли наши продукты используют одни и те же платформы для DevOps, удостоверений, безопасности, подключения и ведения журнала?
• Работают ли эти общие службы одной центральной командой?

Если вы ответили на оба вопроса, создайте одну группу управления продуктами SaaS верхнего уровня в корневой группе клиента.

Если вы вместо этого ответили нет, и каждая из продуктов SaaS управляется отдельными группами платформ, рассмотрите возможность создания отдельной группы управления верхнего уровня для каждого продукта, например двух групп управления верхнего уровня SaaS Product-01 и SaaSProduct-02.

Этот подход управления аналогичен подходу тестирования для целевых зон корпоративного масштаба. Однако вместо создания Contoso и Contoso-Canary в корневой группе арендатора в этом подходе компания создаст продукт-специфические группы верхнего уровня Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 и Contoso-SaaS-Product-03. Этот вариант сценария показан на схеме ниже.

Группа управления платформой

В иерархии организации ресурсов целевой зоны Azure группа управления платформой содержит все подписки Azure, в которых размещаются компоненты и общие службы, используемые рабочими нагрузками в подписках целевой зоны. Примеры компонентов, развернутых в подписках платформы и общих служб, включают централизованную инфраструктуру ведения журналов (например, рабочие области Log Analytics), DevOps, безопасность, средства автоматизации, центральные сетевые ресурсы (такие как узловая виртуальная сеть и планы защиты от DDoS атак), а также службы уровня управления ISV.

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

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

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

На следующей схеме показаны две потенциальные реализации группы управления платформой . Вариант A показывает более комплексный сценарий, в котором группа управления платформой содержит три дочерние группы управления: Управление и DevOps, Identity and Security и Connectivity. Каждая дочерняя группа управления содержит подписку с соответствующими ресурсами. Вариант B показывает более простой сценарий, в котором группа управления платформой содержит одну подписку на платформу.

Группа управления зонами посадки

Группа управления Landing Zones содержит подписки Azure, которые включают фактические подсистемы и рабочие нагрузки решения SaaS.

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

• Соответствие: Если подсистема вашего продукта SaaS должна соответствовать стандартам PCI-DSS, рассмотрите возможность создания группы управления PCI DSS в Целевых зонах. Все подписки Azure, содержащие ресурсы в рамках соответствия PCI-DSS, должны быть помещены в эту группу управления.
• Уровни: Рассмотрите возможность создания отдельных архетипов зон размещения для клиентов SaaS с выделенным уровнем и клиентов с бесплатным уровнем. Каждая из дочерних групп управления содержит разные параметры политики Azure. Например, политики в бесплатном тарифе могут ограничивать развертывание только до определенных типов виртуальных машин (SKU), а политики в выделенном тарифе могут требовать развертывания ресурсов в определенные регионы.

Группы управления, специфичные для окружающей среды

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

Одним из распространенных различий между средами является их правила Azure RBAC, например доступ к каждой группе подписок. Например, команды DevOps, SaaSOps, разработки и тестирования могут иметь разные уровни доступа к разным средам.

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

На следующих схемах показаны два возможных варианта. Параметр A показывает сценарий с отдельными подписками для каждой среды, но без групп управления, зависящих от среды. Опция B показывает сценарий SaaS ISV со специфицичными для среды группами управления в группе управления Regular stamps. Каждая группа управления для конкретной среды содержит несколько подписок. Со временем ISV масштабирует свои ресурсы Azure в стране, охватывая увеличивающееся число подписок, с использованием единого набора политик и назначений ролей.

Выберите каждую вкладку, чтобы увидеть две схемы.

Выведенные из эксплуатации и группы управления песочницами

Руководство по организации ресурсов целевой зоны Azure рекомендует включать в управление группы "Изолированные" и "Песочницы" непосредственно под вашей группой управления верхнего уровня.

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

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

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

Примеры зон посадки ISV

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

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

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