Создание общих вендинг по подписке продуктов
Vending по подписке помогает организациям достичь принципов проектирования подписок целевых зон Azure, которые критически важны для согласованного масштабирования, безопасности и управления средами Azure. Кроме того, vending подписки помогает организациям соответствовать принципам проектирования платформы. Дополнительные сведения см. в разделе "Внедрение мышления продукта" и "Расширение возможностей разработчиков" с помощью самообслуживания с помощью охранников.
Многие организации изо всех сил пытаются предоставить группам приложений гибкость, которую они должны эффективно предоставлять своим рабочим нагрузкам и службам. Одним из ключевых препятствий является отсутствие стандартизованного подхода к вендинг по подписке, что может привести к путанице, задержке и неэффективности.
В этой статье описывается, как команды платформы могут создавать общие вендинг по подписке линейки продуктов, которые удовлетворяют различным потребностям различных команд приложений. В статье рассматриваются преимущества предложения различных линий продуктов и приведены примеры распространенных сценариев на основе реальных развертываний клиентов. Вы также узнаете, почему вендинг по подписке не имеет "один размер соответствует всем" дизайн и почему необходимо предоставить различные линии продуктов группам приложений.
На следующей схеме показана организация групп управления и подписок в среде Azure.
В следующем руководстве описывается, почему могут потребоваться различные линии продуктов и описываются примеры строк продуктов для клиентов, использующих целевые зоны Azure и вендинг по подписке.
Воспользуйтесь различными линиями продуктов
Подписки, необходимые командам приложений для доставки рабочих нагрузок и служб, предоставляются во многих типах и стилях. Вне групп приложений ваша организация может иметь другие требования, необходимые для использования подписки Azure, например различных правил соответствия и обработки данных или шаблонов архитектуры.
При принятии решения о подходе вашей организации к проектированию и реализации вендинг по подписке рекомендуется задавать следующие вопросы:
Какие другие ресурсы должны выполнять виртуальные машины группы платформ в рамках процесса вендинг по подписке?
Для каждой команды приложений по умолчанию развертывается несколько подписок, например одна на среду?
Для каждого приложения вы используете одноранговый узел или подключаете периферийную виртуальную сеть к центрам подключения по умолчанию?
Как структурировать управление доступом на основе ролей (RBAC) в каждой подписке?
Как управлять ресурсами и стилями архитектуры или архетипами, которые используются в подписках?
Вы не можете решать уникальные требования каждой команды приложений и платформы с любым типом подписки или стилем подписки, которые вы предоставляете. Команды платформы должны предоставить группам приложений гибкость в выборе нескольких типов и стилей подписок, которые команда может предоставлять им через систему самообслуживания. Эти типы подписок называются линиями продуктов.
Организации, которые предоставляют только один размер подходит всем" подход к вендинг по подписке часто ограничивают гибкость своих внутренних клиентов. Например, отсутствие гибкости может ограничить выбор архитектуры команды приложений и потенциально привести к компромиссам из-за того, что они были вложены.
Таким образом, командам платформ необходимо предоставить различные линии продуктов для удовлетворения потребностей своей организации. Эта гибкость гарантирует, что потребители могут выбирать линейку продуктов, которая лучше всего соответствует их требованиям.
Управление средами приложений
Ваша организация должна управлять средами приложений для команд приложений в рамках вендинг по подписке процессов и реализаций. Однако вы также должны обеспечить гибкость, чтобы команды приложений могли управлять средами приложений, такими как dev/test/prod, как они хотят при доставке приложений. Дополнительные сведения см. в разделе "Среды", "Подписки" и "Группы управления".
Некоторые службы Azure предоставляют собственные функции, помогающие изолировать среду в одном экземпляре ресурсов в одной подписке Azure, например приложение Azure Service с функцией слотов развертывания. В этом примере команды приложений могут использовать отдельные подписки, поэтому команды не могут воспользоваться полным набором функций служб, предоставляемых Azure. Отдельные подписки также могут увеличить затраты на доставку приложений, включая эксплуатационные и эксплуатационные расходы.
Разработка общих линий продуктов для вендинг по подписке
Теперь, когда вы понимаете, что команды платформ должны предоставлять несколько типов подписок Azure и стилей или линий продуктов для потребителей своей платформы Azure, в этом разделе описывается несколько распространенных продуктов, которые можно использовать в различных отраслях и странах или регионах.
Ваша команда платформы должна использовать эти общие вендинг по подписке линии продуктов в качестве базового плана. Ваша команда может предоставить несколько вариантов для своих потребителей из коробки, которая соответствует приоритету принципа проектирования платформы клиентов . Такой подход позволяет внутренним клиентам использовать принципы проектирования целевой зоны Azure и рекомендации по разработке для доставки рабочих нагрузок и служб, а также управления платформой Azure.
Примечание.
Используйте эти примеры в качестве отправной точки. Вы можете настроить и расширить эти линии продуктов для удовлетворения потребностей вашей организации.
Распространенные линии продуктов для вендинг по подписке включают:
Corp connected: Рабочие нагрузки, требующие традиционного подключения ip-адресов уровня 3 к другим приложениям и локальным средам через подписку на подключение.
Online: рабочие нагрузки, которые подключаются к другим приложениям с помощью современных служб подключения и архитектур, таких как Приватный канал Azure или взаимодействие с помощью предоставляемых API или конечных точек из каждого приложения.
Техническая платформа: рабочие нагрузки, которые создают платформу, на которой можно создавать другие приложения. Например, парк кластеров Служба Azure Kubernetes (AKS), которым управляет команда платформы AKS, может размещать другие приложения в кластерах AKS от имени других команд приложений.
Общий портфель приложений: общие рабочие нагрузки между теми же командами приложений для общего набора тесно связанных приложений. Вы не хотите размещать приложения самостоятельно или с какой-либо конкретной рабочей нагрузкой.
Песочница: область, в которой команды приложений могут создать доказательство концепции (PoC) или минимально жизнеспособного продукта (MVP) и навязать меньше элементов управления, чтобы команда может продвигать разработку, изобретение и свободу создания наилучшего приложения из каталога доступных служб Azure.
Линия продуктов, подключенная к корпоративной сети
Компания, подключенная к продукту, также называемая внутренней или частной линейкой продуктов, для целевой зоны приложений вендинг по подписке обеспечивает подключение через традиционные методы IP-адресов уровня 3. Эту строку продукта можно использовать для обеспечения подключения между ресурсами, которые:
В той же целевой зоне приложения.
В разных целевых зонах приложений, подключенных к корпоративной сети, через брандмауэр Azure или виртуальное сетевое устройство (NVA).
Локальные или разные облака через Azure ExpressRoute или VPN-подключения.
Организации, использующие вендинг по подписке часто включают эту линейку продуктов, так как она тесно соответствует тому, как большинство локальных сред работают сегодня. Однако при необходимости следует использовать только подключенную корпорацию линию продукта. Рекомендуется использовать более современные облачные подходы, такие как линия продуктов Online, когда вы можете.
Совет
Сведения о различиях между корпоративными и онлайн-рабочими нагрузками см. в статье "Что такое назначение групп управления Подключением, Corp и Online"?
На следующей схеме показан пример подключенной к корпоративной вендинг по подписке линии продукта. Эту настройку можно использовать для модели сети концентратора и периферийной сети, чтобы эффективно управлять сетевым трафиком и политиками.
Когда следует использовать связанную корпорацию линию продукта
Используйте подключенную корпорацию линию продуктов, когда:
Вы хотите выполнить миграцию повторного размещения и рефакторинг и сборки приложений на основе пяти rs рационализации.
Вы хотите начать свое путешествие в Azure и знакомы с аналогичной локальной архитектурой.
Вы хотите "поднять и переместить" приложения в Azure.
Вы хотите повысить безопасность между рабочими нагрузками, изолируя приложения в собственные подписки целевой зоны и переходя к принципам микро-сегментации от нулевого доверия без переключения приложений на полностью облачную среду.
Обратите внимание на эти другие аспекты для корпоративной подключенной линии продуктов:
Ваша команда платформы может отправить виртуальную сеть в подписку целевой зоны приложения и пиринговую виртуальную сеть в виртуальную сеть регионального концентратора или концентратор Azure Виртуальная глобальная сеть. Затем команда может использовать средство управления IP-адресами (IPAM) для управления выделением IP-адресов.
Команды платформы обычно не используют виртуальные подсети или другие ресурсы в виртуальной сети. Вместо этого команды платформы назначают эти действия группам приложений, чтобы они могли разрабатывать сети приложений, как они хотят.
Команды платформы используют политику Azure, назначенную группам управления над подпиской, чтобы обеспечить требуемое поведение, например стандартизованные группы безопасности сети (NSG), подключенные к каждой подсети. Команда приложений наследует эту политику Azure и не может изменить ее. Этот подход следует принципу проектирования целевой зоны Azure для демократизации подписок.
Онлайн-линия продукта
Онлайн-линия продуктов, также называемая внешней или общедоступной линией продуктов, для целевой зоны приложений вендинг по подписке не обеспечивает подключение через традиционные методы IP-адресов уровня 3 между ресурсами в других целевых зонах приложений или локально через ExpressRoute или VPN-подключения. Ресурсы в одной подписке целевой зоны веб-приложения могут использовать виртуальные сети для взаимодействия друг с другом с помощью методов IP-адресов уровня 3. Но виртуальные сети обычно не подключаются к региональным центрам подключения или другим целевым зонам приложений.
Вместо этого можно обеспечить подключение через общедоступные интерфейсы между ресурсами, которые:
В разных целевых зонах приложений.
Локальный.
В рабочих нагрузках, которые находятся в разных облаках.
Вы можете защитить подключения с помощью сетевых элементов управления, функций проверки подлинности и функций авторизации, предоставляемых различными платформами как услуга (PaaS), которые используются для создания приложения.
Вы можете использовать Приватный канал службы и частные конечные точки Azure внутри и между подписками целевой зоны веб-приложений для включения и предоставления частного подключения на основе уровня 3 между приложениями. Этот подход также можно использовать между службами PaaS, которые используются в целевых зонах приложений, чтобы предотвратить использование общедоступных интерфейсов этих служб PaaS для контроля безопасности или регулирования.
Вы также можете использовать службу Приватный канал с частными конечными точками для предоставления и публикации приложений, размещенных в сетевых целевых зонах приложений, для корпоративных целевых зон приложений, локальных расположений или других облаков. Частные конечные точки можно разместить в целевых зонах приложений, подключенных к корпоративным приложениям, или непосредственно в центрах подключения, которые затем предоставляют доступ к этим частным конечным точкам с помощью традиционных методов подключения уровня 3, таких как пиринг виртуальных сетей, подключения ExpressRoute или VPN-подключения.
Думайте о линии продуктов целевой зоны онлайн-приложений как изолированные острова. По умолчанию единственными ресурсами, которые могут получить доступ к ресурсам в подписке, являются ресурсы, которые развертываются в одной подписке целевой зоны веб-приложения. Как упоминалось ранее, можно использовать методы, описанные в этой статье, для расширения подключения к другим целевым зонам приложений, локальным расположениям или другим облакам.
Совет
Дополнительные сведения о различиях между корпоративными и онлайн-рабочими нагрузками см. в статье "Что такое назначение групп управления Подключением, Corp и Online?".
На следующей схеме показан пример онлайн-вендинг по подписке линейки продуктов.
Когда следует использовать онлайн-линию продуктов
Используйте онлайн-линию продуктов, когда вы хотите:
Рефакторинг, реархитирование, перестроение и выполнение миграций и сборок приложений на основе пяти rs рационализации.
Предоставьте командам приложений полностью демократизированную целевую зону приложения для использования, даже в отношении конфигурации сети.
Воспользуйтесь преимуществами облачных служб и архитектур.
Значительно улучшить выравнивание с принципами нулевого доверия.
Используйте подключенную корпорацию строку продукта, но частное IP-адресное пространство недоступно или ограничено.
- В этом сценарии следует ознакомиться с рекомендациями по предотвращению исчерпания IPv4 в Azure.
Линейка продуктов технической платформы
Команды, использующие технологические платформы, такие как Решение Azure VMware или виртуальный рабочий стол Azure, должны реализовать линейку продуктов технической платформы. Линейка продуктов технической платформы по сути является вендинг по подписке линейкой продуктов, которая лучше соответствует высоким техническим требованиям. Вы можете использовать линейку продуктов платформы tech platform для размещения больших и сложных рабочих нагрузок, которые обычно размещают несколько приложений для нескольких других команд приложений в организации. Используйте эту строку продукта, если команда приложений управляет только частями приложения, а не базовыми частями платформы технологий.
Совет
Чтобы лучше понять эту линию продукта, рассмотрим следующий пример. Группа технологических платформ, например команда AKS, стремится предложить AKS в качестве управляемой службы другим командам приложений, которые должны запускать свои приложения на платформе AKS. Команда технической платформы AKS предоставляет управление, обслуживание, безопасность и настройку AKS. Поэтому команда приложений поддерживает только свое приложение и развертывает его на платформе.
Вы можете включить следующие продукты в линейку продуктов технической платформы:
Как правило, Среда службы приложений с помощью отдельных планов Служба приложений.
AKS, как правило, через пространства имен в одном или нескольких кластерах.
Azure Виртуальные машины в кластерах или узлах Решение Azure VMware.
Виртуальный рабочий стол Azure для предоставления виртуальных рабочих столов или приложений всей организации.
Эти продукты можно включить в корпоративные илионлайн-линии продуктов в зависимости от требований к технологической платформе, которую ваша команда хочет предоставить в качестве службы другим командам приложений в вашей организации.
Общий портфель приложений
Общая строка продуктов портфеля приложений для целевой зоны приложений вендинг по подписке предназначена для рабочих нагрузок, которые не требуют нескольких отдельных подписок целевой зоны приложения для простых приложений, которые могут быть созданы только из небольшого количества ресурсов Azure.
Команды приложений и отделы могут использовать эту строку продукта для размещения нескольких небольших приложений или общих компонентов, таких как учетные записи хранения или серверы SQL. Команды совместно используют эти компоненты между несколькими собственными приложениями в одной подписке или небольшим количеством подписок.
Внимание
Общая команда владеет подписками, которые вы используете в рамках этой линейки продуктов. Эта команда управляет соответствующим портфелем приложений, развернутых в этой подписке для этой линии продукта. Не используйте эту строку продукта для общих развертываний несвязанных рабочих нагрузок приложений, у которых есть отдельные владельцы портфеля приложений.
Будьте осторожны, чтобы обеспечить постоянную гибкость, управление доступом, управление и поддержку, если ваша организация изменяет одну подписку и использует группы ресурсов для делегирования доступа.
Если вы рассматриваете делегирование групп ресурсов в одной подписке между несколькими командами, следует учитывать следующие рекомендации перед принятием окончательного решения:
| Площадь | Рекомендации |
|---|---|
| Общее владение соответствующим портфелем приложений | — Имеет общего владельца, например бизнес-подразделение отдела, управляет приложениями, чтобы упростить управление изменениями, чтобы он оставался в пределах области утверждения той же сущности. — Убедитесь, что рабочие нагрузки соответствуют согласованному назначению политик в подписке, включая ведение журнала, мониторинг и безопасность. |
| Соблюдение нормативных требований | — Используйте политики IAM и Azure для создания подписок для рабочих нагрузок с требованиями соответствия нормативным требованиям, включая Национальный институт стандартов и технологий (NIST), Центр безопасности Интернета (CIS), Совет по стандартам безопасности индустрии платной карты (PCI SSC), отраслевые требования и региональные требования. Дополнительные сведения см. в статье "Настройка целевых зон Azure". — создание подписок для рабочих нагрузок, использующих требования к конфиденциальности и обработке данных для управления. Отдельные подписки снижают доступ. |
| Политика Azure | Область действия политик Azure для групп управления, подписок, групп ресурсов и ресурсов. Назначьте политики Azure на высоком уровне для эффективного управления при развертывании ресурсов в группах ресурсов. При управлении Политика Azure на уровне области группы ресурсов следует учитывать следующие ограничения: — увеличивает затраты на управление для создания назначений Политика Azure при добавлении новых групп ресурсов в подписки. — увеличивает рабочую нагрузку при управлении изменениями назначений политик — увеличивает пробелы в безопасности и управлении, если не сразу назначать политики группам ресурсов — уменьшает возможность свернуть состояние соответствия на высоких областях, например группы управления и подписки. |
| Ограничения подписки | — Проверьте ограничения, чтобы обеспечить, чтобы приложения не достигли жестких ограничений, которые препятствуют росту. Каждая подписка имеет мягкие и жесткие ограничения для служб Azure. — создание отдельных подписок для приложений, ожидающих больших шаблонов роста, которые соответствуют ограничениям подписки. — Не делитесь подписками с группами приложений из разных подразделений или отделов, чтобы предотвратить шумные проблемы соседей . |
| Выравнивание служб и компонентов Azure | Вы можете развернуть службы, предоставляющие базовые примитивы служб Azure, такие как Виртуальные машины, виртуальные сети и простые службы PaaS в одной группе ресурсов. Но сложность современных составных предложений может потребовать развертывания этих более сложных служб за пределами одной группы ресурсов. Используйте другие демократические подходы к подписке, описанные ранее в этой статье для этих сценариев развертывания. |
| Только команды платформы могут создавать группы ресурсов | При совместном использовании подписки между различными группами приложений в разных подразделениях или отделах вы можете ограничить возможности любой команды создавать группы ресурсов в общей подписке. Это ограничение ограничивает расползание группы ресурсов. Только команда платформы может создавать и управлять новыми группами ресурсов. Этот подход повышает сложность назначений RBAC и создает повышенную зависимость от команд платформы для управления развертываниями приложений, что может препятствовать гибкости и расширению возможностей команд приложений. |
Вы можете разместить подписки, которые вы используете в общей линейке продуктов портфеля приложений в группах управления Corp или Online. Этот метод соответствует рекомендуемой иерархии целевых зон Azure по умолчанию. Кроме того, вы можете поместить подписки под новыми группами управления, если иерархия групп управления вашей организации соответствует рекомендациям, приведенным в статье "Настройка архитектуры целевой зоны Azure для удовлетворения требований".
На следующей схеме показан пример общего портфеля приложений вендинг по подписке линейке продуктов.
Используйте общую строку продуктов портфеля приложений, если:
Ваша команда приложений должна предоставить несколько небольших ресурсов или компонентов, которыми совместно используются их приложения, но компоненты не помещаются непосредственно в какие-либо выделенные целевые зоны приложений.
У вас есть ресурсы или компоненты, которые необходимо совместно использовать между приложениями в одном отделе, но компоненты не помещаются непосредственно в какие-либо выделенные целевые зоны приложений.
Команды платформы технологий хотят размещать большие, управляемые общие службы, такие как AKS, Виртуальный рабочий стол Azure и Решение Azure VMware, чтобы другие команды приложений могли использовать или размещать свои приложения в службах.
Песочница
Используйте строку продукта песочницы для целевой зоны приложений вендинг по подписке, чтобы обеспечить безопасные, легко управляемые и видимые области тестирования для создания pocs или MVP в Azure.
Дополнительные сведения см. в разделе "Песочница целевой зоны" и "Управление средами разработки приложений" в целевых зонах Azure.
Песочницы часто ограничены временем или бюджетом, что означает, что они имеют ограничение времени или бюджетный предел. В этих случаях необходимо либо расширить или удалить песочницу, либо удалить ее.
Если ваша организация не предоставляет линейку продуктов песочницы для команд приложений или других пользователей для тестирования и экспериментов со службами в Azure, команды могут прибегнуть к теневым ИТ-настройкам. Если это так, ваша организация может бороться с предоставлением отчетов и видимости и применением управления к подпискам, которые бизнес-пользователи создают за пределами контроля и надзора вашей группы платформы.
Ваша команда платформы должна обеспечить легкодоступную, желательно самостоятельную работу и автоматически утвержденный доступ к подпискам песочницы для пользователей и команд вашей организации. Предоставьте пользователям и командам доступ к среде, которую ваша команда платформы может просматривать и управлять ими, чтобы предотвратить теневые ИТ-среды , которые команда платформы не может получить доступ к среде или управлению ими, что создает риск.
Песочницы часто следуют сетевому подходу к сетевым подпискам на продукты, так как они не пиринговой связи с другими виртуальными сетями за пределами границ подписки песочницы. Песочницы также часто имеют дополнительные элементы управления, чтобы предотвратить гибридное подключение к локальным расположениям или другим расположениям. Используйте эти элементы управления, чтобы неизвестные источники не могли получать данные из песочниц в неоцененные расположения. Вы можете использовать политику Azure для применения этих элементов управления.
Как и в общем портфеле приложений и линиях продуктов технической платформы, вы также можете поделиться линией продуктов песочницы между командами в одном отделе с теми же рекомендациями. Не создавайте подписку песочницы и не делитесь ею между группами ресурсов. Вместо этого создайте дополнительные подписки песочницы.
Используйте линейку продуктов песочницы, если необходимо предоставить безопасную, безопасную и управляемую подписку Azure всем пользователям в организации, которые хотят экспериментировать, создавать poCs или создавать MVP в Azure. Эти пользователи должны легко управлять и предоставлять им доступ ко всем службам, чтобы предотвратить теневые ИТ-практики .
Сводка и вынос
В этой статье описаны инструкции, которые помогут вам перейти к сложным процессам вендинг по подписке и перейти к реализации.
Определите требования будущих команд приложений, чтобы выбрать вендинг по подписке линейку продуктов, которая лучше всего подходит для них. Определите требования к начальному набору рабочих нагрузок, которые вы создаете или переносите, чтобы помочь определить приоритеты строк продуктов вендинг по подписке, которые требуется включить и предоставить через интерфейс самообслуживания.
Каждая линейка продуктов имеет затраты на реализацию и затраты на обслуживание. Оцените долгосрочные затраты и долгосрочные преимущества и использование.
Клиенты обычно изначально предоставляют следующие вендинг по подписке линии продуктов:
Дополнительные ресурсы
Чтобы продолжить поддержку подхода к проектированию платформы, ознакомьтесь со следующими ресурсами при разработке и реализации вендинг по подписке продуктов и предложений вашей организации:
- Видео. Сколько подписок следует использовать в Azure?
- Целевые зоны платформы и целевые зоны приложений
- Политики, включенные в эталонные реализации целевых зон Azure
- Настройка архитектуры целевой зоны Azure в соответствии с требованиями
- Какова цель групп управления Подключением, Corp и Online?
- Управление средами разработки приложений в целевых зонах Azure
- Принципы проектирования платформы
Следующий шаг
Чтобы получить наилучшие результаты, необходимо автоматизировать как можно больше вендинг по подписке процесса. Используйте рекомендации по реализации автоматизации вендинг по подписке.