Anwendungsbewertung

  • Artikel

Cloudrationalisierung bezeichnet die Untersuchung von Anwendungen, um die bestmögliche Migrations- oder Modernisierungsmethode für die jeweilige Anwendung in der Cloud zu bestimmen.

Beispiele für Visualisierungsmethoden:

  • Zuweisen eines neuen Hosts. Das Zuweisen eines neuen Hosts wird auch als Lift & Shift-Migration bezeichnet. Dabei wird eine aktuelle Anwendung mit minimalen Änderungen in die Cloud verschoben.
  • Umgestalten. Das leichte Umgestalten einer Anwendung, um sie an PaaS-basierte (Platform-as-a-Service) Optionen anzupassen, kann die Betriebskosten senken.
  • Überarbeiten. Sie überarbeiten veraltete Anwendungen, die mit Cloudkomponenten nicht kompatibel sind, oder cloudkompatible Anwendungen, bei denen durch Überarbeiten in eine cloudnative Lösung kostenbezogene oder betriebliche Effizienten erzielt werden können.
  • Neuerstellen. Wenn die Änderungen oder Kosten der Weiterentwicklung einer Anwendung zu umfangreich bzw. zu hoch sind, sollten Sie die Erstellung einer neuen cloudnativen Codebasis in Erwägung ziehen. Das Neuerstellen empfiehlt sich insbesondere für Anwendungen, die die Anforderungen eines Unternehmens bereits erfüllen, jetzt jedoch nicht mehr unterstützt werden oder nicht mehr den aktuellen Geschäftsprozessen entsprechen.

Bevor Sie sich für eine geeignete Strategie entscheiden, analysieren Sie die aktuelle Anwendung, um die Risiken und die Komplexität der einzelnen Methoden zu ermitteln. Betrachten Sie dabei Anwendungslebenszyklus, Technologien, Infrastruktur, Leistung sowie Betrieb und Überwachung. Bewerten Sie bei Architekturen mit mehreren Ebenen die Darstellungsebene, die Dienstebene, die Integrationsebene und die Datenebene.

In den folgenden Checklisten wird eine Anwendung bewertet, um Komplexität und Risiken ihrer Umgestaltung oder Neuerstellung zu ermitteln.

Komplexität und Risiken

Jede der folgenden Faktoren erhöht die Komplexität und/oder die Risiken.

Aufbau

Definieren Sie die allgemeine Architektur, z. B. Webanwendungen, Webdienste, Datenspeicherung oder Zwischenspeicherung.

Faktor Komplexität Risiko
Es kann keine direkte Translation der Anwendungskomponenten in Azure ausgeführt werden. ✔ ✔
Die Anwendung benötigt Codeänderungen, damit sie in Azure ausgeführt werden kann. ✔ ✔
Die Anwendung benötigt umfassende, komplexe Codeänderungen, damit sie in Azure ausgeführt werden kann. ✔ ✔

Business-Treiber

Ältere Anwendungen erfordern möglicherweise umfassende Änderungen, damit sie in die Cloud verschoben werden können.

Faktor Komplexität Risiko
Diese Anwendung gibt es bereits seit mehr als drei Jahren. ✔
Diese Anwendung ist unternehmenskritisch. ✔
Es gibt technologische Hindernisse für die Migration. ✔
Es gibt geschäftliche Hindernisse für die Migration. ✔
Für diese Anwendung gelten Complianceanforderungen. ✔
Die Anwendung unterliegt den Datenanforderungen, die für das Land/die Region spezifisch sind. ✔
Die Anwendung ist öffentlich zugänglich. ✔ ✔

Technologie

Faktor Komplexität Risiko
Dies ist keine webbasierte Anwendung, und sie wird nicht auf einem Webserver gehostet. ✔
Die App wird nicht in Windows IIS gehostet. ✔
Die App wird nicht in Linux gehostet. ✔
Die Anwendung wird in einer Webfarm gehostet, und es werden mehrere Server zum Hosten der Webkomponenten benötigt. ✔ ✔
Die Anwendung erfordert die Installation von Drittanbietersoftware auf den Servern. ✔ ✔
Die Anwendung wird in einem einzigen Rechenzentrum gehostet, und Vorgänge werden an einem einzigen Ort ausgeführt. ✔
Die Anwendung greift auf die Registrierung des Servers zu. ✔
Die Anwendung sendet E-Mails und benötigt Zugriff auf einen SMTP-Server. ✔
Dies ist keine .NET-Anwendung. ✔
Die Anwendung verwendet SQL Server als Datenspeicher. ✔
Die Anwendung speichert Daten auf lokalen Datenträgern und benötigt Zugriff auf die Datenträger, damit sie ordnungsgemäß funktioniert. ✔
Die Anwendung verwendet Windows-Dienste, um asynchrone Vorgänge zu verarbeiten, oder sie benötigt externe Dienste zum Verarbeiten von Daten oder Vorgängen. ✔

Bereitstellung

Berücksichtigen Sie beim Bewerten der Bereitstellungsanforderungen Folgendes:

  • Anzahl täglicher Benutzer
  • Durchschnittliche Anzahl gleichzeitiger Benutzer
  • Erwarteter Datenverkehr
  • Bandbreite in GBit/s
  • Anforderungen pro Sekunde
  • Benötigte Speichermenge

Sie können das Bereitstellungsrisiko mindern, indem Sie Code unter Quellcodeverwaltung in einem Versionskontrollsystem (z. B. Git, Azure DevOps Server oder SVN) speichern.

Faktor Komplexität Risiko
Die Nutzung von vorhandenem Code und Daten ist von höchster Priorität. ✔ ✔
Der Anwendungscode befindet sich nicht unter Quellcodeverwaltung. ✔
Es gibt keinen automatisierten Buildprozess wie Azure DevOps Server oder Jenkins. ✔
Es gibt keinen automatisierten Releaseprozess zum Bereitstellen der Anwendung. ✔ ✔
Die Anwendung verfügt über eine Vereinbarung zum Servicelevel (SLA), die die erwartete Downtime bestimmt. ✔
Die Anwendung hat Spitzen- oder variable Nutzungszeiten oder -lasten. ✔
Die Webanwendung speichert ihren Sitzungszustand im Prozess und nicht in einem externen Datenspeicher. ✔

Operationen (Operations)

Faktor Komplexität Risiko
Die Anwendung verfügt über keine bewährte Instrumentierungsstrategie und kein standardmäßiges Instrumentierungsframework. ✔
Die Anwendung verwendet keine Überwachungstools, und das Betriebsteam überwacht nicht die Leistung der App. ✔
Für die Anwendung ist eine gemessene SLA vorhanden, und das Betriebsteam überwacht die Leistung der Anwendung. ✔
Die Anwendung schreibt in einen Protokollspeicher, ein Ereignisprotokoll, eine Protokolldatei, eine Protokolldatenbank oder in Application Insights. ✔
Die Anwendung schreibt nicht in einen Protokollspeicher, ein Ereignisprotokoll, eine Protokolldatei, eine Protokolldatenbank oder in Application Insights. ✔
Die Anwendung ist im Notfallwiederherstellungsplan der Organisation nicht berücksichtigt. ✔

Sicherheit

Faktor Komplexität Risiko
Die Webanwendung nutzt Active Directory zum Authentifizieren von Benutzern. ✔ ✔
Die Organisation hat Microsoft Entra ID noch nicht konfiguriert oder Microsoft Entra Connect zum Synchronisieren des lokalen AD mit Microsoft Entra ID nicht konfiguriert. ✔
Die Anwendung benötigt Zugriff auf lokale Ressourcen, für die VPN-Konnektivität von Azure erforderlich ist. ✔
Die Organisation hat noch keine VPN-Verbindung zwischen Azure und ihrer lokalen Umgebung konfiguriert. ✔ ✔
Die Anwendung benötigt zum Ausführen ein SSL-Zertifikat. ✔ ✔

Ergebnisse

Ermitteln Sie anhand der obigen Tabellen, ob jeder Faktor für Ihre Anwendung gilt. Zählen Sie die Anzahl der Häkchen für Komplexität und Risiko für die Faktoren, die für Ihre Anwendung gelten.

  • Der erwartete Grad an Komplexität für die Migration der Anwendung zu Azure oder ihre Modernisierung ist: Faktoren der Zuordnungskomplexität / Mögliche Gesamtkomplexitätsfaktoren.
  • Das erwartete Risiko ist: Faktoren der Zuordnungsrisiken / Mögliche Gesamtrisikofaktoren.

Mögliche Gesamtkomplexitätsfaktoren = 28, Mögliche Gesamtrisikofaktoren = 23

Bei Komplexität und Risiko ist ein Scorewert, der aus der obenstehenden Rechnung resultiert, mit <0,3 = niedrig, < 0,7 = mittel, > 0,7 = hoch. Diese Scorewerte bieten eine relative Skala von Komplexität und Risiko.

Umgestalten, Überarbeiten oder Neuerstellen

Berücksichtigen Sie bei den Überlegungen, ob Sie die Anwendung neu hosten, umgestalten, überarbeiten oder neu erstellen möchten, die folgenden Punkte. Viele dieser Faktoren tragen auch zu Komplexität und Risiko bei.

Bestimmen Sie, ob eine direkte Translation der Anwendungskomponenten in Azure möglich ist. Wenn dies der Fall ist, sind keine Codeänderungen erforderlich, um die Anwendung in Azure zu verschieben, und Sie können die Strategien zum Rehosten oder Umgestalten verfolgen. Andernfalls müssen Sie Code neu schreiben, also die Anwendung überarbeiten oder neu erstellen.

Wenn die App Codeänderungen benötigt, bestimmen Sie die Komplexität und den Umfang der benötigten Änderungen. Kleinere Änderungen lassen möglicherweise eine Überarbeitung zu, während bei umfassenden Änderungen u. U. eine Neuerstellung nötig ist.

Rehosten oder Umgestalten

  • Wenn das Verwenden von vorhandenem Code und vorhandenen Daten oberste Priorität hat, sollten Sie eine Umgestaltungsstrategie und keine Umgestaltung oder Neuerstellung in Erwägung ziehen.

  • Wenn zeitliche Faktoren wie die anstehende Schließung von Rechenzentren oder der Vertragsablauf, Ende der Lizenzierung oder Fusionen oder Übernahmen von Belang sind, verschieben Sie die Anwendung möglicherweise am schnellsten per Rehosting in Azure, mit anschließender Umgestaltung, um von den Cloud-Funktionen zu profitieren.

Überarbeiten oder Neuerstellen

  • Wenn es Anwendungen gibt, die in Ihrem Portfolio ähnliche Anforderungen erfüllen, kann dies eine Gelegenheit sein, die gesamte Lösung zu überarbeiten oder neu zu erstellen.

  • Wenn Sie für eine monolithische App eine Mehrebenen- oder Microservicesarchitektur implementieren möchten, müssen Sie die App überarbeiten oder neu erstellen. Wenn die monolithische Struktur erhalten bleiben darf, können Sie sie möglicherweise neu hosten oder umgestalten.

  • Überarbeiten oder erstellen Sie die App neu, um von den Cloud-Funktionen zu profitieren, wenn Sie die App häufiger als einmal pro Jahr aktualisieren möchten, wenn die App Spitzen- oder variable Nutzungszeiten hat oder wenn die App voraussichtlich einen starken Datenverkehr verarbeiten muss.

Bewerten Sie die folgenden Faktoren, um eine Entscheidung über Überarbeitung oder Neuerstellung zu treffen. Die höchste Bewertung gibt die beste Strategie an.

Faktor Rearchitect (Überarbeiten) Neu erstellen
Es gibt andere Anwendungen, die in Ihrem Portfolio ähnliche Anforderungen erfüllen. ✔ ✔
Die Anwendung benötigt geringfügige Codeänderungen, damit sie in Azure ausgeführt werden kann. ✔
Die Anwendung benötigt umfassende, komplexe Codeänderungen, damit sie in Azure ausgeführt werden kann. ✔
Es ist wichtig, vorhandenen Code zu nutzen. ✔
Sie möchten eine monolithische Anwendung in eine Architektur mit mehreren Ebenen verschieben. ✔
Sie möchten eine monolithische Anwendung in eine Microservicesarchitektur verschieben. ✔ ✔
Sie erwarten, dass durch diese App bahnbrechende Funktionen wie KI, IoT oder Bots eingeführt werden. ✔
Unter Funktionalität, Kosten, Infrastruktur und Prozessen ist die Funktionalität der am wenigsten effiziente Aspekt dieser Anwendung. ✔
Die Anwendung erfordert die Installation von Drittanbietersoftware auf den Servern. ✔
Die Anwendung greift auf die Registrierung des Servers zu. ✔
Die Anwendung sendet E-Mails und benötigt Zugriff auf einen SMTP-Server. ✔
Die Anwendung verwendet SQL Server als Datenspeicher. ✔
Die Anwendung speichert Daten auf lokalen Datenträgern und benötigt Zugriff auf die Datenträger, damit sie ordnungsgemäß funktioniert. ✔
Die Anwendung verwendet Windows-Dienste, um asynchrone Vorgänge zu verarbeiten, oder sie benötigt externe Dienste zum Verarbeiten von Daten oder Vorgängen. ✔
Eine Webanwendung speichert ihren Sitzungszustand im Prozess und nicht in einem externen Datenspeicher. ✔
Die App hat Spitzen- und variable Nutzungszeiten und -lasten. ✔ ✔
Sie erwarten, dass die Anwendung starken Datenverkehr verarbeiten muss. ✔ ✔

Nächste Schritte