Azure-Zielzonen Entwurfsprinzipien
Die konzeptionelle Architektur für Azure-Zielzonen gilt universell für alle Azure-Zielzonenprozesse oder -implementierungen. Die Architektur basiert auf einer Reihe von zentralen Entwurfsprinzipien, die als Orientierungshilfe für nachfolgende Entwurfsentscheidungen in wichtigen technischen Bereichen dienen.
Die Prinzipien sind bewusst ambitioniert, um Ihnen dabei zu helfen, ein optimales Design der Zielarchitektur zu erreichen. Wenn Sie sich dafür entscheiden, einen Azure-Zielzonenbeschleuniger oder eine beliebige Version der Codebasis für Zielzonen auf Unternehmensebene bereitzustellen, nutzen Sie die Architektur als Grundlage, und wenden Sie die in diesem Artikel beschriebenen Entwurfsprinzipien an.
Verwenden Sie diese Prinzipien in Ihrer Implementierung als Orientierungshilfe, um die Vorteile von Cloudtechnologien zu nutzen. Dieser cloudorientierte (oder cloudnative) Ansatz umfasst Arbeitsweisen und technische Optionen für Ihre Organisation, die bei älteren Technologieansätzen meist nicht verfügbar sind.
Machen Sie sich mit diesen Prinzipien vertraut, um ihre Auswirkungen und die Nachteile einer Abweichung von den Prinzipien besser zu verstehen.
Auswirkungen von Entwurfsabweichungen
Es gibt ggf. berechtigte Gründe, um von den Entwurfsprinzipien abzuweichen. Beispielsweise können organisationsspezifische Anforderungen bestimmte Ergebnisse oder Ansätze für den Aufbau einer Azure-Umgebung erforderlich machen. In solchen Fällen ist es wichtig, die Auswirkungen der Abweichung auf den Entwurf und auf zukünftige Vorgänge zu verstehen. Berücksichtigen Sie sorgfältig die für jedes Prinzip erläuterten Nachteile.
Seien Sie allgemein darauf vorbereitet, Anforderungen und Funktionen auszugleichen. Ihr Weg zu einer konzeptionellen Architektur entwickelt sich im Laufe der Zeit weiter, wenn sich die Anforderungen ändern und Sie aus Ihrer Implementierung lernen. Beispielsweise können Sie durch die Nutzung von Vorschaudiensten und die Verwendung von Dienstroadmaps technische Hürden für die Einführung beseitigen.
Demokratisierung von Abonnements
Verwenden Sie Abonnements als Verwaltungseinheit, und skalieren Sie, um Anwendungsmigrationen und die Entwicklung neuer Anwendungen zu beschleunigen. Richten Sie Abonnements an Geschäftsanforderungen und Prioritäten aus, um Geschäftsbereiche und Portfoliobesitzer zu unterstützen. Stellen Sie Abonnements für Geschäftseinheiten zur Verfügung, um das Entwerfen, Entwickeln und Testen neuer Workloads sowie das Migrieren vorhandener Workloads zu unterstützen.
Unterstützen Sie ein Abonnement mit einer geeigneten Verwaltungsgruppenhierarchie, damit die Organisation im großen Stil effektiv arbeiten kann. Diese Hierarchie ermöglicht eine effiziente Abonnementverwaltung und -strukturierung.
Tipp
Weitere Informationen zur Demokratisierung von Abonnements finden Sie in einem aktuellen YouTube-Video: Azure-Zielzonen: Wie viele Abonnements sollte ich in Azure verwenden?.
Auswirkungen der Abweichung
Gegenüberstellung von dezentralen und zentralisierten Vorgängen: Eine Möglichkeit zur Implementierung dieses Prinzips ist die Zuweisung von Vorgängen zu Geschäftseinheiten und Workloadteams. Dadurch erhalten Workloadbesitzer mehr Kontrolle und Eigenständigkeit für ihre Workloads (im Rahmen der Schutzmaßnahmen der Plattformbasis). Organisationen, die zentrale Vorgänge benötigen, möchten die Kontrolle über Produktionsumgebungen möglicherweise nicht an Workloadteams oder Geschäftseinheiten delegieren. Solche Organisationen müssen ggf. Änderungen an ihrem Entwurf der Ressourcenorganisation vornehmen und von diesem Prinzip abweichen.
Diskrepanz beim Betriebsmodell: Beim Entwurf der konzeptionellen Architektur von Azure-Zielzonen wird eine bestimmte Verwaltungsgruppen- und Abonnementhierarchie für alle Betriebsverwaltungsabonnements vorausgesetzt. Diese Hierarchie weicht möglicherweise von Ihrem Betriebsmodell ab. Ihr Betriebsmodell kann sich ändern, wenn Ihre Organisation wächst und sich weiterentwickelt. Die Verschiebung von Ressourcen in separate Abonnements kann zu komplizierten technischen Migrationen führen. Lesen Sie den Leitfaden für die Ausrichtung, bevor Sie sich auf einen Ansatz festlegen.
Richtlinienbasierte Governance
Verwenden Sie Azure Policy, um Schutzmaßnahmen bereitzustellen und zu gewährleisten, dass die von Ihnen bereitgestellten Anwendungen die Anforderungen der Plattform Ihrer Organisation erfüllen. Azure Policy bietet Anwendungsbesitzern Unabhängigkeit und einen sicheren, ungehinderten Pfad zur Cloud.
Weitere Informationen finden Sie unter Einführen richtliniengesteuerter Schutzmaßnahmen.
Auswirkungen der Abweichung
Erhöhter Betriebs- und Verwaltungsaufwand: Wenn Sie keine Richtlinien zur Einrichtung von Schutzmaßnahmen in Ihrer Umgebung verwenden, erhöhen Sie den Betriebs- und Verwaltungsaufwand für die Gewährleistung der Compliance. Azure Policy hilft Ihnen, den gewünschten Konformitätszustand in Ihrer Umgebung einzuschränken und zu automatisieren.
Eine einzige Steuerungs- und Verwaltungsebene
Vermeiden Sie Abhängigkeiten von Abstraktionsebenen (beispielsweise kundenseitig entwickelte Portale oder Tools). Es empfiehlt sich, sowohl für zentrale Vorgänge als auch für Workloadvorgänge über eine konsistente Erfahrung zu verfügen. Azure bietet eine einheitliche und konsistente Steuerungsebene für alle Azure-Ressourcen und Bereitstellungskanäle. Die Steuerungsebene unterliegt der rollenbasierten Zugriffssteuerung sowie richtlinienbasierten Steuerungen. Mithilfe dieser Azure-Steuerungsebene können Sie standardisierte Richtlinien und Steuerungen für die gesamte Unternehmensumgebung einrichten.
Auswirkungen der Abweichung
Erhöhte Komplexität bei der Integration: Ein Ansatz mit mehreren Anbietern für die Steuerungs- und die Verwaltungsebene kann die Komplexität der Integration und der Featureunterstützung erhöhen. Der Austausch einzelner Komponenten, um einen erstklassigen Entwurf zu erreichen, oder die Verwendung von Tools mehrerer Anbieter bringt Einschränkungen mit sich und kann aufgrund der vorhandenen Abhängigkeiten zu unbeabsichtigten Fehlern führen.
Wenn Sie bereits in Tools für Betrieb, Sicherheit oder Governance investiert haben und diese integrieren möchten, überprüfen Sie die Azure-Dienste und alle Abhängigkeiten.
Anwendungsorientiertes Dienstmodell
Der Fokus sollte auf der anwendungsorientierten Migration und Entwicklung liegen statt auf reinen Infrastrukturmigrationen per Lift & Shift (wie etwa die Migration virtueller Computer). Bei Entwurfsoptionen sollte nicht zwischen alten und neuen Anwendungen, IaaS-Anwendungen (Infrastructure-as-a-Service) oder PaaS-Anwendungen (Platform-as-a-Service) unterschieden werden.
Versuchen Sie unabhängig vom Dienstmodell immer, eine sichere Umgebung für alle auf der Azure-Plattform bereitgestellten Anwendungen zu schaffen.
Auswirkungen der Abweichung
Höhere Komplexität von Governancerichtlinien: Wenn die Segmentierung von Workloads von den Implementierungsoptionen der Verwaltungsgruppenhierarchie abweicht, erhöht sich die Komplexität in Governancerichtlinien und Zugriffssteuerungsstrukturen für Ihre Umgebung. Beispiele dafür sind zum Beispiel das Abweichen von der hierarchischen Struktur der Organisation oder Gruppieren nach Azure-Dienst.
Operativer Mehraufwand: Dieser Kompromiss führt zum Risiko einer unbeabsichtigten Richtlinienduplizierung und damit zu Ausnahmen, die den Betriebs- und Verwaltungsaufwand erhöhen.
Entwicklung, Test und Produktion ist ein weiterer gängiger Ansatz für Organisationen. Weitere Informationen zum Umgang mit Workloadzielzonen für Entwicklung, Test und Produktion in der Azure-Zielzonenarchitektur finden Sie hier.
Ausrichtung an nativen Azure-Entwürfen und -Roadmaps
Nutzen Sie nach Möglichkeit native Azure-Plattformdienste und -Funktionen. Dieser Ansatz sollte mit den Roadmaps der Azure-Plattform übereinstimmen, um sicherzustellen, dass neue Funktionen in Ihren Umgebungen verfügbar sind. Anhand der Roadmaps für die Azure-Plattform lassen sich die Migrationsstrategie und der konzeptionelle Ablauf für Azure-Zielzonen bestimmen.
Auswirkungen der Abweichung
Erhöhte Komplexität bei der Integration: Durch die Einführung von Drittanbieterlösungen in Ihrer Azure-Umgebung kann eine Abhängigkeit von diesen Lösungen entstehen, um Featureunterstützung und die Integration in native Azure-Dienste zu bieten.
Manchmal ist es unvermeidlich, bereits getätigte Investitionen für Lösungen von Drittanbietern in eine Umgebung zu integrieren. Berücksichtigen Sie dieses Prinzip und die damit verbundenen Kompromisse sorgfältig, um sie mit Ihren Anforderungen in Einklang zu bringen.
Nächste Schritte
Organisationen können sich bei der Lektüre dieses Leitfadens in verschiedenen Phasen der Cloudtransformation befinden. Daher können die erforderlichen Maßnahmen und Empfehlungen zum Erreichen der genannten Ergebnisse variieren. Im Artikel „Journey zur Zielarchitektur“ erfahren Sie, welche Aktionen Sie in Ihrer Phase der Cloudeinführung als Nächstes durchführen sollten:
Machen Sie sich mit den Entwurfsbereichen von Azure-Zielzonen vertraut, um sich für die richtige Implementierungsoption für Azure-Zielzonen zu entscheiden.