Установление общих продуктовых линий для продуктов подписки

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

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

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

На следующей схеме показана организация групп управления и подписок в среде Azure.

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

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

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

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

• Какие другие ресурсы должна предоставлять команда платформ в рамках процесса управления подписками?

• Разворачивает ли каждая команда по приложениям по умолчанию несколько подписок, например, по одной на каждую среду?

• Для каждого приложения вы по умолчанию объединяете периферийную виртуальную сеть в одноранговую сеть с вашими центрами подключения или подключаете её обратно к ним?

• Как структурировать управление доступом на основе ролей (RBAC) в каждой подписке?

• Как управлять ресурсами и стилями архитектуры или архетипами, которые используются в подписках?

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

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

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

Управление средами приложений

Ваша организация должна управлять средами приложений для команд разработчиков приложений в рамках процессов предоставления и внедрения подписок. Однако вы также должны обеспечить гибкость, чтобы команды приложений могли управлять средами приложений, такими как dev/test/prod, как они хотят при доставке приложений. Дополнительные сведения см. в разделе "Среды", "Подписки" и "Группы управления".

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

Проектирование общих линеек продукции для продажи по подписке

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

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

К общим линейкам продуктов для автоматизированных подписок относятся:

• Corp connected: Рабочие нагрузки, требующие традиционной маршрутизации уровня 3 IP, подключения к другим приложениям и локальным средам через абонемент на подключение.

• Online: рабочие нагрузки, которые подключаются к другим приложениям с помощью современных служб подключения и архитектур, таких как Azure Private Link или взаимодействие с помощью вскрытых API или конечных точек каждого приложения.

• Техническая платформа: рабочие нагрузки, которые создают платформу, на которой можно создавать другие приложения. Например, парк кластеров службы Azure Kubernetes (AKS), которым управляет группа платформы AKS, может размещать другие приложения в кластерах AKS от имени других команд приложений.

• Общий портфель приложений: общие рабочие нагрузки между теми же командами приложений для общего набора тесно связанных приложений. Вы не хотите размещать приложения самостоятельно или с какой-либо конкретной рабочей нагрузкой.

• Песочница: область, в которой команды приложений могут создать прототип (PoC) или минимально жизнеспособный продукт (MVP) и навязать меньше элементов управления, для продвижения разработки, изобретения и свободы создания наилучшего приложения из каталога доступных служб Azure.

Линия продуктов, подключенная к корпоративной сети

Линейка продуктов corp connected, также известная как внутренняя или частная линейка продуктов, обеспечивает подключение для подписки на зону посадки приложений через традиционные методы IP уровня 3. Линейку продуктов можно использовать для обеспечения подключения между ресурсами, такими как:

• В той же целевой зоне приложения.

• В разных целевых зонах приложений, подключенных к корпоративной сети, через брандмауэр Azure или виртуальное сетевое устройство (NVA).

• Локальная инфраструктура или различные облака через Azure ExpressRoute или VPN-соединения.

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

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

Когда следует использовать линейку подключенных продуктов?

Используйте линейку продуктов компании corp, когда:

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

• Вы хотите начать свое путешествие в Azure и знакомы с аналогичной локальной архитектурой.

• Вы хотите "поднять и переместить" приложения в Azure.

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

Обратите внимание на эти другие аспекты для корпоративной подключенной линии продуктов:

• Ваша команда, отвечающая за платформу, может разместить виртуальную сеть в подписке целевой зоны приложения и выполнить пиринговую связь с виртуальной сетью регионального концентратора либо с узлом виртуальной глобальной сети Azure. Затем команда может использовать средство управления IP-адресами (IPAM) для управления выделением IP-адресов.

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

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

Онлайн-линия продукта

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

Вместо этого можно обеспечить подключение через общедоступные интерфейсы между ресурсами, которые:

• В разных зонах приземления приложений.

• Локально.

• В рабочих нагрузках, которые находятся в разных облачных средах.

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

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

Вы также можете использовать службу Private Link с частными конечными точками для предоставления и публикации приложений, размещенных в онлайн-зонах размещения приложений, в корпоративные зоны размещения приложений, локальные расположения или другие облака. Частные конечные точки можно разместить в целевых зонах приложений, подключенных к корпоративным приложениям, или непосредственно в центрах подключения, которые затем предоставляют доступ к этим частным конечным точкам с помощью традиционных методов подключения уровня 3, таких как пиринг виртуальных сетей, подключения ExpressRoute или VPN-подключения.

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

На следующей схеме показан пример линии продуктов для автоматической онлайн-продажи подписки.

Когда следует использовать онлайн-линию продуктов

Используйте онлайн-линию продуктов, когда вы хотите:

• Рефакторинг, переархитектурирование, перестроение и выполнение миграций и сборок приложений на основе пяти R рационализации.

• Предоставьте командам приложений полностью демократизированную целевую зону приложения для использования, даже в отношении конфигурации сети.

• Воспользуйтесь преимуществами облачных служб и архитектур.

• Значительно улучшить согласование с принципами нулевого доверия.

• Используйте подключенную продуктовую линию Corp, но частное IP-адресное пространство недоступно или ограничено.

  • В этом сценарии следует ознакомиться с рекомендациями по предотвращению исчерпания IPv4 в Azure.

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

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

Вы можете включить следующие продукты в линейку продуктов технической платформы:

• Среда службы приложений, обычно через отдельные планы службы приложений.

• AKS, обычно используя пространства имен в одном или нескольких кластерах.

• Виртуальные машины Azure в кластерах или узлах решения Azure VMware.

• Виртуальный рабочий стол Azure для предоставления виртуальных рабочих столов или приложений всей организации.

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

Общий портфель приложений

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

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

Если вы рассматриваете делегирование групп ресурсов в одной подписке между несколькими командами, следует учитывать следующие рекомендации перед принятием окончательного решения:

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

На следующей схеме показан пример продуктовой линии автоматов подписки на общий портфель приложений.

Используйте общую продуктовую линейку портфеля приложений, если:

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

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

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

Песочница

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

Дополнительные сведения см. в разделе Среды песочницы посадочной зоны и Управление средами разработки приложений в посадочных зонах Azure.

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

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

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

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

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

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

Сводка и выводы

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

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

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

Как правило, клиенты изначально предоставляют следующие линии продуктов для vending подписки:

• Песочница
• Corp connected
• Онлайн

Дополнительные ресурсы

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

• Видео. Сколько подписок следует использовать в Azure?
• Целевые зоны платформы и целевые зоны приложений
• Политики, включенные в эталонные реализации целевых зон Azure
• Адаптация архитектуры посадочной зоны Azure в соответствии с требованиями
• Какова цель групп управления Подключением, Corp и Online?
• Управление средами разработки приложений в целевых зонах Azure
• Принципы проектирования платформы

Следующий шаг

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