Cloudrationalisierung

Cloudrationalisierung bezeichnet die Untersuchung von Ressourcen, um die bestmögliche Migrations- oder Modernisierungsmethode für die jeweilige Ressource in der Cloud zu ermitteln. Weitere Informationen zum Rationalisierungsprozess finden Sie unter Worum handelt es sich bei digitalen Ressourcen?

Rationalisierungskontext

Die in diesem Artikel aufgeführten fünf Phasen der Rationalisierung sind eine großartige Möglichkeit zur Bezeichnung eines potenziellen zukünftigen Zustands für jede Workload, die als Cloudkandidat betrachtet wird. Setzen Sie diesen Bezeichnungsprozess in den richtigen Kontext, bevor Sie versuchen, eine Umgebung zu rationalisieren. Überprüfen Sie die folgenden Mythen, um diesen Kontext bereitzustellen:

Mythos: Es ist einfach, Rationalisierungsentscheidungen in einem frühen Stadium des Prozesses zu treffen.

Eine gute Rationalisierung erfordert ein fundiertes Wissen in Bezug auf die Workload und die damit verbundenen Ressourcen wie Anwendungen, Infrastruktur und Daten. Am wichtigsten ist, dass fundierte Rationalisierungsentscheidungen Zeit in Anspruch nehmen. Wir empfehlen die Verwendung eines inkrementellen Rationalisierungsprozesses.

Mythos: Die Cloudeinführung muss darauf warten, dass alle Workloads rationalisiert sind.

Die Rationalisierung eines gesamten IT-Portfolios oder sogar eines einzelnen Rechenzentrums kann die Realisierung des Geschäftswerts um Monate oder sogar Jahre verzögern. Vermeiden Sie nach Möglichkeit eine vollständige Rationalisierung. Verwenden Sie stattdessen den Zehnerpotenzansatz für die Releaseplanung, um kluge Entscheidungen zu den nächsten 10 Workloads zu treffen, die für die Cloudeinführung vorgesehen sind.

Mythos: Die geschäftliche Begründung muss warten, bis alle Workloads rationalisiert sind.

Um eine geschäftliche Begründung für eine Cloudeinführung zu entwickeln, machen Sie ein paar grundlegende Annahmen auf Portfolioebene. Wenn die Beweggründe an Innovationen ausgerichtet sind, gehen Sie von einer Umstrukturierung aus. Wenn sie an der Migration ausgerichtet sind, gehen Sie vom Rehosten aus. Diese Annahmen können den Prozess der geschäftlichen Begründung beschleunigen. Während der Bewertungsphase des Einführungszyklus für die einzelnen Workloads werden die Annahmen hinterfragt und die Budgets optimiert.

Überprüfen Sie jetzt die folgenden fünf Phasen der Rationalisierung, um sich mit dem zeitintensiven Prozess vertraut zu machen. Wählen Sie bei der Entwicklung Ihres Cloudeinführungsplans die Option aus, die am besten zu Ihren Beweggründen, Geschäftsergebnissen und der aktuellen Situation passt. Das Ziel der Rationalisierung digitaler Ressourcen ist es, Grundwerte festzulegen, und nicht die Rationalisierung sämtlicher Workloads.

Die fünf Phasen der Rationalisierung

Die folgenden fünf Rs der Rationalisierung beschreiben die gängigsten Optionen für die Rationalisierung.

Zuweisen eines neuen Hosts

Auch Lift & Shift-Migration genannt. Beim Rehosten wird die Ressource im aktuellen Zustand zum gewählten Cloudanbieter migriert. Die Architektur bleibt dabei größtenteils unverändert.

Häufige Motive können Folgendes umfassen:

• Reduzieren der Investitionskosten.
• Freigabe von Platz im Datencenter.
• Erzielen einer schnelle Rendite in der Cloud.

Faktoren für die quantitative Analyse:

• VM-Größe, einschließlich CPU, Arbeitsspeicher und Speicher
• Abhängigkeiten wie Netzwerkdatenverkehr
• Ressourcenkompatibilität.

Faktoren für die qualitative Analyse:

• Änderungstoleranz.
• Geschäftliche Prioritäten.
• Wichtige Unternehmensereignisse.
• Prozessabhängigkeiten.

Refactoring

PaaS-Optionen (Platform-as-a-Service) können zur Senkung der Betriebskosten zahlreicher Anwendungen beitragen. Es empfiehlt sich, eine Anwendung geringfügig umzugestalten, um sie an ein PaaS-basiertes Modell anzupassen.

Umgestalten (Refactoring) bezieht sich auch auf den Anwendungsentwicklungsprozess der Codeumgestaltung, damit eine Anwendung neue Geschäftsmöglichkeiten erschließen kann.

Häufige Motive können Folgendes umfassen:

• Schnellere und kürzere Updates.
• Codeportabilität.
• Höhere Cloudeffizienz zur Unterstützung von Ressourcen, Geschwindigkeit, Kosten und verwalteten Vorgängen

Faktoren für die quantitative Analyse:

• Größe der Anwendungsressource wie CPU, Arbeitsspeicher und Speicher
• Abhängigkeiten wie Netzwerkdatenverkehr
• Benutzerdatenverkehr wie Seitenaufrufe, Verweildauer auf der Seite und Ladezeiten
• Entwicklungsplattformen wie Sprachen, Datenplattformen und Dienste der mittleren Ebene
• Datenbank mit CPU, Arbeitsspeicher, Speicher und Version

Faktoren für die qualitative Analyse:

• Laufende Unternehmensinvestitionen.
• Burstoptionen oder -zeitpläne.
• Geschäftsprozessabhängigkeiten.

Rearchitect (Überarbeiten)

Einige ältere Anwendungen sind nicht mit Cloudanbietern kompatibel. Diese Inkompatibilität wird durch architekturbezogene Entscheidungen verursacht, die bei der Entwicklung der Anwendung getroffen wurden. In diesem Fall muss die Anwendung vor der Transformation ggf. überarbeitet werden.

In anderen Fällen können Anwendungen, die zwar mit der Cloud kompatibel, aber keine nativen Cloudanwendungen sind, unter Umständen kostengünstiger und effizienter betrieben werden, indem die Lösung überarbeitet und in eine native Cloudanwendung umgewandelt wird.

Häufige Motive können Folgendes umfassen:

• Skalierbarkeit und Flexibilität der Anwendung.
• Einfachere Einführung neuer Cloudfunktionen.
• Verwendung verschiedener Technologiestapel.

Faktoren für die quantitative Analyse:

• Größe der Anwendungsressource wie CPU, Arbeitsspeicher und Speicher
• Abhängigkeiten wie Netzwerkdatenverkehr
• Benutzerdatenverkehr wie Seitenaufrufe, Verweildauer auf der Seite und Ladezeiten
• Entwicklungsplattformen wie Sprachen, Datenplattformen und Dienste der mittleren Ebene
• Datenbank mit CPU, Arbeitsspeicher, Speicher und Version

Faktoren für die qualitative Analyse:

• Steigern von Unternehmensinvestitionen
• Betriebskosten.
• Potenzielle Feedbackschleifen und DevOps-Investitionen.

Neu erstellen

In manchen Szenarien kann die Kluft, die für die Weiterverwendung einer Anwendung überwunden werden muss, zu groß sein, um weitere Investitionen zu rechtfertigen. Dies gilt insbesondere für Anwendungen, die die Anforderungen eines Unternehmens bereits erfüllen, aber jetzt mit den aktuellen Geschäftsprozesse nicht mehr unterstützt werden. Erstellen Sie zum Beheben dieses Problems eine neue Codebasis, die auf einen cloudnativen Ansatz ausgerichtet ist.

Häufige Motive können Folgendes umfassen:

• Beschleunigung von Innovationen.
• Schnelleres Erstellen von Anwendungen
• Senkung der Betriebskosten.

Faktoren für die quantitative Analyse:

• Größe der Anwendungsressource wie CPU, Arbeitsspeicher und Speicher
• Abhängigkeiten wie Netzwerkdatenverkehr
• Benutzerdatenverkehr wie Seitenaufrufe, Verweildauer auf der Seite und Ladezeiten
• Entwicklungsplattformen wie Sprachen, Datenplattformen und Dienste der mittleren Ebene
• Datenbank mit CPU, Arbeitsspeicher, Speicher und Version

Faktoren für die qualitative Analyse:

• Sinkende Endbenutzerzufriedenheit
• Durch den Funktionsumfang eingeschränkte Geschäftsprozesse
• Potenzielle Verbesserungen bei Kosten, Erfahrung oder Umsatz.

Replace

Lösungen werden in der Regel mit der besten Technologie und Methode implementiert, die zu diesem Zeitpunkt zur Verfügung steht. Manchmal können SaaS-Anwendungen (Software-as-a-Service) alle erforderlichen Funktionen für die gehostete Anwendung bereitstellen. In diesen Szenarien kann eine Workload zukünftig ersetzt werden, wodurch sie bei der Transformation nicht weiter berücksichtigt werden muss.

Häufige Motive können Folgendes umfassen:

• Standardisierung auf der Grundlage bewährter Branchenmethoden.
• Beschleunigung der Einführung geschäftsprozessbasierter Ansätze
• Umverteilung von Entwicklungsinvestitionen für Anwendungen, die Alleinstellungsmerkmale oder Wettbewerbsvorteile generieren.

Faktoren für die quantitative Analyse:

• Senkung der allgemeinen Betriebskosten
• VM-Größe, einschließlich CPU, Arbeitsspeicher und Speicher
• Abhängigkeiten wie Netzwerkdatenverkehr
• Außer Betrieb zu nehmende Ressourcen.
• Datenbank mit CPU, Arbeitsspeicher, Speicher und Version

Faktoren für die qualitative Analyse:

• Kosten-Nutzen-Analyse der aktuellen Architektur im Vergleich zu einer SaaS-Lösung.
• Geschäftsprozesszuordnungen.
• Datenschemas.
• Benutzerdefinierte oder automatisierte Prozesse.

Nächste Schritte

Sie können diese fünf Phasen der Rationalisierung auf digitale Ressourcen anwenden, damit Sie Rationalisierungsentscheidungen zum zukünftigen Status der einzelnen Anwendungen einfacher treffen können.