Cloud-Rationalisierung

Die Cloud-Rationalisierung ist der Prozess der Bewertung von Ressourcen, um die beste Methode zum Migrieren oder Modernisieren der einzelnen Ressourcen in der Cloud zu ermitteln. Weitere Informationen zum Rationalisierungsprozess finden Sie unter "Was ist ein digitaler Nachlass".

Rationalisierungskontext

Die in diesem Artikel aufgeführten fünf Rs der Rationalisierung sind eine hervorragende Möglichkeit, um einen potenziellen zukünftigen Zustand für jeden Workload zu bezeichnen, der als Cloudkandidat betrachtet wird. Setzen Sie diesen Bezeichnungsprozess in den richtigen Kontext, bevor Sie versuchen, eine Umgebung zu rationalisieren. Um diesen Kontext bereitzustellen, überprüfen Sie die folgenden Mythen:

Mythos: Es ist einfach, Rationalisierungsentscheidungen frühzeitig im Prozess zu treffen

Eine gute Rationalisierung erfordert ein tiefes Wissen über die Arbeitsauslastung und die zugehörigen Ressourcen, wie Anwendungen, Infrastruktur und Daten. Am wichtigsten ist, dass gute Rationalisierungsentscheidungen Zeit in Anspruch nehmen. Es wird empfohlen, einen inkrementellen Rationalisierungsprozess zu verwenden.

Mythos: Die Cloudakzeptanz muss warten, bis alle Workloads rationalisiert werden.

Wenn ein gesamtes IT-Portfolio oder sogar ein einzelnes Rechenzentrum rationalisiert wird, kann es die Realisierung des Geschäftswerts um Monate oder sogar Jahre verzögern. Vermeiden Sie möglichst eine vollständige Rationalisierung. Verwenden Sie stattdessen den Power of 10-Ansatz zur Veröffentlichungsplanung , um kluge Entscheidungen über die nächsten 10 Workloads zu treffen, die für die Cloudakzeptanz vorgesehen sind.

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

Um eine geschäftliche Begründung für eine Cloudakzeptanz zu entwickeln, nehmen Sie einige grundlegende Annahmen auf Portfolioebene vor. 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 Geschäftlichen Rechtfertigungsprozess beschleunigen. Während der Bewertungsphase des Einführungszyklus jeder Arbeitslast werden Annahmen hinterfragt, und Budgets werden verfeinert.

Überprüfen Sie nun die folgenden fünf Rs der Rationalisierung, um sich mit dem langfristigen Prozess vertraut zu machen. Wählen Sie beim Entwickeln Ihres Cloudakzeptanzplans die Option aus, die am besten mit Ihren Motivationen, geschäftsergebnissen und der aktuellen Zustandsumgebung übereinstimmt. Ziel der Rationalisierung digitaler Immobilien ist es, einen Basisplan festzulegen, nicht jede Arbeitsauslastung zu rationalisieren.

Die fünf Phasen der Rationalisierung

Die folgenden fünf Rs der Rationalisierung beschreiben die am häufigsten verwendeten Optionen für die Rationalisierung.

Rehosten

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.

Quantitative Analysefaktoren sind:

• VM-Größe, einschließlich CPU, Arbeitsspeicher und Speicher.
• Abhängigkeiten, z. B. Netzwerkdatenverkehr.
• Vermögenswertkompatibilität.

Qualitative Analysefaktoren sind:

• Toleranz für Veränderung.
• Geschäftsprioritäten.
• Kritische Geschäftsereignisse.
• Abhängigkeiten der Prozesse

Umgestalten

Plattform-as-a-Service-Optionen (PaaS) können die Betriebskosten reduzieren, die mit vielen Anwendungen verbunden sind. Es ist ratsam, eine Anwendung leicht umzuschichten, um in ein PaaS-basiertes Modell zu passen.

Refaktorierung bezieht sich auch auf den Prozess der Anwendungsentwicklung, bei dem der Code umgestaltet wird, um einer Anwendung neue Geschäftsmöglichkeiten zu erschließen.

Häufige Treiber können folgendes umfassen:

• Schnellere und kürzere Updates.
• Codeübertragbarkeit.
• Höhere Cloudeffizienz bei Ressourcen, Geschwindigkeit, Kosten und verwalteten Vorgängen.

Quantitative Analysefaktoren sind:

• Größe der Anwendungsressource, z. B. CPU, Arbeitsspeicher und Speicher.
• Abhängigkeiten, z. B. Netzwerkdatenverkehr.
• Benutzerdatenverkehr, z. B. Seitenansichten, Zeit auf der Seite und Ladezeiten.
• Entwicklungsplattformen wie Sprachen, Datenplattformen und Dienste der mittleren Ebene.
• Datenbank, die CPU, Arbeitsspeicher, Speicher und Version enthält.

Qualitative Analysefaktoren sind:

• Fortgesetzte Geschäftsinvestitionen.
• Burstoptionen oder -zeitpläne.
• Geschäftsprozessabhängigkeiten.

Rearchitect (Überarbeiten)

Einige alternde Anwendungen sind nicht mit Cloudanbietern kompatibel. Diese Inkompatibilität liegt an den Architekturentscheidungen, die beim Erstellen der Anwendung getroffen wurden. In diesen Fällen muss die Anwendung vor der Transformation möglicherweise neu erstellt werden.

In anderen Fällen können Anwendungen, die cloudkompatibel, aber nicht cloudnativ sind, Kosteneffizienz und betriebliche Effizienz schaffen, indem sie die Lösung in eine cloudeigene Anwendung umstellen.

Häufige Treiber können folgendes umfassen:

• Anwendungsmaßstab und Flexibilität.
• Einfachere Einführung neuer Cloudfunktionen.
• Mischung aus Technologie-Stacks.

Quantitative Analysefaktoren sind:

• Größe der Anwendungsressource, z. B. CPU, Arbeitsspeicher und Speicher.
• Abhängigkeiten, z. B. Netzwerkdatenverkehr.
• Benutzerdatenverkehr, z. B. Seitenansichten, Zeit auf der Seite und Ladezeiten.
• Entwicklungsplattformen wie Sprachen, Datenplattformen und Dienste der mittleren Ebene.
• Datenbank, die CPU, Arbeitsspeicher, Speicher und Version enthält.

Qualitative Analysefaktoren sind:

• Um Geschäftsinvestitionen zu erhöhen.
• Betriebskosten.
• Potenzielle Feedbackschleifen und DevOps-Investitionen.

Umbauen

In einigen Szenarien kann das Delta, das überwunden werden muss, um eine Anwendung vorwärts zu führen, zu groß sein, um weitere Investitionen zu rechtfertigen. Dieses Problem gilt insbesondere für Anwendungen, die zuvor die Anforderungen eines Unternehmens erfüllten, aber jetzt nicht mehr mit den aktuellen Geschäftsprozessen unterstützt werden. Um das Problem zu beheben, erstellen Sie eine neue Codebasis für die Ausrichtung an einem cloudeigenen Ansatz.

Häufige Motive können Folgendes umfassen:

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

Quantitative Analysefaktoren sind:

• Größe der Anwendungsressource, z. B. CPU, Arbeitsspeicher und Speicher.
• Abhängigkeiten, z. B. Netzwerkdatenverkehr.
• Benutzerdatenverkehr, z. B. Seitenansichten, Zeit auf der Seite und Ladezeiten.
• Entwicklungsplattformen wie Sprachen, Datenplattformen und Dienste der mittleren Ebene.
• Datenbank, die CPU, Arbeitsspeicher, Speicher und Version enthält.

Qualitative Analysefaktoren sind:

• Abnehmende Endbenutzerzufriedenheit.
• Geschäftsprozesse, die durch Funktionalität begrenzt sind.
• Potenzielle Kosten, Erfahrungen oder Umsatzgewinne.

Replace

Lösungen werden in der Regel mithilfe der besten Technologie und des jeweils verfügbaren Ansatzes implementiert. 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.
• Beschleunigen Sie die Einführung von geschäftsprozessgesteuerten Ansätzen.
• Umverteilung von Entwicklungsinvestitionen für Anwendungen, die Alleinstellungsmerkmale oder Wettbewerbsvorteile generieren.

Quantitative Analysefaktoren sind:

• Allgemeine Betriebskostenreduzierungen.
• VM-Größe, einschließlich CPU, Arbeitsspeicher und Speicher.
• Abhängigkeiten, z. B. Netzwerkdatenverkehr.
• Außer Betrieb zu nehmende Ressourcen.
• Datenbank, die CPU, Arbeitsspeicher, Speicher und Version enthält.

Qualitative Analysefaktoren sind:

• Kostenvorteilanalyse der aktuellen Architektur im Vergleich zu einer SaaS-Lösung.
• Geschäftsprozesskarten
• Datenschemas.
• Benutzerdefinierte oder automatisierte Prozesse.

Nächste Schritte

Sie können diese fünf Rs der Rationalisierung auf einen digitalen Nachlass anwenden, um Rationalisierungsentscheidungen über den zukünftigen Zustand jeder Anwendung zu treffen.

Was ist ein digitaler Nachlass