Designprinzipien für Azure-Zielzonen

Die Referenzarchitektur der Azure-Zielzone gilt universell für alle Azure-Landungszonenprozesse oder -implementierungen. Auf der Grundlage der Architektur dienen eine Reihe von kernen Designprinzipien als Kompass für nachfolgende Designentscheidungen in kritischen technischen Bereichen.

Die Prinzipien sind absichtlich ehrgeizig, um Ihnen zu helfen, ein optimales Design der Zielarchitektur zu erreichen. Wenn Sie eine Implementierung bereitstellen möchten, bei der es sich um eine Referenzarchitektur für Azure-Zielzonen oder eine beliebige Version der Codebasis für die Landezone im Unternehmen handelt, bauen Sie auf der Architektur auf, indem Sie die Designprinzipien anwenden, die in diesem Artikel beschrieben werden.

Verwenden Sie diese Prinzipien in Ihrer Implementierung als nützlichen Leitfaden, um die Vorteile von Cloudtechnologien zu erkennen. Dieser cloudorientierte oder cloudeigene Ansatz stellt Möglichkeiten zum Arbeiten und technischen Optionen für Ihre Organisation dar, die ältere Technologieansätze in der Regel nicht anbieten.

Machen Sie sich mit diesen Prinzipien vertraut, um ihre Auswirkungen und die mit der Abweichung verbundenen Kompromisse besser zu verstehen.

Auswirkungen von Entwurfsabweichungen

Es kann gültige Gründe geben, von den Designprinzipien abzuweichen. Beispielsweise können organisatorische Anforderungen bestimmte Ergebnisse oder Ansätze für das Entwerfen einer Azure-Umgebung diktieren. In solchen Fällen ist es wichtig zu verstehen, welche Auswirkungen die Abweichung auf den Entwurf und die zukünftigen Vorgänge hat. Berücksichtigen Sie sorgfältig die für jedes Prinzip erläuterten Nachteile.

Im Allgemeinen müssen Sie darauf vorbereitet sein, Anforderungen und Funktionen abzuwägen. Ihre Reise zu einer konzeptionellen Architektur entwickelt sich im Laufe der Zeit, während sich die Anforderungen ändern, und Sie lernen von Ihrer Implementierung. Beispielsweise können die Verwendung von Vorschau-Services und das Abhängig-Sein von Service-Roadmaps technische Blocker während der Einführung beseitigen.

Demokratisierung des Abonnements

Die Demokratisierung von Abonnements bietet eine skalierbare Möglichkeit, Anwendungsmigrationen und neue Anwendungsentwicklung zu beschleunigen. Mit diesem Ansatz können Workloadteams unabhängig auf Azure-Abonnements zugreifen und diese verwalten, während sie innerhalb der Plattformgovernance und betriebsbereiter Schutzläufe bleiben.

1. Verwenden Sie Abonnements als Verwaltungseinheiten. Abonnements stellen die grundlegende Grenze zum Organisieren und Verwalten von Azure-Ressourcen dar. Weisen Sie Geschäftseinheiten Abonnements zu, um das Design, die Entwicklung, das Testen und die Migration von Workloads zu unterstützen. Diese Ausrichtung an Geschäftsanforderungen und Prioritäten ermöglicht Portfoliobesitzern und Workloadteams, einen schnelleren Wert zu erzielen.

2. Verwenden Sie Abonnements zum Trennen von Anwendungsumgebungen. Abonnements sollten auch verwendet werden, um Umgebungen im gesamten Lebenszyklus der Softwareentwicklung (SOFTWARE Development Lifecycle, SDLC) zu steuern und zu trennen, z. B. Entwicklung, Tests und Produktion. Diese Trennung verbessert die Governance, verringert das Risiko und unterstützt ein konsistentes Workload-Management. Befolgen Sie die Anleitungen zum Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen.

3. Aktivieren Sie einen Self-Service-Abonnement-Verkaufsvorgang. Richten Sie einen Prozess ein, mit dem Anwendungs- und Serviceteams Abonnements mit minimaler Reibung anfordern und empfangen können. Ein Self-Service- oder near Self-Service-Modell reduziert Verzögerungen durch manuelle Genehmigungen und komplexe Geschäftsabmeldungen. Befolgen Sie die Anleitungen im Abonnementverkauf , um die Bereitstellung zu optimieren und Innovationen zu beschleunigen.

4. Bieten Sie mehrere Abonnementtypen an, um unterschiedliche Anforderungen zu unterstützen. Stellen Sie eine Reihe von Abonnementproduktlinien bereit, die auf verschiedene Workloadszenarien zugeschnitten sind. Mit dieser Flexibilität können Teams den am besten geeigneten Abonnementtyp für ihre Anforderungen auswählen. Weitere Informationen finden Sie in der Einrichtung gemeinsamer Produktlinien für abonnementverkaufte Produkte.

5. Unterstützen Sie Abonnements mit einer skalierbaren Verwaltungsgruppenhierarchie. Verwenden Sie eine gut definierte Verwaltungsgruppenhierarchie , um Abonnements effektiv zu betreiben, zu steuern und zu sichern. Diese Hierarchie ermöglicht die zentralisierte Richtlinienerzwingung und effiziente Organisation mit mehreren Abonnements. Folgen Sie den empfohlenen Hierarchie- und Abonnemententwurfsüberlegungen und Empfehlungen der Azure-Zielzone, um Konsistenz zu gewährleisten.

Auswirkung der Abweichung

• Gemeinsame Verwaltung im Vergleich zu zentralisierten Vorgängen. Eine Möglichkeit, dieses Prinzip zu implementieren, besteht darin, Operationen an Geschäftseinheiten und Workload-Teams zu übertragen. Dadurch erhalten Workloadbesitzer mehr Kontrolle und Eigenständigkeit für ihre Workloads (im Rahmen der Schutzmaßnahmen der Plattformbasis). Organisationen, die zentrale Vorgänge erfordern, möchten möglicherweise keine Kontrolle über Produktionsumgebungen an Teams oder Geschäftseinheiten delegieren. Diese Organisationen müssen möglicherweise ihr Ressourcenorganisationsdesign ändern, um von diesem Prinzip abzuweichen.

• Fehlausrichtung des Betriebsmodells. Das Referenzarchitekturdesign der Azure-Zielzone setzt eine bestimmte Verwaltungsgruppe und Abonnementhierarchie für alle Betriebsverwaltungsabonnements voraus. Diese Hierarchie richtet sich möglicherweise nicht an Ihren Vorgangsansatz. Wenn Ihre Organisation wächst und sich weiterentwickelt, kann sich Ihr Betriebssystem ändern. Das Verschieben von Ressourcen in separate Abonnements kann zu komplizierten technischen Migrationen führen. Überprüfen Sie die Ausrichtungsanleitungen, bevor Sie sich für einen Ansatz verpflichten.

• Fehlender Abonnementverkaufsprozess und Automatisierung. Wenn Sie keinen Abonnementverkaufsprozess und eine zugehörige Automatisierung bereitstellen, unabhängig davon, ob Self-Service oder nicht, werden Anwendungs- und Serviceteams von der Bereitstellung des Werts für Ihre Organisation verzögert, während Abonnements für sie erstellt und die entsprechende Verwaltungsgruppe in der Hierarchie platziert werden. Wenn der Prozess zum Erlangen neuer Abonnements kompliziert ist und lange dauert, können sich Anwendungs- und Serviceteams dazu entscheiden, Abonnements selbst über alternative Abrechnungskonten und vielleicht auch in nicht verwalteten oder geregelten Microsoft Entra-Mandanten zu erstellen, was bedeutet, dass nun Schatten-IT existiert.

Richtliniengesteuerte Governance

Verwenden Sie Azure-Richtlinien, um Leitplanken bereitzustellen und sicherzustellen, dass die Anwendungen, die Sie bereitstellen, den Sicherheits-, Governance- und behördlichen Kontrollen Ihrer Organisation entsprechen, die unabhängig von Implementierungs- und Konfigurationstools sind. Azure Policy bietet Plattformteams die erforderlichen Tools zum Implementieren, Erzwingen, Überwachen und Steuern von Azure-Steuerelementen und Datenebenenvorgängen und -konfigurationen. Dies ermöglicht es dann, die Abonnements zu demokratisieren, idealerweise über einen Self-Service-Prozess, an Anwendungs- und Serviceteams, damit sie den Geschäftlichen Wert für die Organisation schnell bereitstellen können.

Weitere Informationen zur Verwendung von Azure-Richtlinien finden Sie unter Übernehmen von richtliniengesteuerten Schutzläufen.

Auswirkung der Abweichung

Erhöhter Betriebs- und Verwaltungsaufwand. Wenn Sie keine Azure-Richtlinie zum Erstellen von Schutzläufen in Ihrer Umgebung verwenden, erhöhen Sie den Betriebs- und Verwaltungsaufwand für die Aufrechterhaltung der Compliance. Azure-Richtlinie hilft Ihnen, Ihren gewünschten Compliancestatus in Ihrer Umgebung einzuschränken und zu automatisieren.

Einzelne Steuerungs- und Verwaltungsebene

Vermeiden Sie abhängigkeiten von Abstraktionsebenen wie vom Kunden entwickelten Portalen oder Tools. Es wäre am besten, ein konsistentes Erlebnis sowohl für zentrale Abläufe als auch für Arbeitsvorgänge zu bieten. Azure bietet eine einheitliche und konsistente Kontrollebene, die für alle Azure-Ressourcen und Bereitstellungskanäle gilt, die als Azure Resource Manager bezeichnet werden. Die Steuerungsebene unterliegt rollenbasierten Zugriffssteuerungen und richtliniengesteuerten Steuerelementen. Sie können diese Azure-Kontrollebene verwenden, um einen standardisierten Satz von Richtlinien und Steuerelementen einzurichten, die Ihre gesamte Unternehmensfläche steuern.

Auswirkung der Abweichung

Erhöhte Integrationskomplexität. Ein Multivendor-Ansatz für Steuerungs- und Verwaltungsebenen kann die Komplexität von Integrations- und Featureunterstützungsfunktionen zur Folge haben. Das Ersetzen einzelner Komponenten zum Erzielen eines "Best of Breed"-Designs oder Multivendor-Betriebstools hat Einschränkungen und kann unbeabsichtigte Fehler aufgrund von inhärenten Abhängigkeiten verursachen.

Wenn Sie eine vorhandene Investition in Tools für Betrieb, Sicherheit oder Governance integrieren, überprüfen Sie die Azure-Dienste und alle Abhängigkeiten.

Anwendungsorientiertes Dienstmodell

Konzentrieren Sie sich auf anwendungsorientierte Migrationen und Entwicklung, anstatt reine Infrastruktur-Lift-and-Shift-Migrationen wie das Verschieben virtueller Maschinen. Designentscheidungen sollten nicht zwischen alten und neuen Anwendungen, Infrastruktur as a Service-Anwendungen (IaaS)-Anwendungen oder PaaS-Anwendungen (Platform as a Service) unterscheiden.

Unabhängig vom Dienstmodell sollten Sie eine sichere Umgebung für alle Anwendungen bereitstellen, die Sie auf der Azure-Plattform bereitstellen.

Auswirkung der Abweichung

• Erhöhte Komplexität der Governance-Politik. Wenn Sie Workloads anders als die Implementierungsoptionen der Verwaltungsgruppenhierarchie segmentieren, erhöhen Sie die Komplexität bei Governancerichtlinien und Zugriffssteuerungsstrukturen, die Ihre Umgebung steuern. Beispiele dafür sind zum Beispiel das Abweichen von der hierarchischen Struktur der Organisation oder Gruppieren nach Azure-Dienst.

• Erhöhter Betriebsaufwand. Dieser Kompromiss führt zu einem Risiko unbeabsichtigter Richtlinienduplizierung und -ausnahmen, was zu Betriebs- und Verwaltungsaufwand führt.

• Dev/Test/Production ist ein weiterer gängiger Ansatz, den Organisationen berücksichtigen. Weitere Informationen finden Sie unter Wie gehen wir mit "Dev/Test/Production"-Arbeitslast-Landezonen in der Azure-Landezonenarchitektur um.

Ausrichtung an nativen Azure-Entwürfen und -Roadmaps

Verwenden Sie azure-native Plattformdienste und -funktionen wann immer und wo möglich. Dieser Ansatz sollte mit Azure-Plattform-Roadmaps übereinstimmen, um sicherzustellen, dass neue Funktionen in Ihren Umgebungen verfügbar sind. Azure-Plattform-Fahrpläne sollten dabei helfen, die Migrationsstrategie und die konzeptionelle Weiterentwicklung der Azure-Landezone zu gestalten.

Auswirkung der Abweichung

Erhöhte Integrationskomplexität. Die Einführung von Drittanbieterlösungen in Ihre Azure-Umgebung kann eine Abhängigkeit von diesen Lösungen schaffen, um Featureunterstützung und Integration in Azure-Erstanbieterdienste bereitzustellen.

Manchmal ist es unvermeidlich, vorhandene Investitionen in Drittanbieterlösungen in eine Umgebung zu integrieren. Berücksichtigen Sie dieses Prinzip und seine Kompromisse sorgfältig, um Ihre Anforderungen zu erfüllen.

Nächste Schritte

Organisationen befinden sich möglicherweise in verschiedenen Phasen ihrer Cloud-Reisen, wenn sie diese Anleitung überprüfen. Daher können die erforderlichen Aktionen und Empfehlungen für den Fortschritt in Richtung der vorherigen Ergebnisse variieren. Um die besten nächsten Aktionen für Ihre Cloudakzeptanzphase zu verstehen, überprüfen Sie die Reise zur Zielarchitektur.

Um die richtige Implementierungsoption für die Azure-Zielzone auszuwählen, sollten Sie sich mit den Entwurfsbereichen der Azure-Zielzone vertraut machen.