Unternehmen, die sich bereits auf den Weg in die Cloud gemacht haben, haben sich als widerstandsfähiger und reaktionsfähiger gegenüber dieser Pandemie erwiesen. Es wird erwartet, dass die Cloud-Nutzung in naher Zukunft branchenübergreifend erheblich zunehmen wird, wobei verschiedene Cloud-Service-Modelle (Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS)) mit hybriden und Multi-Cloud-Topologien kombiniert werden. Cloud-Hosting wird ein neuer wesentlicher IT-Dienst für Unternehmen werden.
Es wird erwartet, dass ein gut definierter Ansatz für die Cloud-Transformation Geschäftsziele, Kosteneinsparungen und strategische Vorteile realisiert. In diesem Artikel werden die Elemente eines typischen Ansatzes für die Migration, Modernisierung und Transformation von Anwendungen in die Cloud kurz umrissen. Der Artikel kombiniert Methoden zur Portfolio-Rationalisierung, die potenzielle Einsparungen durch die Reduzierung von Ausgaben für nicht wertvolle Portfolios identifizieren können, mit Methoden zur Cloud-Migration, um die Vorteile der Cloud zu nutzen. Diese Artikelserie stellt den methodischen Ansatz für eine erfolgreiche Cloud-Transformation dar.
Ein typisches Cloud-Transformationsprojekt kann die folgenden vier Phasen umfassen. Je nach dem aktuellen Transformationsstadium einer Organisation müssen die entsprechenden Phasen angewendet werden:
- Strategie- und Portfoliobewertung,
- Entwurf & Planung,
- Migration und Umwandlung,
- Betriebsführung und Optimierung.
Dieser Artikel konzentriert sich mehr auf die ersten beiden Phasen, d.h. Strategie- und Portfoliobewertung sowie Design und Planung. Die folgende Abbildung zeigt einen Cloud-Migrationsansatz, der in diesem Artikel näher erläutert wird.
Bewertung der Strategie und des Portfolios
Ziel dieser Phase ist es, die Bereitschaft des Unternehmens für die Cloud zu bewerten, eine Cloud-Strategie zu definieren, eine Bewertung des Anwendungsportfolios durchzuführen und die Zieldisposition zu definieren.
1.1. Cloud-Strategie
Bevor eine Cloud-Strategie entwickelt wird, ist es wichtig, die aktuellen Geschäftsziele und -prioritäten des Unternehmens, die aktuelle IT-Landschaft, laufende Transformationsinitiativen und Technologiestrategien zu verstehen.
- Definieren Sie Cloud-Ziele, die mit der Unternehmensvision und der Geschäfts- und IT-Strategie übereinstimmen. Definieren Sie, wie die Cloud das Unternehmen in die Lage versetzen wird, seine Geschäftsziele oder neuen Fähigkeiten zu erreichen.
- Definieren Sie die Hauptziele für die Einführung der Cloud. Zum Beispiel digitale Transformation, Ausstieg aus dem Rechenzentrum, Modernisierung von veralteten Technologien, Ersetzen von veralteten Technologien, Einführung neuer Geschäftsdienste, Verbesserung der Agilität, Kapazitätsausweitung, Kostensenkung, Verbesserung der Widerstandsfähigkeit, Reaktionsfähigkeit, Flexibilität oder betrieblichen Effizienz. Definieren von KPIs (Leistungskennzahlen, engl. Key Performance Indicator) mit materiellen und immateriellen Vorteilen für diese Ziele.
- Definieren Sie die Prozessmethode für die Cloud-Migration und -Transformation. Zum Beispiel Pilotprojekt vor der Implementierung, um verschiedene Arbeitslastszenarien zu berücksichtigen, Vorzug der Migration in kurzen Sprints gegenüber dem “Big Bang”-Ansatz.
- Definieren Sie die Cloud-Entscheidungen mit Begründung, Auswirkungen und Vorteilen, wie
- Entscheidung über die Auswahl von Cloud-Service-Anbietern (AWS, Azure oder GCP). Definieren Sie um welche Cloud-Topologie es geht, d.h. ob es sich um eine private, hybride oder Multi-Cloud handelt. Wenn es sich um eine Multi-Cloud-Strategie handelt, definieren Sie die Gründe für die Auswahl der verschiedenen Clouds und welche Art von Arbeitslasten in den verschiedenen Clouds platziert werden können (z.B. Analytics auf AWS und veraltete Server auf Azure oder umgekehrt).
- Entscheidung über Container-Plattform und Containerisierungsstrategie.
- Auswahl des bevorzugten Cloud-Service-Modells für eine Anwendung – z.B. wird SaaS gegenüber PaaS bevorzugt, dann CaaS (Container as a Service) und schließlich IaaS als letzte Option.
- Definieren Sie, welche Cloud-Dienste (IaaS/PaaS) für die Nutzung durch die einzelnen Cloud-Dienstanbieter zugelassen sind. Serverlose Rechenfunktionen (z.B. Lambda/Azure-Funktionen) sind aus verschiedenen Sicherheitsgründen möglicherweise nicht als Unternehmensstrategie zugelassen. Definieren Sie den Genehmigungsprozess für den Fall, dass solche neuen Cloud-Dienste genutzt werden.
- Definieren Sie alle Entscheidungen oder Überlegungen zum Ersatz von Softwarepaketen oder Unternehmensanwendungen durch SaaS– oder COTS-Plattformen.
- Festlegung von Grundsätzen für die Cloud-Einführung – z.B. Durchsetzung von Standardtechnologie-Stacks für Migrationen, Anwendung von DevOps-Grundsätzen, Self-Service- und Cloud-Brokerage-Grundsätzen, Portabilitätsgrundsätze zur Vermeidung einer Anbieterbindung. Zum Beispiel die Durchsetzung von Kubernetes-basierten PaaS-Container-Plattformen zur Unterstützung der Portabilität zwischen Clouds. “Infrastructure as Code”-Prinzip, damit die Bereitstellung in jeder Cloud funktioniert. Wahl von Cloud-agnostischen Datenbanken anstelle von nativen Datenbanken. Portabilitätsoptionen zwischen Clouds (z.B. AWS zu Azure oder Azure zu AWS).
- Für Datenmigrationen wie Data-Warehouses oder Big-Data- und Analytics-Plattformen ist eine detaillierte Datenmigrationsstrategie erforderlich, entweder unter Verwendung von Cloud-Nativen oder neuartigen COTS-Datenplattformen.
- Definition von Plattformen für Multi-Cloud-Integrationen (z.B. mithilfe von iPaaS- und API-Gateway-Platformen).
- Umfassende Zeitpläne für die Cloud-Migration und Transformation.
- Hochrangiger Änderungsmanagementprozess, z.B. neue Rollen, neue Fähigkeiten, Änderungen im Bereitstellungsprozess, zusätzliche Tests, die erforderlich sein können (z.B. Sicherheits-/Penetrationstests) und Schulungsbedarf für neue Cloud-Fähigkeiten.
- Definition von Einschränkungen bei der Cloudeinführung, Risiken und Abhilfemaßnahmen für das Unternehmen – z.B. Einschränkungen in Bezug auf Datensicherheit und Vorschriften sowie Auswirkungen aufgrund laufender strategischer Initiativen. Ausstiegskriterien des IT-Dienstleisters, wie z.B. der Prozess der Übertragung von Cloud-Abonnements/Kontenbesitz. Ausstiegskriterien des Cloud-Dienstleisters.
- Definition von Leitlinien und -planken für Cloudgovernance – d.h. Regeln und Richtlinien für den Prozess der Regulierung und Einhaltung von Vorschriften, Sicherheitsrichtlinien, Genehmigungsverfahren für Cloud-Migrationsprojekte, Betriebsrichtlinien und Kostenmanagement.
- Definieren Sie für die Ausstiegsstrategie aus dem Rechenzentrum einen übergeordneten Prozess für die Abschaltung des Rechenzentrums (DC, engl. Data Center).
Die Cloud-Strategie ist ein sich entwickelndes Dokument. Oftmals bestehen zu Beginn verschiedene Unklarheiten. Diese Strategie wird während der Entwurfs- und Planungsphase weiter verfeinert.
1.2. Bewertung des Anwendungsportfolios
Führen Sie eine unternehmensweite Bewertung des Anwendungsportfolios durch. Dies ist für die Festlegung einer unternehmensweiten Transformationsstrategie erforderlich. Wenn solch eine Aufgabe bereits durchgeführt wurde, können diese Artefakte für die weitere Analyse genutzt werden. Wenn nicht das gesamte Unternehmen für die Cloud bereit ist, dann planen Sie die Bewertung der Anwendungen einer Geschäftseinheit, die für die Cloud-Transformation bereit ist. Es gibt 7R-Strategien für eine Migration. Diese sind:
- den Host wechseln (Rehost),
- die Plattform ändern (Replatform),
- Umstrukturierung (Refactor),
- Änderung der Architektur (Rearchitect),
- Ersetzen (Replace),
- Behalten von Anwendungen, die keine Migration benötigen (Retain) und
- Anwendungen, die nicht mehr benötigt werden (Retire).
Das Ergebnis der Bewertungsphase besteht darin, eine der 7R-Strategien auf die Anwendungen abzubilden.
Die Anwendungen müssen sowohl von oben nach unten als auch von unten nach oben bewertet werden. In dieser Phase werden die erforderlichen Anwendungsdetails durch die Durchführung von Workshops und die Erfassung von Antworten auf Fragebögen von verschiedenen Anwendungsbeteiligten gesammelt. Anwendungs- und Infrastrukturattribute können auch aus der Konfigurationsmanagement-Datenbank (CMDB, engl. Configuration Management Database) oder aus bestehenden Archiven der Unternehmensarchitektur (EA, engl. Enterprise Architecture) gesammelt werden. Es geht also darum, den aktuellen IT-Bestand eines Unternehmens zu kennen. Für Unternehmen mit einem großen IT-Fußabdruck ist es ratsam, automatisierte Anwendungs- und Infrastrukturerkennungswerkzeuge zu nutzen, um die erforderlichen Attribute und Anwendungsdetails zu erhalten.
Die nachstehende Tabelle enthält eine kurze Beschreibung der 7R. Nach der Analyse kann die Anwendung in eine dieser Dispositionskategorien fallen.
7R-Strategien für die Cloud-Migration
Rehost/Neu hosten (Lift & Shift)
- Lift and shift. Im Wesentlichen eine „Forklift“-Anwendung und eine Datenbank in die Cloud verlagern, ohne Code- oder Datenbankänderungen. Es wird erwartet, dass aktuelle Anwendungen auf den neuesten Betriebssystemen oder Softwareversionen gehostet werden, die in der Cloud unterstützt werden.
- Obwohl dieser Prozess oft als “Lift and Shift” bezeichnet wird, erfordert er in vielen Fällen die Neukompilierung eines Software- oder Anwendungscodes auf den Zielplattformen und die Bereitstellung.
- Hauptsächlich in Strategien zur Beschleunigung des Ausstiegs aus Rechenzentren oder zur Konsolidierung von Rechenzentren verwendet.
- Migration von Anwendungen oder COTS/Paketanwendungen im Ist-Zustand in die Cloud.
- Z.B., Windows 2012 zu Windows 2012, Linux RHEL 7 zu Linux RHEL 7, Oracle DB zu AWS RDS, SQL zu Azure SQL
- Meistens wird diese Migration mit benutzerdefinierten Tools, kommerziellen Tools oder Tools von Cloud Computing-Anbietern durchgeführt. Sehr geringe bis keine Änderungen am Code
Replatform/Plattformwechsel
- Verlagerung von Altanwendungen oder COTS-Produkten in die Cloud durch Aufrüstung mit der neuesten Softwareversion oder neuen Betriebssystemversionen.
- Umstellung kommerzieller Anwendungsserver auf Open-Source-Server.
- Heterogene Datenbankmigrationen, z. B. Oracle zu PostgreSQL, Oracle zu Redshift, Netezza zu Azure DWH, …
- Bedeutende Versions-Upgrades wie UNIX/Solaris auf Linux, AIX auf Linux, Windows auf Linux, Windows 2003/Win2008 auf Windows 2016/2019, Mainframe auf x86-Plattformen, …
- Bei der Migration von alten Plattformen auf neue Betriebssysteme kann es zu mäßigen bis größeren Veränderungen kommen.
Refactor/Umstrukturierung
- Refactoring des Codes und einiger Teile einer bestehenden Anwendung, um die Vorteile von Cloud-Nativen Frameworks und Funktionen zu nutzen.
- Modernisierung von Anwendungen mit Cloud-Nativen PaaS-Diensten, z.B. .NET/Java-Webanwendungen auf Azure Apps, AWS Beanstalk, …
- Containerisierung bestehender App-Stacks auf Container-Plattformen wie Docker mit Code-/Konfigurationsänderungen auf Kubernetes oder AWS ECS/Azure EKS.
- Konvertierung der Datenbanken von RDBMS zu NoSQL.
- Konvertierung von veraltetem Code in neuere Sprachen.
- Konvertierung von Big Data vor Ort zu nativen Cloud-Plattformen wie Azure HOP oder AWS EMR/Glue.
- Beinhaltet mäßige bis größere Änderungen am Code. Bestehender Code oder Dienste werden weiter verwendet.
Rearchitect/Umgestalten (auch bekannt als Rewrite, Remediate)
- Modernisierung und Neucodierung aller Teile einer bestehenden veralteten Anwendung, um die Vorteile von Cloud-Nativen Frameworks und Funktionen zu nutzen.
- Erhebliche Änderungen der logischen physischen Anwendungsarchitekturen oder der Technologie. Z.B. Umschreiben von Anwendungen in Microservices, alte ETL-Jobs auf AWS Lambda/Glue oder Azure Data Factory.
- Modernisierung von Altbeständen durch komplett neue Dienste mit PaaS-Container-Plattformen wie Kubernetes/OpenShift/PCF (PaaS).
- Rationalisierung der lizenzierten Anwendung mit Open-Source-Software. Erfordert größere Codeänderungen. Die Wiederverwendung von bestehendem Code wird sehr begrenzt sein.
Replace/Ersetzen (Drop and Shop)
- Neukauf einer Software für die Anwendung. Die Anwendung muss auf ein anderes Produkt oder einen anderen Dienst migriert werden, oft auf eine SaaS-Plattform.
- Migration von Geschäftsprozessen, für die SaaS-Angebote zur Verfügung stehen, und Stilllegung bestehender.
- Umstellung von Backend-Prozessen wie CRM, Teamzusammenarbeit, Gehaltsabrechnung, HR-Funktionen, Betrieb, Marketing, … auf Salesforce, Workday, Oracle, SuccessFactors, Microsoft 365, ADP, …
- Erfordert in der Regel mäßigen bis hohen Aufwand. Die Wiederverwendung von existierendem Code ist sehr limitiert.
Retain/Behalten
Veraltete Anwendungen und Technologien, die nicht in die Cloud migriert werden können. Anwendungen mit hohen Datenrisiken, Sicherheits- und Compliance-Anforderungen. Eng gekoppelte Systeme mit veralteten Betriebssystemen und -Hardwareplattformen (z. B. Mainframe, COBOL, BSS-Anwendungen), die nicht umgestaltet werden können oder für die in der Cloud keine Unterstützung verfügbar ist.
Retire/Stilllegen
Veraltete Anwendungen und Technologien, die nicht in die Cloud migriert werden können. Anwendungen mit hohen Datenrisiken, Sicherheits- und Compliance-Anforderungen. Eng gekoppelte Systeme mit veralteten Betriebssystemen und -Hardwareplattformen (z. B. Mainframe, COBOL, BSS-Anwendungen), die nicht umgestaltet werden können oder für die in der Cloud keine Unterstützung verfügbar ist. Geplante Stilllegung für End-of-Life-Anwendungen. Ausmusterung nicht nützlicher Anwendungen.
Identifizieren Sie den Lebenszyklus-Status einer Anwendung. Filtern Sie die Anwendungen und Infrastrukturen aus der Bewertungsliste heraus, die in naher Zukunft stillgelegt werden sollen oder die bereits aus der weiteren Bewertung herausgenommen wurden.
1.2.1. Sammeln von Daten
Erfassen der Attribute für die folgenden Kategorien für jede Anwendung.
Anwendungsattribute: Erstellen Sie ein Inventar mit grundlegenden Anwendungsattributen wie Funktionalität, Status des Anwendungslebenszyklus, Geschäftsfähigkeit, unterstützende Geschäftseinheit, gehosteter Standort/Geografie, Art der Anwendung (Web, Batch, Middleware, Transaktion, Analyse, …), geplante Upgrades oder in naher Zukunft erwartete Änderungen.
Attribute des Unternehmenswerts: Wie wichtig ist diese Anwendung für das Unternehmen in Bezug auf die Generierung von Einnahmen, die Bereitstellung von Analyseberichten oder die Unterstützung von Abläufen. Erfassen Sie Faktoren wie Ausrichtung an der Geschäftsstrategie, aktueller Nutzen, Geschäftskritik, redundante/duplizierte Funktionen dieser Anwendung, die in anderen Anwendungen vorhanden sind, Anzahl der Benutzer, Zeitaufwand für die Freigabe neuer Funktionen (Agilität), Differenzierungsfaktor für das Unternehmen, Benutzerzufriedenheit, Automatisierungsgrad in dieser Anwendung.
Gesamtbetriebskosten – z.B. Kosten für die Wartung einer Anwendung, Infrastrukturkosten, Lizenzierungskosten.
Technische Wertmerkmale: Ausrichtung der Anwendung an der Technologiestrategie, technische Schuld und Leistung der Anwendung, einfache Unterstützbarkeit, einfache Integration, Erfüllung moderner Technologiestandards, aktueller Stand bei der Erfüllung von nichtfunktionalen Anforderungen (NFRs, engl. Non-Function Requirements) wie Modularität, Erweiterbarkeit, Skalierbarkeit, Portabilität, Zugänglichkeit, Wartbarkeit, Reaktionszeit, Wiederherstellbarkeit, Verfügbarkeit, Leistung, Entwicklungs- und Bereitstellungsmethoden, Qualität und Genauigkeit der erzeugten Daten.
Attribute Risiko und Einhaltung von Vorschriften: Datenschutz-, Sicherheits- und Regulierungsanforderungen, wie Datenvertraulichkeitsstufen, Datenverschlüsselungsanforderungen, Anwendungssicherheitsanforderungen, organisatorische Beschränkungen, lokale/regionale Regulierungsanforderungen wie
- Health Insurance Portability and Accountability Act (HIPAA),
- Datenschutz
- General Data Protection Regulation (EU) (GDPR)/Datenschutz-Grundverordnung (DSGVO oder DS-GVO),
- Bundesdatenschutzgesetz neu (BDSG neu),
- BSI-KritisV,
- Payment Card Industry Data Security Standard (PCI-DSS), ….
Cloud-Eignung (Bereitschaft): Prüfen Sie die technische Machbarkeit der Verlagerung dieser Anwendung in die Cloud. Faktoren wie z. B., ob die Anwendung hardwareabhängig ist oder Betriebssysteme (OS, engl. Operating System) hat, die in der Cloud nicht unterstützt werden. Wenn es sich um eine COTS-Paketanwendung handelt, prüfen Sie, ob sie in der Cloud unterstützt wird. Verwendet die Anwendung veraltete Technologien wie COBOL, C, C++, … oder verwendet sie moderne Technologien. Prüfen Sie, ob die Datenbank in der Cloud unterstützt wird. Gehosteter Standort, d.h. ob die Anwendung firmenintern oder in einem Rechenzentrum eines Dritten gehostet wird.
Komplexität: Komplexität, die sich auf die Migration in die Cloud auswirken kann. Faktoren wie Verteilung der Anwendung, Konfigurationen, Anzahl der Hosts, Datenbankgröße, Schnittstellentechnologie, Anzahl der Schnittstellen (sowohl eingehend als auch ausgehend), Topologie-/Clustering-Anforderungen, Lastausgleichsanforderungen, Code-Komplexität, einfache Erstellung/Tests/Installation, Verwendung von Legacy-Technologien.
Viele IT-Firmen und Cloud-Service-Provider (AWS/Azure/GCP) bieten kostenlose Tools für die automatische Anwendungserkennung und -bewertung an, doch sind manuelle Eingriffe und Befragungen nach wie vor erforderlich, um bestimmte Attribute für die Festlegung der richtigen Dispositionsstrategie zu erfassen.
1.2.2. Analyse
Es ist wichtig, die Cloud-Strategie des Unternehmens zu kennen, die einen Einfluss auf die Disposition haben kann. Wenn ein Unternehmen kurzfristig eine Strategie zur Konsolidierung des Rechenzentrums oder zum Ausstieg aus dem Rechenzentrum verfolgt, könnten “Rehost” und “Replatform” die erste Option für die vorhandenen Anwendungen sein. Dies gilt auch für Unternehmen, die eine schnellere Migration zu einigen ihrer Arbeitslasten benötigen und die Anwendungen in späteren Phasen modernisieren. Es könnte ein EOL (End Of Life Support) für das zugrunde liegende Betriebssystem oder die Software geben, auf der kritische Geschäftsanwendungen laufen. Solche Anwendungen können Kandidaten für die Migration auf neue Software- oder Betriebssystemversionen in der Cloud sein, für die der Hersteller Support anbietet. Einige Unternehmen nutzen die Cloud-Transformation als Gelegenheit zur Rationalisierung und Modernisierung ihrer bestehenden IT. Einige Unternehmen möchten ihre Anwendungen durch Umstellung auf unterstützte Container-Technologien (z. B. Kubernetes/Docker) “containerfähig” machen. Andere nutzen die Gelegenheit, kommerzielle Anwendungen/Datenbanken in kostengünstigere Open-Source-Anwendungen umzuwandeln, um Kosten zu sparen. Einige sehen die Cloud als eine Erweiterung für zusätzliche Kapazitätsanforderungen. Einige Unternehmen nutzen die Cloud für den Aufbau neuer Funktionen wie Data Lake, Analytik und maschinellem Lernen. Die Cloud kann auch für Experimente genutzt werden (z.B. Pilotierung/POC). Hier ist der schnelle Entscheidungsbaum basierend auf der Cloud-Strategie.
Cloud-Migrationsstrategie
Wie Sie in der obigen Abbildung sehen, sind Rehost-/Replatform-Strategien mit geringen Risiken und weniger Migrationsaufwand verbunden, bieten aber auch weniger Vorteile. Die Sanierung bzw. Modernisierung von Anwendungen kann mit einem höheren Migrationsaufwand verbunden sein, bringt aber langfristig mehr Vorteile mit sich. Es ist wichtig, das Verhältnis zwischen Migrationsrisiko und -nutzen für jede Anwendung zu bewerten. Einige veraltete Anwendungen können aufgrund technologischer Beschränkungen nicht neu gehostet oder replatformed werden. Solche Anwendungen müssen auf neue Plattformen umgestellt werden (Rearchitecture). Es ist vorteilhaft, “geringwertige” Anwendungen auf kostengünstiger Hardware neu zu hosten, anstatt eine kostspielige Umstrukturierung vorzunehmen.
Nutzen Sie die Daten aus den Fragebögen und anderen oben genannten Attributen, um die Anwendungen auf 7R-Dispositionen zu analysieren. Geben Sie eine Gewichtung und Bewertung der Attribute in jeder Kategorie an. Die Gewichtung kann auf der Grundlage der Geschäftsstrategie des Unternehmens festgelegt werden, z.B. kann die Produkteinführungszeit für das Unternehmen wichtiger sein als die Benutzerfreundlichkeit. Technische Verschuldung kann mehr Gewicht haben als hohe Verfügbarkeit.
Geschäftsfähigkeitslandkarte (BCM, engl. Business Capability Map): Definieren Sie für jede Anwendung die Zuordnung zu den Geschäftsfähigkeiten. Identifizieren Sie Rationalisierungsmöglichkeiten wie die Reduzierung von COTS-Lizenzen, redundante Anwendungen, die zusammengeführt oder ersetzt werden können, Anwendungen oder Datenspeicher, deren Betrieb zu teuer ist.
Erstellen Sie auf der Grundlage der Bewertung von Geschäftswerten, technischem Wert und Cloud-Eignung verschiedene Analysemodelle wie das TIME-Modell, Vorteile gegenüber einfacher Migration, technischer Wert gegenüber Geschäftswert. Diese Analyse hilft bei der Identifizierung potenzieller “Quick Wins”, d.h. Anwendungen, die mit geringem Risiko schneller migriert werden können, aber auch kurzfristig Kostenvorteile und einen geschäftlichen Nutzen bieten. Beispielhafte Analysevorlagen finden Sie unten.
1.3. Disposition und Empfehlungen
Erstellen Sie einen Entscheidungsbaum und wenden Sie die Werte aus den obigen Diagrammen an, um die Ziel-Cloud-Disposition zu ermitteln. Zum Beispiel kann eine Anwendung mit geringem Geschäftswert, aber hohem Cloud Readiness Score einfach “Rehost” sein, anstatt Aufwand für “Rearchitecture” zu betreiben. Anwendungen ohne Geschäftswert und mit geringem technischem Wert können in Betracht gezogen werden, um sie stillzulegen oder auf einer kostengünstigen Infrastruktur neu zu hosten. Anwendungen mit sehr hohem geschäftlichem Nutzen, aber geringem technischen Wert (d.h. hohe technische Schulden) können für die Optionen Replace, Refactor oder Rearchitecture in Betracht gezogen werden. Anwendungen, die sowohl einen hohen geschäftlichen als auch einen hohen technischen Wert haben, können je nach langfristigem Nutzen entweder für Rearchitect oder Rehost-Szenarien in Betracht gezogen werden. Einige IT-Dienstleister haben Analysetools entwickelt, die standardisierte Scoring-Werte und Regelsätze zur Beschleunigung des Analyseprozesses enthalten. Ein Beispiel für einen Entscheidungsbaum ist unten dargestellt.
In diesem Stadium kann es sinnvoll sein, eine Zusammenfassung der Empfehlungen für die Anwendungen auf hoher Ebene zu erstellen. Definieren Sie die kurz- und langfristigen Empfehlungen für jede Anwendung. Die kurzfristige Strategie kann z.B. “Rehosting” sein und die langfristige Strategie kann eine Neuarchitektur mit serverlosen Berechnungen sein.
1.4. Geschäftsfall
Sobald die übergeordnete Bewertung erfolgt ist, führen Sie eine übergeordnete Kosten-Nutzen-Analyse für Anwendungen durch. Bestimmen Sie auf der Grundlage der Betriebskosten für die Infrastruktur vor Ort, der Abschreibung und der Betriebskosten für die Infrastruktur die aktuellen Gesamtbetriebskosten der Anwendung. Ermitteln Sie die erwarteten Ausgaben für die nächsten drei bis vier Jahre. Erstellen Sie auf der Grundlage der Disposition der Anwendung und der Datenbank ein Inventar der Zielinfrastruktur mit geeigneter Instanzgröße, Instanztypen, Speicher, Netzkomponenten, PaaS und DbaaS-Services. Bestimmen Sie die Betriebskosten der Anwendung in der Ziel-Cloud für die nächsten drei bis vier Jahre. Bestimmen Sie die geschätzten Migrationskosten. Ermitteln Sie die Einsparungen bei den derzeitigen Betriebskosten der Infrastruktur, wenn diese in die Cloud verlagert wird. Nutzen Sie verschiedene Rabatte von Cloud-Anbietern und Vorteile langfristiger Preispläne, um die Zielkosten zu ermitteln. Cloud-Investitionen amortisieren sich in der Regel innerhalb von zwei bis drei Jahren. Vergleichen Sie die Kosten für das Hosting in verschiedenen Clouds. Die Online-TCO-Rechner der Cloud-Anbieter bzw. die Rechner für monatliche Ausgaben können zur Ermittlung der Kosten herangezogen werden. Berücksichtigen Sie die zusätzlichen immateriellen Vorteile wie Agilität, Elastizität, Flexibilität und Skalierbarkeit als Teil des gesamten Business Case.
Das Durchspielen des Geschäftsszenarios liefert den Geschäftsinhabern und CxOs eine Entscheidungsgrundlage für die Initiierung von Cloud-Projekten. Es ist auch wichtig, eine Cloud-Optimierungsübung einzubeziehen, sobald die Anwendung und die Daten in die Cloud migriert worden sind.
1.5. Cloud Business Office
Für eine erfolgreiche Cloud-Einführung und -Wertrealisierung ist es wichtig, eine effektive strategische Aufsicht und Governance in einer Organisation zu haben. Das Cloud Business Office (CBO) besteht aus Führungskräften auf C-Ebene (Sponsoren), wichtigen Geschäftsinteressenten, Anwendungs-Eigentümern, Infrastrukturleitern, Sicherheitsleitern, technischen Leitern, Betriebsleitern, dem Beschaffungsteam, Risk & Compliance und Unternehmensarchitekten, die die Cloud-Transformation vorantreiben, beschleunigen und ermöglichen. Die Anliegen des CBOs sind die Definintion von Umwandlungszielen, das Nahebringen der Cloud-Strategie im Unternehmen, Bereitstellung des Etats, Entwicklung von Standards, Änderungsmanagement, Starten und Steuern von Cloudmigrationsprojekten, die Werteverwirklichung durch Messungen von Metriken und Vorteilen zu überwachen.
Jede der Rollen hat entweder langfristige oder kurzfristige Verantwortlichkeiten für die Unterstützung der CBO-Ziele und Entscheidungen rund um die Cloud-Einführung. Eine solche Funktion oder Einheit kann auch als Cloud Strategy Office (CSO) oder Cloud Center of Excellence (COE) bezeichnet werden.
Umfang des Cloud Business Office
| Definition von Zielen & Geschäftszielen für die Einführung von Cloud Computing |
| Vorantreiben der Cloud Computing Strategie |
| Sponsoring, Bereitstellung von Budgets |
| Cloud Computing-Projekte ins Leben rufen |
| Verfolgen und Steuern von Cloud Computing-Projekten |
| Werterealisierung der Cloud |
| Organisation und Management von Herausforderungen |
| Architektur, Tools und Standards |
| Kostenoptimierung des Cloud Computing |
Entwurf und Planung
In dieser Phase wird eine detaillierte Bewertung der Anwendung vorgenommen und eine möglichst praktikable Architektur zur Umsetzung der Migrationsstrategie definiert. Es ist auch möglich, die Cloud-Strategie in dieser Phase zu verfeinern.
Detaillierte Bewertung: Analyse des Anwendungscodes bzw. der Software, der/die für das Refactoring vorgesehen ist, mithilfe von Code-Scannern. Es gibt viele kommerzielle Tools zum Scannen von Code für Refactoring. Azure und AWS Cloud bieten ebenfalls Code-Scan-Tools an, z. B. .NET Portability Analyzer/Porting Assistant for .NET usw. Es gibt auch Tools wie AWS App2Container, die sogar Anwendungen containerisieren und auf Container-Plattformen bereitstellen können. Analysieren Sie die Funktionalitäten und den Code für Rehosting, Replatforming und Rearchitecting von Anwendungen. Identifizieren Sie alle Risiken und Hindernisse. Diese Übung liefert die Details, die erforderlich sind, um den Aufwand für die Cloud-Migration zu schätzen.
Transformationsfahrplan: Definieren Sie den Migrationsplan auf der Grundlage der durchgeführten Bemühungen und Bewertungen. Gruppieren Sie die Anwendungen mit gemeinsamen Abhängigkeiten und Datenbanken. Definieren Sie für jede dieser Gruppen eine Migration. Die Gruppierung kann auch nach Organisationsfunktionen/Domänen oder technischen Fähigkeiten erfolgen (z.B. Webanwendungen, Middleware, Kerntransaktionssysteme, Big Data, …). Priorisierung der Anwendungen nach Komplexität. Planen Sie die Migration von Anwendungen mit geringem Risiko (“Quick Wins”) und geringer Komplexität für den Anfang. So können beispielsweise einfache Webanwendungen oder Berichtsanwendungen als Vorreiter betrachtet werden. Identifizieren Sie die agilen Prozessmethoden und Teamstrukturen. Bestimmen Sie die Anzahl der Migrations-User-Stories und Sprints, indem Sie die Migrationsbemühungen richtig dimensionieren. Definieren Sie die Struktur des Migrationsteams und bestimmen Sie die richtige Größe des Teams, indem Sie es in Stämme und Gruppen aufteilen. In manchen Unternehmen werden diese Strukturen auch als PODs bezeichnet. Definieren Sie die Lebenszyklusphasen für Migration, Tests und Cut-Over-Pläne für Anwendungen. Erfolgreiche Migrationen schaffen Vorlagen für die Übertragung der übrigen Anwendungen. Die Modernisierung von Anwendungen (Rearchitektur oder Refactoring) kann mehr Zeit und eine langfristige Strategie erfordern. Anwendung von Dev(Sec)Ops und agilen Methoden (z. B. Scrum, SAFe) für Migrationen.
Zielarchitektur: Definieren Sie die Zielarchitektur für die Anwendungen, Daten und Netzkomponenten. Da die Migrationen auf agile Art und Weise geplant werden, ist es wichtig, eine Architektur (Minimum Viable Architecture) zu definieren, die einfach, aber ausreichend ist, um die Migration umzusetzen. Definieren Sie die Zieltechnologien, Software- sowie Betriebssystemversionen und Datenbankversionen, die während der Migration in bestehende Anwendungen und Datenbanken umgewandelt werden sollen. Berücksichtigen Sie Datenbankabhängigkeiten, Schnittstellen, externe Integrationen und Datenmigrationsanforderungen für die Anwendungen. In Fällen, in denen Daten und abhängige Anwendungen vor Ort verbleiben, sollten Sie eine hybride Cloud-Architektur in Betracht ziehen. Diese Architektur wird sich während der Migrationsphasen ständig weiterentwickeln. Treffen Sie architektonische Entscheidungen und holen Sie sich die Unterstützung der Beteiligten für diese Entscheidungen. Entwerfen Sie eine Architektur mit hoher Verfügbarkeit, Lastausgleich und Leistung nach dem Prinzip “fit for purpose”. Schließlich ist die Cloud auf Skalierbarkeit und Verfügbarkeit ausgelegt, weshalb ein Over-Engineering zu vermeiden ist. Ein Beispiel für eine hybride Cloud-Architektur ist unten dargestellt.
Dev(Sec)Ops: Dev(Sec)Ops ist in jeder Branche zum De-facto-Standard für Transformations- und Modernisierungsprojekte geworden. Jedes Migrations-POD-Team sollte dem DevOps-Prozess folgen. Für einige Anwendungen (z. B. COTS) ist DevOps möglicherweise nicht relevant oder kann nicht angewendet werden. Solche Anwendungen sollten in den architektonischen Entscheidungen genannt werden. Solche Anwendungen können den bestehenden Methoden zur Erstellung und Bereitstellung in der Ziel-Cloud folgen. Definieren Sie die Tools, die zum Erstellen, Testen, Bereitstellen und Überwachen von Anwendungen in der Ziel-Cloud verwendet werden sollen. Es sind viele cloudnative Optionen verfügbar. Entwerfen Sie die DevOps-Pipeline (z.B. mit Jenkins, AWS Code Pipeline, Azure DevOps, GitHub Actions …). Berücksichtigen Sie Code-Schwachstellen-Scans und Sicherheitstests vor der Bereitstellung. Planen Sie, die Schritte zu automatisieren, wo immer dies möglich ist (z.B. Tests). Definieren Sie, wie der Quellcode verwaltet und versioniert wird (z.B. in Github-Repositories mit Branches). Definieren Sie, wie User Stories erfasst und nachverfolgt werden (z.B. mit Tools wie Jira). Definieren Sie die verschiedenen Umgebungen, in denen die bestehende Anwendung eingesetzt und getestet werden soll, bevor sie in Produktion geht. Der Migrationsprozess muss kontinuierlich (CI/CD) und iterativ für jede Anwendung erfolgen, bis die erforderlichen Test-KPIs erreicht sind. Definieren Sie den Prozess der Anwendungsunterstützung und wie die Probleme nach der Produktion überwacht werden sollen. Von DevOps-Teams wird erwartet, dass sie die Anwendung von Codeänderungen über die Bereitstellung bis hin zum Betrieb betreuen.
Proof of Concept (POC): Führen Sie einen Proof of Concept in der Cloud durch. Ganz gleich, ob es sich um die Migration einer Anwendung oder eines Data Warehouse handelt, die Durchführung der Migration in einer Cloud-Umgebung schafft Vertrauen, neue Erkenntnisse und hilft bei der Bewältigung von Herausforderungen. POC hilft bei der Identifizierung von Problemen und Lücken auf der Grundlage des aktuellen organisatorischen Prozesses, der Konnektivität und der Abhängigkeiten von der Umgebung. Wenden Sie DevOps Prozesse und Werkzeuge bei der Migration an. Nehmen Sie mittelkomplexe Rehosting- und Refactoring-Anwendungsfälle als POC auf, mit denen die meisten Anwendungsfälle abgedeckt werden. Die POC helfen bei der Verfeinerung der Zielanwendung und der Infrastrukturarchitekturen.
Entwurf von Cloud-Infrastruktur und Sicherheit: Dies ist ein sehr wichtiger Teil der Entwurfsphase. Hier geht es um die Definition der technischen Landezone der Zielarchitektur. Ein Beispiel für eine AWS-Landezone sind Netzkomponenten wie die Anzahl der VPCs, Konnektivität vom Rechenzentrum, Kommunikation zwischen VPCs, Subnetze, Route 53, ELB, API-Gateway usw. Rechen- und Speicherkomponenten wie EC2, EKS, ECS, RDS, SQS, S3 usw. Sicherheitskomponenten wie IAM-Gruppen, Benutzergruppen, IAM-Richtlinien, AD SSO für bestehende Unternehmensbenutzer, Sicherheitsgruppen und Portkontrollen auf Netzebene. Definieren Sie Kennzeichnungsregeln für Komponenten. Zugriffskontrollmechanismen für Umgebungen einschließlich Datenbank. Definieren Sie die Infrastruktur nach dem “Infrastructure as Code” Prinzip. Nutzung neuer Tools wie cloudnative Infrastrukturerstellungsdienste oder cloudunabhängige Open-Source-Tools wie Terraform. Entwerfen Sie die Integration mit DevOps-Tools, um die Infrastruktur einfach zu erstellen und zu löschen. Dieser Entwurf sollte folgende Bereiche mindestens abdecken:
- Komponenten und Dienste der Cloud Computing Infrastruktur
- Integrationsebenen
- Big Data- und Analysekomponenten (falls zutreffend)
- Netzkonnektivität
- Topologie der hybriden Cloud-Netzkonnektivität (Definition der Konnektivität zu Rechenzentren und externen Clouds je nach Standort/Region)
- Hochverfügbarkeitsdesign – Disaster-Recovery-Ansatz.
Eine Sicherheitsarchitektur sollte Folgendes umfassen:
- Zugriffs- und Identitätsmanagement (z.B. AD-Integration, AWS-Konto und -Organisationen)
- Sicherheitskontrollen und Verfahren für den Zugriff auf Umgebungen/Anwendungen und Datenbanken
- Sicherheitsprüfung und -überwachung (z. B. SIEM-Integration)
- Datensicherheit und -verschlüsselung
- Bewertung von Schwachstellen/Patch-Management-Verfahren
Cloud-Betriebsmodell: Beim Cloud-Betriebsmodell geht es darum, wie das Unternehmen seine Cloud-Transformation umsetzen wird. Es besteht aus mindestens
- Personen (People),
- Privacy (Datenschutz),
- Prozessen (Processes),
- Produkten (Products),
- Partnern (Partners) und
- Policies (Regularien).
Personen sind entscheidend für den Erfolg von Cloud-Programmen. Identifizieren Sie Beteiligten, Teamstrukturen und Rollen, die auf Cloud Business Office, Business/Domains, Operations, Security und DevOps ausgerichtet sind. Identifizierung von Anwendungs- und Daten-Governance-Prozessen und -Richtlinien. Identifizieren Sie die Compliance-Anforderungen und die Art und Weise, wie sie zu erfüllen sind. Es kann eine Strategie geben, die entweder zentralisierte, dezentralisierte oder gemeinsame Betriebsmodelle vorsieht. Das dezentralisierte Betriebsmodell ist das bevorzugte Modell, da es mehr Flexibilität und Kostenmanagement bietet. Allerdings kann ein solches Modell auch Einschränkungen mit sich bringen. Weitere Einzelheiten finden Sie in der Azure-Dokumentation zum Vergleich der Betriebsmodelle.
Änderungsmanagement: Die Cloud-Transformation erfordert die Anpassung an Änderungen der Prozesstechnologie und der Tools. Es wird Änderungen bei der Governance und den Infrastrukturkontrollen geben. Kümmern Sie sich um die neuen Änderungen, die in den verschiedenen Rollen erforderlich sind, die die bestehenden Teams möglicherweise übernehmen müssen. Planen Sie die Umschulung und Cloud-Schulung der Mitarbeiter. Erstellen Sie einen Plan für die Behebung von Lücken in den neuen erforderlichen Fähigkeiten. Die Cloud-Migration ist hauptsächlich eine technische Veränderung. In vielen Unternehmen ist ein Change Advisory Board (CAB) für die Überprüfung und Genehmigung solcher Änderungen zuständig. Die herkömmliche CAB-Genehmigung kann ein Hindernis für die Migration darstellen, wenn nicht rechtzeitig mit den Beteiligten zusammengearbeitet wurde. Es wäre lohnend, ein unternehmensweites Änderungsmanagement-Tool (z.B. ServiceNow, BMC Jira Service Desk, Freshservice, …) zur Steuerung und Kontrolle des gesamten Cloud-Migrationsprozesses in Betracht zu ziehen. Es gibt Tools für die vollständige Zugriffskontrolle auf die Umgebungen, die Bereitstellung, die Abrechnung/Kostenkontrolle, die Sicherheitsüberwachung, das Incident-Management, das Release-Management und das Change-Management sowie den Genehmigungsprozess. Alternativ können Sie auch native Cloud-Dienste (wie AWS config, CloudTrail, Service-Katalog, AWS-Konsole, AWS-Organisationen, Trusted Advisor, …) zusammen mit Unternehmenstools benutzen, um diese Aufgaben zu erfüllen.
Nächste Schritte
Der nächste Schritte sind Migrationen und Transformation. Einsatz von POD-Teams, Migration von Anwendungen und Daten, wie in den vorangegangenen Phasen konzipiert und geplant. In der Phase Verwalten und Optimieren geht es um die Verwaltung (“RUN”) von Infrastruktur, Anwendungen und Daten nach der Migration in die Cloud. Der detaillierte Implementierungsprozess, die Überwachung und der Cloud-Betrieb werden im nächsten Artikel behandelt.
Referenz
Pierre Gronau ist seit über 25 Jahren für namhafte Unternehmen als Senior IT-Berater mit umfangreicher Projekterfahrung tätig. Zu seinen Kompetenzfeldern gehören Server-Virtualisierungen, IT-Sicherheit, IT-Compliance, moderne Cloud- und Automationslösungen sowie Informationsschutz.
