Freigeben über

Planen für moderne Anwendungsplattformen

  • Artikel

Anhand der Planmethodik des Cloud Adoption Frameworks können Sie einen Gesamtplan für die Cloudeinführung erstellen, der als Grundlage für die Programme und Teams dient, die bei Ihnen an der cloudbasierten digitalen Transformation beteiligt sind. Dieser Leitfaden enthält Vorlagen für das Erstellen Ihres Backlogs und Pläne für die Vermittlung der erforderlichen Qualifikationen in Ihren Teams, alles auf der Grundlage dessen, was Sie in der Cloud erreichen möchten.

Die Anwendung der Planmethodik konzentriert sich auf die fünf Phasen der Rationalisierung Ihrer digitalen Ressourcen. Bei der standardmäßigen Cloudeinführung liegt der Fokus vor allem auf Geschwindigkeit, Effizienz und Wiederholbarkeit der Migrations- und Modernisierungsprozesse. Ausgehend von den fünf Phasen der Rationalisierung werden bei der Planung in der Regel Rehosting-Optionen mit eingeschränkter paralleler Unterstützung von Überarbeitung (Rearchitecting) und Neuerstellung (Rebuilding) priorisiert.

Digitale Ressourcen

Wenn Sie einen Plan für Ihre digitalen Ressourcen aufstellen, sollten Sie Bestandsdaten sammeln und Ihre Ressourcen rationalisieren. In einem Plan zur Einführung von Containern ist es wichtig, dass alle Ressourcen, z. B. VMs, Daten und Anwendungen, nach der Workload gruppiert werden, die sie unterstützen. Sobald die Gruppierung und grundlegende Rationalisierung abgeschlossen ist, können Sie diese Workloads auswerten, um die Optionen für Paketierung und Zuweisung eines neuen Hosts oder zum Überarbeiten zu bestimmen.

Die Standardvorlage für den Cloudeinführungsplan berücksichtigt die Arten von Arbeiten, die für eine typische Cloudeinführung erforderlich sind. Sie müssen jedoch Aufgaben für die Verpackung der Workload in Container und die Orchestrierung der Containerbereitstellung in Ihren Plan aufnehmen.

Achtung

In diesem Artikel wird davon ausgegangen, dass der Leser die bewährten Methoden aus der Artikelreihe über das Erstellen eines Cloudeinführungsplans in Azure DevOps bereits befolgt hat. Wenn Sie die Umsetzung Ihres Cloudeinführungsplans mithilfe einer Tabelle oder einem anderen Tool zur Projektnachverfolgung überwachen, sind die folgenden Abschnitte weiterhin anwendbar, aber die umsetzbaren Schritte zum Hinzufügen von Daten zu Ihrem Plan müssen angepasst werden.

Warnung

Um eine Strategie für moderne Anwendungsplattformen in Ihre Standardmigrationsprozesse (oder eine Migrationsfactory) integrieren zu können, ist eine ausgereifte Implementierung von Aufgaben im Zusammenhang mit dem Entwerfen von Workloadarchitekturen vor der Migration notwendig. Eine Umsetzung dieser Strategie ohne diese Aufgaben führt zu einer Verzögerung des gesamten Migrationsaufwands und möglicherweise auch zu ungünstigen Architekturentscheidungen für die bereitgestellten Containerhosts und die unterstützenden Workloads.

Identifizieren Sie Kandidatenworkloads

In Szenarios mit modernen Anwendungsplattformen werden längerfristige Renditen, die eine höhere Vorabinvestitionen erfordern, im Vergleich zu effizienteren Migrationsprozessen priorisiert. Die längerfristigen Investitionen werden in bestimmten Teilen des Plans als verstärkter Fokus auf die Ermöglichung von Innovationen und auf die Optimierung von Vorgängen für bestimmte Workloadgruppen dargestellt.

Um die Strategie und den Plan aufeinander auszurichten, müssen zunächst alle Workloads identifiziert werden, die wahrscheinlich durch die Integration moderner Anwendungsplattformen in Ihre Cloudeinführungsstrategie betroffen sind. Diese Annahmen werden vor jeder Implementierung von technischen Änderungen überprüft. Um potenzielle Kandidaten zu identifizieren, können Sie in Ihrem Workloadportfolio nach den folgenden Kriterien suchen:

  • Aktive Entwicklung oder DevOps-Investitionen: Ein Prozentsatz der Produktionsworkloads befindet sich in der aktiven Entwicklung. Einige werden möglicherweise sogar über fortlaufende DevOps-Methoden verwaltet.
  • Portabilität von Workloads: Einige Workloads unterliegen Compliance-, Datenschutz- oder Betriebseinschränkungen, wodurch möglicherweise eine Portabilität zwischen privaten Cloud-, Edge- oder sogar mehreren öffentlichen Cloudanbietern erforderlich wird.
  • Konsolidierung von Workloads: Viele Workloads (insbesondere Workloads mit geringer Auslastung) können Kandidaten für eine Konsolidierung auf Containerhosts sein, wodurch weniger Server/VMs benötigt und die Betriebskosten reduziert werden.
  • Legacy-Workloads: Ältere Workloads können Updates für Betriebssysteme blockieren und sogar eine Migration in die Cloud verhindern. Ältere Workloads, die nicht mit den Azure-Funktionen kompatibel sind, sind möglicherweise Kandidaten für eine Migration auf einen Containerhost.

Dokumentieren Sie Kandidatenworkloads

Hinweis

Die folgende Liste mit Überlegungen sollte nur für Migrationskandidaten erstellt werden, die Sie anhand der oben genannten Kriterien identifiziert haben.

Beim Erstellen eines Cloudeinführungsplans wird jede Workload gemäß den Anweisungen im Abschnitt Definieren und Priorisieren von Workloads dokumentiert. Für alle Workloads, bei denen es sich um Kandidaten für Szenarios mit modernen Anwendungsplattformen handelt, sind vor der Umsetzung des Plans zusätzliche Informationen erforderlich. In diesem Artikel wird beschrieben, wie wichtig die Dokumentation geschäftlicher und technischer Eingaben für die Definition der Workloads ist. Bei den Kandidaten für Szenarios mit modernen Anwendungsplattformen sollten der Workloaddefinition die folgenden Datenpunkte hinzugefügt werden.

Geschäftseingaben

Im Folgenden finden Sie geschäftsbezogene Datenpunkte, die die Entscheidung beeinflussen können, ob bestimmte Workloads in die Strategie für moderne Anwendungsplattformen aufgenommen werden.

  • Compliancefaktoren: Welche spezifischen Compliancekriterien sind bei den Überlegungen im Zusammenhang mit dem Hosten einer bestimmten Workload in einer privaten Cloud ausschlaggebend?
  • Datenschutzfaktoren: Welche Datenschutzmaßnahmen sind bei den Überlegungen im Zusammenhang mit dem Hosten einer bestimmten Workload in einer privaten Cloud ausschlaggebend?
  • Betriebseinschränkungen: Welche betrieblichen Einschränkungen sind bei den Überlegungen im Zusammenhang mit dem Hosten einer bestimmten Workload in einer privaten Cloud ausschlaggebend?
  • Ergebnisse für moderne Anwendungsplattformen: Welcher der folgenden Punkte ist ausschlaggebend für die Bewertung einer bestimmten Workload als Kandidat für einen Container? DevOps, Portabilität, Konsolidierung, Legacy oder mehrere dieser Faktoren.
  • Betriebsmodell: Wird diese Workload zentral (durch eine zentrale IT/CCoE), dezentral (vom Workloadteam) oder über Unternehmensvorgänge (zentraler Support und workloadspezifische Vorgänge) verwaltet?

Technische Eingaben

Im Folgenden finden Sie Datenpunkte der Technologie-Teams, die die Entscheidung beeinflussen können, ob bestimmte Workloads in die Strategie für moderne Anwendungsplattformen aufgenommen werden.

Überlegungen zum Standort:

Überlegungen im Zusammenhang mit dem Ort, an dem die Workload gehostet wird.

  • Hostinganforderung für die öffentliche Cloud: Gibt es bestimmte technische Einschränkungen im Zusammenhang mit den Anforderungen der öffentlichen Cloud?
  • Hostinganforderung für die private Cloud: Gibt es bestimmte technische Einschränkungen im Zusammenhang mit den Anforderungen der privaten Cloud?
  • Hostinganforderung für Edge: Gibt es bestimmte technische Einschränkungen im Zusammenhang mit den Edge-Anforderungen?
  • Portabilitätsanforderungen: Gibt es bestimmte technische Einschränkungen im Zusammenhang mit den Portabilitätsanforderungen?

Überlegungen zu Vorgängen:

Überlegungen im Zusammenhang mit den Vorgängen in Verbindung mit der Plattform, den Hosts und den Workloads.

  • Primäre Cloudplattform: Organisationen sollten eine primäre Cloudplattform definieren, über die Tools zur Vorgangsverwaltung zur Verfügung gestellt werden können. Einige Organisationen verfügen möglicherweise über mehrere primäre Cloudplattformen, um verschiedene Arten von Vorgängen zu verwalten. Welche primäre Cloudplattform ist für den Betrieb dieser Workload geeignet?
  • Zusätzliche Vorgangsplattformen: Wird diese Workload auch von weiteren Vorgangsplattformen verwaltet?
  • Hostinganforderungen für die Cloud: Erfordert diese Workload eine bestimmte Cloudhostingstrategie? Öffentliche Cloud, private Cloud oder Cloudportabilität
  • Standardisierte Orchestrierungsplattform: Wenn das Unternehmen über eine Standardlösung für die Containerorchestrierung verfügt, geben Sie den Namen der zu berücksichtigenden standardisierten Plattform an. Beispiele: Azure Kubernetes Service (AKS), AKS-Engine oder Kubernetes.
  • Überlegungen zur benutzerdefinierten Orchestrierung: Ist eine nicht standardmäßige Orchestrierungsplattform für Container erforderlich? Wenn ja, führen Sie diese Anforderung genauer aus.
  • Standardisierte Hostvorgänge: Es wird davon ausgegangen, dass Workloads nicht schädlich sind und in freigegebenen Containern gehostet werden können, die durch standardisierte Hostvorgänge unterstützt werden. Ist die Workload mit diesem Ansatz kompatibel?
  • Überlegungen zu benutzerdefinierten Hostvorgängen: Welche spezifischen Anforderungen sollten bei der Erstellung von Hostvorgängen für diese Workload berücksichtigt werden, wenn die Workload nicht mit standardisierten Vorgängen kompatibel ist?

Überlegungen zu Anwendungen:

Überlegungen in Bezug auf die anfängliche Entwicklung sowie die zukünftige Weiterentwicklung einer Anwendung.

  • PaaS-Laufzeit (Platform as a Service): Öffentliche Cloudanbieter erzeugen konsistente Anwendungslaufzeiten, die häufig auch als PaaS-Angebote (Platform as a Service) bezeichnet werden. In Azure werden die PaaS-Laufzeiten durch Azure App Service bereitgestellt. Kann diese Anwendung auf einer PaaS-Laufzeitumgebung ausgeführt werden? Welche Laufzeit ist am besten geeignet?
  • Standardisierte Laufzeit: Gibt es eine standardisierte Laufzeit, die von der Organisation bereitgestellt wird, wenn die Anwendung nicht mit einer PaaS-Laufzeit kompatibel ist? Auf welcher Laufzeit wird diese Workload erstellt?
  • Überlegungen zur benutzerdefinierten Laufzeit: Aufgrund welcher spezifischen Überlegungen ist eine benutzerdefinierte Laufzeit für diese Workload erforderlich?
  • Laufzeiteinschränkungen: Gibt es Einschränkungen, die durch die Auswahl der Laufzeit im Zusammenhang mit der Anwendung entstehen?
  • Anwendungsabhängigkeiten: Ist diese Workload von vorhandenen Systemen abhängig, die sich an einem bestimmten Ort (z. B. öffentlich oder privat) befinden? Beispiele wären ein ERP-System wie SAP, das bei einer bestimmten Lösung ausgeführt wird.
  • Data Gravity: Ist diese Workload von einer Datenquelle abhängig, die sich an einem bestimmten Ort befindet (z. B. öffentlich oder privat)? Beispiele hierfür sind eine Abhängigkeit von den Daten in SAP oder in anderen zentralisierten Datenquellen.
  • Überlegungen zu genehmigten Listen: Sind die Überlegungen zu benutzerdefinierten Vorgängen für die Nutzung innerhalb Ihrer Cloudplattform genehmigt? Welche genehmigten Dienste müssen in die Bereitstellung integriert werden?

Überlegungen zu den ursprünglichen Containern

Das Verpacken Ihrer Workloads in Containern ist der erste Teil der Arbeit, der geplant und bearbeitet werden muss. Die zweite Teil ist die Planung des Hostings dieser Container.

PaaS-Lösungen für standardisierte Laufzeiten, Orchestrierung und Vorgänge

Einige Workloads sind sehr eigenständig und profitieren nicht unbedingt von den erweiterten Kontrollen und Infrastrukturanforderungen, die eine große Plattform wie Kubernetes mit sich bringt. Eine Containerisierung Ihrer Workload bedeutet nicht, dass sie in Kubernetes bereitgestellt werden muss. Azure bietet eine Vielzahl von Lösungen zum Ausführen von Workloads innerhalb Ihres Portfolios, die nicht das Maß an Verwaltung und Infrastruktur erfordern, das von AKS benötigt wird. Die folgenden Lösungen würden jeweils diesem Planungsansatz folgen:

Ziehen Sie in Erwägung, eine einfachere Lösung für Ihre Container für Workloads zu verwenden, die voraussichtlich nicht an Komplexität zunehmen und mit den Zwecken und Grenzwerten dieser Lösungen übereinstimmen.

Standardisierte Orchestrierung mit benutzerdefinierten Laufzeiten und Vorgängen in der öffentlichen Cloud

Für Workloads, die nicht auf einer vollständig verwalteten PaaS-Plattform ausgeführt werden können und auf Kontrollen auf Infrastrukturebene angewiesen sind, wechseln Sie zu Azure Kubernetes Service (AKS), wenn Sie sich die Verwendung erweiterter Features zur Bereitstellung wünschen, wie sie von Containerorchestratoren angeboten werden, oder wenn Sie eine zunehmende modulare Komplexität erwarten. AKS bietet eine Lösung für das Containerhosting, aber auch umfassende Optionen für Architektur, SRE, Sicherheit, Bereitstellung, Überwachung und Infrastruktur.

Der Funktionsumfang der Plattform geht mit der Anforderung einher, die Plattform sowohl auf Clusteroperatorebene als auch auf Workloadebene kennenzulernen. Berücksichtigen Sie die Schulung Ihrer Betriebs-, Architektur- und Workloadentwicklungteams in den Zeitplänen für die Migration. Da es sich bei AKS um eine Plattform handelt, sollten Sie außerdem sicherstellen, dass die Workloadteams die Trennung der Verantwortlichkeiten innerhalb dieser Plattform im Vergleich zu ihrer aktuellen Hostingvereinbarung verstehen. Es könnte in mancher Hinsicht ähnlich sein, wird aber wahrscheinlich in anderer Hinsicht neu sein.

Benutzerdefinierte Orchestrierung, Laufzeiten und Vorgänge in der öffentlichen Cloud

Für sehr spezialisierte Workloads oder besondere organisatorische Anforderungen bietet Azure zwei weitere Hauptplattformen im Bereich der Containerorchestrierung.

  • Azure Red Hat OpenShift
  • Azure Service Fabric

Wenn es einen Grund gibt, Alternativen zu untersuchen, stellen Sie sicher, dass Sie Zeit einplanen, um die Vor- und Nachteile aller Plattformoptionen zu verstehen. Die Standardlösung von Azure ist AKS, und in dieser Dokumentation wird davon ausgegangen, dass AKS die ausgewählte Technologie ist.

Standardisieren Sie Vorgänge über Cloudplattformen hinweg

Kunden stellen häufig verschiedene Containerorchestratoren in privaten und öffentlichen Cloud- sowie Edgeumgebungen bereit. Um Vorgänge über diese unterschiedlichen Cloudplattformen hinweg zu standardisieren, können Kunden einen Unified Operations-Ansatz (einheitliche Vorgänge) integrieren, indem sie ihre Vorgangstools auf mehrere Cloudplattformen erweitern.

In Azure können Organisationen Vorgänge für verschiedene Orchestratoren standardisieren, indem sie unterschiedliche Containerhosts in Azure Arc für Kubernetes integrieren. Dieses Tool stellt eine konsistente Überwachung und Governance sowie einheitliche Vorgänge für jeden Containerhost sicher.

Anwendungslaufzeiten in privaten Cloud- und Edgeumgebungen

Wenn Workloads in einer privaten Cloud- oder Edgeumgebung ausgeführt werden müssen, aber eigentlich am besten durch eine PaaS-Laufzeit unterstützt werden, gibt es einige Tools, über die Entwickler mithilfe von Azure App Service auf konsistenten PaaS-Laufzeiten aufbauen können:

  • Azure Stack HCI: Ermöglicht das native Hosten von Azure App Service auf Azure Stack, das vom Azure Stack-Betreiber verwaltet wird.
  • Azure Stack HCI für AKS: Ermöglicht das Hosten von benutzerdefinierten Laufzeiten, die in AKS innerhalb von Azure Stack ausgeführt werden und von Azure Stack- und AKS-Betreibern verwaltet werden, um eine Portabilität zu anderen Kubernetes-Lösungen zu ermöglichen.
  • Azure App Service in Kubernetes mit Azure Arc: Ermöglicht jedem Kubernetes-Host die Bereitstellung von Anwendungsdiensten in Azure. Alle Hosts werden zu einer kleinen Instanz von Azure App Service. Da jeder Host auch in Azure Arc integriert ist, können sie auch mithilfe von einheitlichen cloudbasierten Hostvorgängen verwaltet werden.

Readiness-Plan für moderne Anwendungsplattform

Zusätzlich zum Qualifizierungsplan für die Cloudeinführung müssen die Cloudeinführungsteams möglicherweise Qualifikationen im Zusammenhang mit Containern und Kubernetes entwickeln, bevor sie Ihren Plan umsetzen können:

Stellen Sie sicher, dass den Workloadteams Zeit für die Dokumentation und den Probelauf der Migrationspläne zugewiesen wird. Die vorhandene Anwendung oder das externe System (sowohl die Abhängigkeiten als auch die Systeme, die von dieser Workload abhängen) müssen möglicherweise mit zusätzlicher Flexibilität ergänzt werden, um den Migrationsaufwand zu unterstützen. Dies gilt sowohl für Vorproduktions- als auch für Produktionsumgebungen.

Nächster Schritt: Überprüfen Ihrer Umgebung oder Azure-Zielzone

Die folgenden Artikel enthalten Anleitungen zu bestimmten Aspekten des Cloudeinführungsprozesses, die Ihnen dabei helfen sollen, die Cloudeinführung erfolgreich abzuschließen.