Einrichten gemeinsamer Produktlinien für Abonnementverkauf

Abonnementverkauf hilft Organisationen dabei, die Designprinzipien für dieAbonnementdemokratisierung von Azure-Zielzonen zu erreichen, was für eine konsistente Skalierung, Sicherheit und Governance von Azure-Umgebungen von entscheidender Bedeutung ist. Abonnementverkauf hilft Organisationen auch bei der Ausrichtung an plattformtechnischen Prinzipien. Weitere Informationen finden Sie unter Übernehmen einer Produkt-Denkweise und Fördern von Entwicklern durch Self-Service mit Guardrails.

Viele Organisationen haben Schwierigkeiten, ihren Anwendungsteams die Flexibilität zu geben, die sie benötigen, um ihre Workloads und Dienste effektiv bereitzustellen. Ein zentrales Hindernis ist das Fehlen eines standardisierten Ansatzes für Abonnementverkauf, der zu Verwirrung, Verzögerung und Ineffizienz führen kann.

In diesem Artikel wird erläutert, wie Plattformteams gemeinsame Abonnementverkaufs-Produktlinien einrichten können, die den verschiedenen Anforderungen verschiedener Anwendungsteams entsprechen. Der Artikel erörtert die Vorteile des Angebots verschiedener Produktlinien und liefert Beispiele für gängige Szenarien, die auf realen Kundenbereitstellungen basieren. Außerdem erfahren Sie, warum Abonnementverkauf nicht über ein Design mit einer „Einheitsgröße“ verfügt und warum Sie verschiedene Produktlinien für Anwendungsteams bereitstellen müssen.

Das folgende Diagramm zeigt die Organisation von Verwaltungsgruppen und Abonnements in einer Azure-Umgebung.

Das Diagramm zeigt Elemente wie Verwaltungsgruppen, Zielzonen und Plattformen namens Konnektivität and Identität. Das Diagramm zeigt außerdem Konnektivitätsabonnements mit Komponenten wie einem regionalen Hub und Abonnementverkaufs-Automatisierung, die den Flow und die Beziehungen zwischen verschiedenen Organisationskomponenten angibt. Diese Architektur richtet sich an Azure-Zielzonen.

In den folgenden Anleitungen wird beschrieben, warum Sie möglicherweise verschiedene Produktlinien benötigen, und beschreibt Produktlinienbeispiele für Kunden, die Azure-Zielzonen und Abonnementverkauf verwenden.

Nutzen Sie die Vorteile verschiedener Produktlinien

Abonnements, die Anwendungsteams für die Bereitstellung ihrer Workloads und Dienste benötigen, gibt es in vielen Typen und Stilen. Außerhalb von Anwendungsteams verfügt Ihre Organisation möglicherweise über andere Anforderungen, die die Verwendung eines Azure-Abonnements erfordern, z. B. verschiedene Compliance- und Datenverarbeitungsregeln oder Architekturmuster.

Wenn Sie sich entscheiden, wie Ihr Unternehmen den Abonnementverkauf gestalten und einführen will, sollten Sie sich diese Fragen stellen:

• Welche anderen Ressourcen sollte das Plattformteam im Rahmen des Abonnementverkaufs-Prozesses kaufen?

• Stellen Sie für jedes Anwendungsteam standardmäßig mehrere Abonnements bereit, z. B. eines pro Umgebung?

• Stellen Sie für jede Anwendung standardmäßig eine Peer-Verbindung her oder verbinden Sie das virtuelle Spoke-Netzwerk mit Ihren Konnektivitäts-Hubs?

• Wie sollten Sie die rollenbasierte Zugriffssteuerung (RBAC) innerhalb jedes Abonnements strukturieren?

• Wie sollten Sie Ressourcen und Architekturstile oder Archetypen, die Sie innerhalb von Abonnements verwenden, steuern und kontrollieren?

Sie können nicht die individuellen Anforderungen jedes Anwendungs- und Plattformteams mit einem einzigen Abonnementtyp oder einer einzigen Abonnementart erfüllen, die Sie anbieten. Die Plattformteams müssen den Anwendungsteams die Möglichkeit geben, aus verschiedenen Arten und Stilen von Abonnements zu wählen, die das Team ihnen über ein Self-Service-System anbieten kann. Diese Arten von Abonnements werden als Produktlinien bezeichnet.

Unternehmen, die nur eine Einheitsgröße für den Verkauf von Abonnements anbieten, schränken die Flexibilität ihrer internen Kunden oft ein. Ein Mangel an Flexibilität könnte beispielsweise die Auswahlmöglichkeiten eines Anwendungsteams bei der Architekturgestaltung einschränken und möglicherweise zu Kompromissen führen, weil ihnen etwas vorgesetzt wurde.

Daher müssen Plattformteams verschiedene Produktlinien bereitstellen, um den Anforderungen ihrer Organisation gerecht zu werden. Diese Flexibilität stellt sicher, dass Verbraucher die Produktlinie auswählen können, die ihren Anforderungen am besten entspricht.

Verwalten von Anwendungsumgebungen

Ihr Unternehmen muss Anwendungsumgebungen für Anwendungsteams als Teil Ihrer Prozesse und Implementierungen für den Abonnementverkauf verwalten. Sie sollten jedoch auch Flexibilität bieten, damit Anwendungsteams ihre Anwendungsumgebungen verwalten können, z. B. dev/test/prod, wie sie bei der Bereitstellung von Anwendungen vorgehen möchten. Weitere Informationen finden Sie unter Umgebungen, Abonnements und Verwaltungsgruppen.

Einige Azure-Dienste bieten native Funktionen zur Isolierung einer Umgebung innerhalb einer einzelnen Ressourceninstanz in einem einzelnen Azure-Abonnement, wie z. B. Azure App Service mit seiner Funktion für Bereitstellungsslots. In diesem Beispiel werden Anwendungsteams gezwungen, separate Abonnements zu verwenden, so dass die Teams nicht den vollen Funktionsumfang der von Azure angebotenen Dienste nutzen können. Separate Abonnements können auch die Kosten für die Anwendungszustellung erhöhen, einschließlich Betriebs- und Wartungsaufwand.

Gestaltung gemeinsamer Produktlinien für den Abonnementverkauf

Da Sie nun wissen, dass Plattformteams den Nutzern ihrer Azure-Plattform mehrere Azure-Abonnementtypen und -Stile bzw. Produktlinien anbieten müssen, werden in diesem Abschnitt mehrere gängige Produktlinien beschrieben, die Sie branchen-, länder- oder regionenübergreifend verwenden können.

Ihr Plattformteam sollte diese gängigen Abonnementverkaufs-Produktlinien als Baseline verwenden. Ihr Team kann seinen Kunden von vornherein mehrere Optionen anbieten, was dem Prinzip der Priorisierung von Kundenplattformen entspricht. Dieser Ansatz gibt internen Kunden die Freiheit, Azure-Zielzone-Designprinzipien und Designbereich-Empfehlungen zu nutzen, um ihre Workloads und Dienste bereitzustellen, und bietet außerdem Azure-Plattform-Governance.

Hinweis

Verwenden Sie diese Beispiele als Startpunkt. Sie können diese Produktlinien anpassen und erweitern, um den Anforderungen Ihrer Organisation gerecht zu werden.

Gemeinsame Produktlinien für den Abonnementverkauf sind:

• Corp verbunden: Workloads, die herkömmliche Layer-3-IP-Routing-Konnektivität zu anderen Anwendungen und lokalen Umgebungen über das Konnektivitäts-Abonnement benötigen.

• Online: Workloads, die über moderne Konnektivitätsdienste und -architekturen mit anderen Anwendungen verbunden sind, wie z. B. Azure Private Link oder Interaktion über exponierte APIs oder Endpunkte der einzelnen Anwendungen.

• Tech-Plattform: Workloads, die eine Plattform erstellen, auf der Sie andere Anwendungen erstellen können. Beispielsweise kann eine Azure Kubernetes Service (AKS)-Flotte von Clustern, die ein AKS-Plattformteam verwaltet, andere Anwendungen in seinen AKS-Clustern im Auftrag anderer Anwendungsteams hosten.

• Gemeinsames Anwendungsportfolio: Gemeinsame Nutzung von Workloads durch dieselben Anwendungsteams für eine Reihe von eng miteinander verbundenen Anwendungen. Sie möchten die Anwendungen nicht eigenständig oder mit einer bestimmten Workload hosten.

• Sandbox: Ein Bereich, in dem Anwendungsteams eine Machbarkeitsstudie (proof of concept, PoC) oder ein Minimum Viable Product (MVP) erstellen und weniger Kontrollen auferlegen können, sodass das Team die Entwicklung, den Erfindungsreichtum und die Freiheit fördern kann, die bestmögliche Anwendung aus dem Katalog der verfügbaren Azure-Dienste zu erstellen.

Die mit der Corp verbundene Produktlinie

Die mit der Corp verbundene Produktlinie, die auch als interne oder private Produktlinie bezeichnet wird, für die Anwendung Zielzonen-Abonnementverkauf bietet Konnektivität über herkömmliche Ebene-3-IP-Methoden. Sie können diese Produktlinie verwenden, um die Konnektivität zwischen verschiedenen Ressourcen zu gewährleisten:

• In der gleichen Anwendungszielzone.

• In verschiedenen unternehmensverbundenen Anwendungslandezonen über eine Azure-Firewall oder eine Network Virtual Appliance (NVA).

• Lokal oder in verschiedenen Clouds über Azure ExpressRoute oder VPN-Verbindungen.

Organisationen, die Abonnementverkauf verwenden, integrieren diese Produktlinie häufig, da sie eng mit der Funktionsweise der meisten lokalen Umgebungen übereinstimmt. Allerdings sollten Sie die corp connected-Produktlinie nur im Bedarfsfall verwenden. Es wird empfohlen, bei Bedarf modernere cloudnative Ansätze wie die Online-Produktlinie zu bevorzugen.

Tipp

Informationen zu den Unterschieden zwischen Unternehmens- und Online-Workloads finden Sie unter Was ist der Zweck der Verwaltungsgruppen Konnektivität, Corp und Online?.

Das folgende Diagramm zeigt ein Beispiel für die corp connected Abonnementverkaufs-Produktlinie. Sie können dieses Setup für ein Hub-and-Spoke-Netzwerkmodell verwenden, um den Netzwerkverkehr und die Richtlinien effektiv zu verwalten.

Das Diagramm zeigt ein Beispiel für die corp connected Abonnementverkaufs-Produktlinie mit einer Netzwerkarchitektur, die einen zentralen Routable-Hub mit der IP-Adresse 10.1.0.0/24 umfasst. Der routingfähige Hub ist mit zwei Speichen verbunden: Zielzone A und Zielzone B, mit den IP-Adressen 10.1.1.0/24 bzw. 10.1.2.0/24. Das Diagramm zeigt außerdem Peeringverbindungen des virtuellen Netzwerks zwischen dem Hub und den Zielzonen und anderen nicht angegebenen Zielzonen. Dieses Setup ist typisch für ein Hub-and-Spoke-Netzwerkmodell und hilft dabei, den Netzwerkverkehr und die Richtlinien effizient zu verwalten.

Wann die corp connected-Produktlinie zu verwenden ist

Verwenden Sie die corp connected-Produktlinie, wenn:

• Sie Rehost- und Refactor-Migrationen und Anwendungs-Builds auf der Grundlage der fünf Rs der Rationalisierung durchführen möchten.

• Sie möchten Ihre Reise in Azure beginnen und mit einer ähnlichen lokalen Architektur vertraut sein.

• Sie möchten Anwendungen in Azure per Lift & Shift migrieren.

• Sie möchten die Sicherheit zwischen den Workloads erhöhen, indem Sie Anwendungen in ihre eigenen Zielzone-Abonnements isolieren und sich von Zero-Trust auf die Prinzipien der Mikrosegmentierung zubewegen, ohne die Anwendung jedoch so umzugestalten, dass sie vollständig cloudnativ ist.

Beachten Sie diese anderen Überlegungen für die Produktlinie corp connected:

• Ihr Plattformteam kann das virtuelle Netzwerk in das Anwendungszielzonen-Abonnement einbinden und das virtuelle Netzwerk mit dem virtuellen Netzwerk des regionalen Hubs oder dem Azure Virtual WAN-Hub verbinden. Ihr Team kann dann ein IP-Adressverwaltungstool (IPAM) verwenden, um die IP-Adresszuweisung zu steuern.

• Plattformteams geben in der Regel keine Subnetze oder andere Ressourcen in das Virtual Network ab. Stattdessen weisen Plattformteams diese Aktivitäten den Anwendungsteams zu, damit sie ihre Anwendungsnetzwerke wie gewünscht entwerfen können.

• Plattformteams verwenden eine Azure Policy, die den Verwaltungsgruppen oberhalb des Abonnements zugewiesen ist, um das gewünschte Verhalten zu erzwingen, z. B. standardisierte Netzwerksicherheitsgruppen (NSGs), die an jedes Subnetz angefügt sind. Das Anwendungsteam erbt diese Azure Policy und kann sie nicht bearbeiten. Dieser Ansatz folgt dem Designprinzip der Azure-Zielzone der Demokratisierung von Abonnements.

Die Online-Produktlinie

Die Online-Produktlinie, die auch als externe oder öffentliche Produktlinie bezeichnet wird, für die Anwendungszielzone Abonnementverkauf stellt keine Konnektivität über herkömmliche Layer-3-IP-Methoden zwischen Ressourcen in anderen Anwendungszielzonen oder lokal über ExpressRoute- oder VPN-Verbindungen bereit. Ressourcen, die sich in derselben Zielzone für Onlineanwendungen befinden, können virtuelle Netzwerke nutzen, um über Layer-3-IP-Methoden miteinander zu kommunizieren. Aber die virtuellen Netze werden in der Regel nicht an regionale Konnektivitäts-Hubs oder andere Anwendungszielzonen zurückgespiegelt.

Stattdessen können Sie die Verbindung über öffentliche Schnittstellen zwischen Ressourcen herstellen, die es sind:

• In verschiedenen Anwendungszielzonen.

• Lokal.

• In Workloads, die sich in verschiedenen Clouds befinden.

Sie können die Verbindungen mit Netzwerkkontrollen, Authentifizierungs- und Autorisierungsfunktionen absichern, die von den verschiedenen Platform-as-a-Service-Lösungen (PaaS) bereitgestellt werden, die Sie für die Erstellung der Anwendung verwenden.

Sie können den Private Link-Dienst und private Azure-Endpunkte innerhalb und zwischen Online-Anwendungs-Zielzone-Abonnements verwenden, um private, Ebene-3-basierte Konnektivität zwischen Anwendungen zu aktivieren und bereitzustellen. Sie können diesen Ansatz auch zwischen den PaaS-Diensten verwenden, die Sie innerhalb von Anwendungszielzonen nutzen, um die Nutzung der öffentlichen Schnittstellen dieser PaaS-Dienste aus Sicherheits- oder Regulierungsgründen zu verhindern.

Sie können den Private Link-Service auch mit privaten Endpunkten verwenden, um Anwendungen, die Sie in Online-Anwendungszielzonen hosten, in verbundenen Anwendungszielzonen, an lokalen Standorten oder in anderen Clouds bereitzustellen und zu veröffentlichen. Sie können private Endpunkte entweder in unternehmensverbundenen Anwendungszielzonen oder direkt in Konnektivitäts-Hubs platzieren, die dann den Zugang zu diesen privaten Endpunkten über herkömmliche Layer-3-Konnektivitätsmethoden wie Peering virtueller Netzwerke, ExpressRoute-Verbindungen oder VPN-Verbindungen ermöglichen.

Stellen Sie sich die Produktlinie der Onlineanwendungs-Zielzone als isolierte Inseln vor. Standardmäßig sind die einzigen Ressourcen, die auf Ressourcen innerhalb des Abonnements zugreifen können, die Ressourcen, die Sie innerhalb desselben Abonnements der Online-Anwendungszielzone bereitstellen. Wie bereits erwähnt, können Sie dann die in diesem Artikel beschriebenen Techniken nutzen, um die Konnektivität auf andere Anwendungszielzonen, lokale Standorte oder andere Clouds zu erweitern.

Tipp

Weitere Informationen zu den Unterschieden zwischen den Unternehmens- und Online-Workloads finden Sie unter Was ist der Zweck der Verwaltungsgruppen Konnektivität, Corp und Online?.

Das folgende Diagramm zeigt ein Beispiel für die Online-Abonnementverkaufs-Produktlinie.

Dieses Diagramm zeigt ein Beispiel für eine Produktlinie vom Online-Abonnementverkauf mit einem Netzwerkarchitekturdiagramm, dessen Abschnitte mit Zielzone A, Zielzone B, Zielzone C und Zielzone D bezeichnet sind. Jeder Abschnitt enthält Symbole für Netzwerkelemente wie Datenbanken und Clouddienste, die mit Pfeilen verbunden sind, um den Datenfluss zu zeigen. Ein zentraler Routinghub 10.0.0/24 mit einem Sicherheitssperrsymbol verbindet sich mit anderen Zielzonen, die von Cloudsymbolen dargestellt werden. Wichtig ist, dass keines der virtuellen Netze zusammengeschaltet ist und alle moderne Dienste und Konzepte wie private Verbindungen nutzen, um miteinander zu interagieren.

Wann die Online-Produktlinie verwendet werden soll

Verwenden Sie die Online-Produktlinie, wenn Sie:

• auf der Grundlage der fünf Rs der Rationalisierung Refactoring, Re-Architektur, Rebuild, Migrationen und Anwendungs-Builds durchführen möchten.

• Anwendungsteams eine vollständig demokratisierte Anwendungszielzone zur Verfügung stellen möchten, die sie auch für die Netzwerkkonfiguration nutzen können.

• die Vorteile von cloudnativen Diensten und Architekturen nutzen möchten.

• Die Ausrichtung mit Zero Trust-Prinzipien wird erheblich verbessert.

• Verwenden Sie die Produktlinie corp connected, aber der private IP-Adressraum ist nicht verfügbar oder begrenzt.

  • In diesem Szenario sollten Sie die Anleitung unter Verhindern der IPv4-Erschöpfung in Azure lesen.

Die Tech-Plattform-Produktlinie

Teams, die Technologieplattformen wie Azure VMware Solution oder Azure Virtual Desktop verwenden, sollten die Produktlinie der Technologieplattform implementieren. Die Produktlinie der Technologieplattformen ist im Wesentlichen eine Produktlinie für den Abonnementverkauf, die sich besser für hochtechnische Anforderungen eignet. Sie können die Produktlinie der Technologieplattform nutzen, um große und komplexe Workloads zu hosten und zu verwalten, die in der Regel mehrere Anwendungen für mehrere andere Anwendungsteams in Ihrem Unternehmen hosten. Verwenden Sie diese Produktlinie, wenn Ihr Anwendungsteam nur die Anwendungsteile und nicht die zugrunde liegende Technologieplattform verwaltet.

Tipp

Um diese Produktlinie besser zu verstehen, betrachten Sie das folgende Beispiel. Ein Technologieplattformteam, wie ein AKS-Team, hat das Ziel, AKS als verwalteten Dienst für andere Anwendungsteams anzubieten, die ihre Anwendungen auf der AKS-Plattform ausführen müssen. Das Team der AKS-Tech-Plattform sorgt für die Verwaltung, Wartung, Sicherheit und Konfiguration von AKS. Das Anwendungsteam pflegt also nur seine Anwendung und stellt sie auf der Plattform bereit.

Sie könnten die folgenden Produkte in eine Produktlinie für eine technische Plattform aufnehmen:

• Ein App Service-Umgebung, in der Regel über separate App Service-Pläne.

• AKS, in der Regel über Namespaces innerhalb eines oder mehrerer Cluster.

• Virtuelle Azure-Computer auf Azure VMware Solution-Clustern oder -Hosts.

• Azure Virtual Desktop zum Bereitstellen virtueller Desktops oder Anwendungen für Ihre gesamte Organisation.

Sie können diese Produkte entweder in die corp connected oder in die Online-Produktlinien aufnehmen, je nach den Anforderungen an die Technologieplattform, die Ihr Team anderen Anwendungsteams in Ihrem Unternehmen als Service anbieten möchte.

Gemeinsames Anwendungsportfolio

Die Produktreihe des freigegebenen Anwendungsportfolios für Anwendungszielzone Abonnementverkauf ist für Workloads gedacht, die nicht mehrere separate Anwendungszielzonenabonnements für einfache Anwendungen benötigen, die möglicherweise nur aus einer kleinen Anzahl von Azure-Ressourcen erstellt werden.

Ihre Anwendungsteams und Abteilungen können diese Produktlinie nutzen, um mehrere kleine Anwendungen oder gemeinsam genutzte Komponenten wie Speicherkonten oder SQL Server zu hosten. Die Teams teilen diese Komponenten mit mehreren ihrer eigenen Anwendungen in einem Einzelabonnement oder einer kleinen Anzahl von Abonnements.

Wichtig

Ein gemeinsames Team besitzt Abonnements, die Sie unter dieser Produktlinie verkaufen. Dieses Team verwaltet das zugehörige Portfolio von Anwendungen, die Sie in diesem Abonnement für diese Produktlinie bereitstellen. Verwenden Sie diese Produktlinie nicht für allgemeine Bereitstellungen von nicht miteinander verbundenen Anwendungs-Workloads, die unterschiedliche Besitzer des Anwendungsportfolios haben.

Planen Sie sorgfältig, um kontinuierliche Flexibilität, Zugriffskontrolle, Governance und Wartungsfreundlichkeit zu gewährleisten, wenn Ihr Unternehmen zu einem Einzelabonnement wechselt und Ressourcengruppen zum Delegieren des Zugriffs verwendet.

Wenn Sie die Delegierung von Ressourcengruppen in einem einzigen Abonnement zwischen mehreren Teams in Erwägung ziehen, sollten Sie die folgenden Überlegungen berücksichtigen, bevor Sie eine endgültige Entscheidung treffen:

Bereich	Überlegungen
Gemeinsames Eigentum an verbundenen Anwendungsportfolios	- Ein gemeinsamer Eigentümer, z. B. eine Unternehmenseinheit einer Abteilung, verwaltet die Anwendungen, um die Änderungsverwaltung zu vereinfachen, so dass sie innerhalb des Genehmigungsbereichs der gleichen Entität bleibt. - Stellen Sie sicher, dass Workloads im gesamten Abonnement einer einheitlichen Richtlinienzuweisung folgen, einschließlich Protokollierung, Überwachung und Sicherheit.
Compliance	- Verwenden Sie IAM- und Azure-Richtlinien, um Abonnements für Workloads zu erstellen, die gesetzliche Anforderungen erfüllen müssen, darunter das National Institute of Standards and Technology (NIST), das Center for Internet Security (CIS), das Payment Card Industry Security Standards Council (PCI SSC), Branchenanforderungen und regionale Anforderungen. Weitere Informationen finden Sie unter Azure-Zielzone maßschneidern. - Erstellen Sie Abonnements für Workloads, die Datenschutz- und Datenverarbeitungsanforderungen für Governance verwenden. Einzelne Abonnements reduzieren den Zugriff.
Azure Policy	Azure-Richtlinien auf Verwaltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen anwenden. Weisen Sie Azure-Richtlinien auf hoher Ebene zu, um eine effiziente Governance zu gewährleisten, wenn Sie Ressourcen in Ressourcengruppen bereitstellen. Beachten Sie die folgenden Einschränkungen, wenn Sie Azure Policy auf der Ebene des Ressourcengruppenbereichs verwalten: - Erhöht den Verwaltungsaufwand für die Erstellung von Azure Policy-Zuweisungen, wenn Sie neue Ressourcengruppen zu Abonnements hinzufügen - Erhöht den Workload, wenn Sie Änderungen an Richtlinienzuweisungen verwalten - Erhöht Sicherheits- und Governancelücken, wenn Sie Ressourcengruppen keine Richtlinien sofort zuweisen - Reduziert die Möglichkeit, den Konformitätsstatus auf hoher Ebene, z. B. bei Verwaltungsgruppen und Abonnements, zu erhöhen
Grenzwerte für Abonnements	- Überprüfen Sie die Grenzwerte, um sicherzustellen, dass die Anwendungen nicht an harte Grenzen stoßen, die ein Wachstum verhindern. Jedes Abonnement hat weiche und harte Grenzwerte für Azure-Dienste. - Erstellen Sie separate Abonnements für Anwendungen, die ein starkes Wachstum erwarten lassen und die Abonnementgrenzen erreichen. - Teilen Sie keine Abonnements mit Anwendungsteams aus verschiedenen Unternehmenseinheiten oder Abteilungen, um Probleme mit lauten Nachbarn zu vermeiden.
Azure-Dienste und Featureausrichtung	Sie können Dienste, die grundlegende Azure-Service-Primitive bereitstellen, wie z. B. virtuelle Maschinen, virtuelle Netzwerke und einfache PaaS-Dienste, innerhalb einer einzigen Ressourcengruppe bereitstellen. Die Komplexität moderner zusammengesetzter Angebote kann jedoch erfordern, dass Sie diese komplexeren Dienste außerhalb der Grenzen einer einzelnen Ressourcengruppe bereitstellen. Verwenden Sie für diese Einsatzszenarien andere demokratisierte Abonnementansätze, die weiter oben in diesem Artikel beschrieben wurden.
Nur Plattformteams können Ressourcengruppen erstellen	Wenn Sie ein Abonnement für verschiedene Anwendungsteams in verschiedenen Unternehmenseinheiten oder Abteilungen freigeben, können Sie die Möglichkeit jedes Teams einschränken, neue Ressourcengruppen in dem gemeinsamen Abonnement zu erstellen. Diese Einschränkung schränkt die Ressourcengruppenverwendung ein. Nur das Plattformteam kann neue Ressourcengruppen erstellen und verwalten. Dieser Ansatz erhöht die Komplexität der RBAC-Zuweisungen und führt zu einer stärkeren Abhängigkeit von den Plattformteams bei der Verwaltung der Anwendungsbereitstellung, was die Flexibilität und Handlungsfähigkeit der Anwendungsteams beeinträchtigen kann.

Sie können die Abonnements, die Sie in der Produktlinie des gemeinsam genutzten Anwendungsportfolios verkaufen, entweder den Verwaltungsgruppen Corp oder Online zuordnen. Diese Methode entspricht der standardmäßig empfohlenen Hierarchie der Azure-Zielzonen. Alternativ können Sie die Abonnements unter neuen Verwaltungsgruppen platzieren, wenn die Verwaltungsgruppenhierarchie Ihres Unternehmens den Anweisungen unter Anpassen der Azure-Zielzone-Architektur an die Anforderungen entspricht.

Das folgende Diagramm zeigt ein Beispiel für das gemeinsame Anwendungsportfolio der Abonnementverkaufs-Produktlinie.

Dieses Diagramm zeigt ein Beispiel für das gemeinsame Anwendungsportfolio der Abonnementverkaufs-Produktlinie, das ein Netzwerkarchitekturdiagramm mit einem Routable Hub mit der Bezeichnung 10.0.0.0/24 in der Mitte enthält. Dieser Hub verbindet verschiedene kleinere Elemente, wie eine einzelne virtuelle Maschine oder ein Speicherkonto, für viele Anwendungen, die vom selben Team kontrolliert werden. Dazu gehört ein Routable Spoke mit der Bezeichnung 10.1.1.0/24, der in einem Einzelabonnement in Ressourcengruppen aufgeteilt ist. Das Diagramm zeigt auch zusätzliche Zielzonen, die Symbole für verschiedene Netzwerkkomponenten wie Datenbanken, Speicherdienste und virtuelle Maschinen enthalten, mit denen sich das Share Application Portfolio-Abonnement über Peering virtueller Netzwerke über den Hub verbinden kann.

Verwenden Sie die Produktlinie des freigegebenen Anwendungsportfolios, wenn:

• Ihr Anwendungsteam mehrere kleine Ressourcen oder Komponenten bereitstellen muss, die ihre Anwendungen gemeinsam nutzen, aber die Komponenten nicht direkt in eine der dedizierten Anwendungszielzonen passen.

• Sie Ressourcen oder Komponenten haben, die Sie zwischen Anwendungen in derselben Abteilung gemeinsam nutzen müssen, die aber nicht direkt in eine der dedizierten Anwendungszielzonen passen.

• Technologieplattform-Teams möchten große, gemeinsam genutzte und verwaltete Dienste wie AKS, Azure Virtual Desktop und Azure VMware Solution hosten, damit andere Anwendungsteams ihre Anwendungen auf diesen Diensten nutzen oder hosten können.

Sandbox

Nutzen Sie die Sandbox-Produktlinie für den Abonnementverkauf für Anwendungszielzonen, um sichere, wenig regulierte und sichtbare Testbereiche für die Erstellung von PoCs oder MVPs in Azure bereitzustellen.

Weitere Informationen finden Sie unter Zielzone-Sandbox-Umgebungen und Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen.

Sandboxes sind häufig zeit- oder budgetgeschränkt, was bedeutet, dass sie ein Zeitlimit oder ein Budgetlimit haben. In diesen Fällen müssen Sie die Sandbox erweitern oder entfernen und außer Betrieb nehmen.

Wenn Ihr Unternehmen keine Sandbox-Produktlinie für Anwendungsteams oder andere Personen zum Testen und Experimentieren mit Diensten in Azure bereitstellt, können Teams auf Schatten-IT-Konfigurationen zurückgreifen. Wenn dies der Fall ist, hat Ihr Unternehmen möglicherweise Schwierigkeiten, Berichte und Transparenz zu erstellen und die Governance für Abonnements anzuwenden, die von Geschäftsanwendern außerhalb der Kontrolle und Aufsicht Ihres Plattformteams erstellt werden.

Ihr Plattformteam muss leicht zugänglich, vorzugsweise Self-Service und automatisch genehmigten Zugriff auf Sandbox-Abonnements für die Benutzer und Teams Ihrer Organisation bereitstellen. Ermöglichen Sie Benutzern und Teams den Zugriff auf eine Umgebung, die Ihr Plattformteam einsehen und verwalten kann, um Schatten-IT-Umgebungen zu vermeiden, auf die das Plattformteam nicht zugreifen oder die es nicht kontrollieren kann, was zu Risiken führt.

Sandboxes folgen oft dem Ansatz der Netzwerkkonfiguration von Online-Produktlinien-Abonnements, da sie nicht mit anderen virtuellen Netzwerken außerhalb der Abonnementgrenze der Sandbox verbunden sind. Sandboxes verfügen häufig auch über zusätzliche Kontrollen, um hybride Verbindungen zu lokalen Standorten oder anderen Standorten zu verhindern. Verwenden Sie diese Kontrollen, um zu verhindern, dass unbekannte Quellen Daten aus Sandboxes an nicht zugelassene Orte exfiltrieren können. Sie können eine Azure Policy verwenden, um diese Kontrollen durchzusetzen.

Wie bei den gemeinsam genutzten Produktlinien für das Anwendungsportfolio und die technischen Plattformen können Sie auch die Sandbox-Produktlinie zwischen Teams in derselben Abteilung mit denselben Überlegungen gemeinsam nutzen. Erstellen Sie kein einzelnes Sandbox-Abonnement und teilen Sie es über Ressourcengruppen unter Teams. Erstellen Sie stattdessen zusätzliche Sandbox-Abonnements.

Verwenden Sie die Sandbox-Produktlinie, wenn Sie eine sichere und kontrollierte Azure-Subscription für alle Personen in Ihrem Unternehmen bereitstellen möchten, die in Azure experimentieren, PoCs erstellen oder MVPs entwickeln möchten. Sie müssen diese Benutzer leichtfertig verwalten und ihnen Zugang zu allen Diensten gewähren, um Schatten-IT-Praktiken zu verhindern.

Zusammenfassung und Takeaways

Dieser Artikel enthält eine Anleitung, die Sie bei der Navigation durch komplexe Abonnementverkaufsprozesse und bei der Umsetzung unterstützt.

Bestimmen Sie die Anforderungen Ihrer zukünftigen Anwendungsteams, um die Abonnementverkaufs-Produktlinie auszuwählen, die am besten zu ihnen passt. Ermitteln Sie die Anforderungen für die anfänglichen Workloads, die Sie erstellen oder migrieren, um die Prioritäten für die Produktlinien für den Abonnementverkauf festzulegen, die Sie aktivieren und über eine Self-Service-Schnittstelle bereitstellen möchten.

Jede Produktlinie verfügt über Implementierungskosten und Wartungskosten. Bewerten Sie die langfristigen Kosten im Vergleich zu langfristigen Vorteilen und Nutzungen.

Kunden aktivieren in der Regel zunächst die folgenden Abonnementverkaufs-Produktlinien:

• Sandbox
• Corp connected
• Online

Zusätzliche Ressourcen

Zur weiteren Unterstützung Ihres Plattform-Engineering-Ansatzes sollten Sie die folgenden Ressourcen bei der Entwicklung und Implementierung der Produktlinien und Angebote Ihres Unternehmens für den Abonnementverkauf berücksichtigen:

• Video: Wie viele Abonnements sollte ich in Azure verwenden?
• Plattformzielzonen vs. Anwendungszielzonen
• Referenzimplementierungen für in Azure-Zielzonen integrierte Richtlinien
• Anpassen der Architektur der Azure-Zielzonen an die Anforderungen
• Was ist der Zweck der Verwaltungsgruppen „Konnektivität“, „Corp“ und „Online“?
• Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen
• Prinzipien des Plattform-Engineerings

Nächster Schritt

Um die besten Ergebnisse zu erzielen, sollten Sie den Abonnementverkaufsprozess so umfassend wie möglich automatisieren. Befolgen Sie den Begleitleitfaden zum Implementieren der Automatisierung des Abonnementverkaufs.

Implementierungsleitfaden für Abonnementverkauf