CloudLand 2023, Juni 2023, Andreas Zitzelsberger Die Cloud lockt mit großen Versprechen, die sich auch einlösen lassen. Der Weg dorthin aber ist anspruchsvoll und voller Risiken. Migrationen bleiben im Prototyp-Stadium stecken, ungeeignete Software in der Cloud verfehlt die Ziele, dem Migrationsprojekt wird unterwegs der Geldhahn zugedreht, erhoffte Einsparungen stellen sich nicht ein. In diesem Vortrag stellen wir eine adaptive Strategie vor, die die Herausforderungen und Risiken bei Modernisierungs- und Migrationsprojekten direkt adressiert. Die Strategie haben wir in einem großen Migrations-Programm mit hunderten Anwendungen erfolgreich gelebt, sie lässt sich aber genauso gut für kleine Größenordnungen und für andere Arten von Modernisierungsvorhaben verwenden. Wir gehen gemeinsam das Leben eines Cloud-Modernisierungs-Projektes durch, von der Inception bis hin zum Post-Modernisierungs-Nachbrenner.

1. qaware.de
Cloud Migration -
Eine Strategie, die funktioniert
Andreas Zitzelsberger

2. Warum überhaupt Cloud?

3. Darum: Cloud-native Technologie ermöglicht Agilität
Agile Development Agile Infrastructure
Digitalization
Cloud Native
Platforms

4. Die Kernprobleme sind immer ähnlich …
Qualität
Transparenz

5. … die Risiken auch
Stuck-in-PoC
Qualitätsfalle
Geld
geht aus

6. Die adaptive Strategie
1. Transparenz schaffen mit
sorgfältiger Analyse
2. Für Alignment in der
Organisation sorgen
3. Architektur und Blueprint
4. Acceleration als
Modernisierungs-Ansatz
5. Die Modernisierung einer
Anwendung
6. Der Nachbrenner

7. 1. Transparenz schaffen
mit sorgfältiger Analyse

8. Was müssen wir wissen?
QAware | 8

9. Qualitätsschulden sind im Brownfield weit verbreitet
W. Cunningham, “The WyCash portfolio management system,” in Addendum to OPSLA ’92, Vancouver, Canada, 1992, pp. 29–30. doi: 10.1145/157709.157715.
M. Fowler, Technical Debt, 2003 / 2019 https://martinfowler.com/bliki/TechnicalDebt.html
“A little debt speeds development so long as it is paid back promptly
with a rewrite. … The danger occurs when the debt is not repaid”
Ward Cunningham, 1992
"... deficiencies in internal quality that make it harder than it would
ideally be to modify and extend the system further.“
Martin Fowler 2003/2019
"Technische Schulden verursachen besonders bei Änderungen
Probleme, z.B. im Rahmen einer Modernisierung.“
Andreas Zitzelsberger, hier und jetzt

10. Fachliche Schulden sind besonders schmerzhaft
domain
UX
documentation
requirements
architecture
design
code
Implementierung
Tool-Support Auswirkung
(requirements)
(architecture)
design
code

11. Ehrlich machen: Wie schlimm ist es denn wirklich?

12. Die wichtigsten Fragestellungen:
Welche Anwendungen sind im Portfolio?
Wie kompliziert sind die Anwendungen?
Wie sind die Beziehungen und welche
Abhängigkeiten gibt es?
Welche Technologien werden eingesetzt?
Wer sind die Stakeholder?
→ Wie hängt alles zusammen?

13. Eine Single Source of Truth schafft Transparenz
EAM Tooling
Additional Data
Static Analysis
Source Code
Binaries
Deployments
Excel Sheets
LeanIX
Whatever Else
Custom
Loaders
Single Source
of Truth
Business
Intelligence
Architects
Workbench

14. Pilot-Modernisierungen erden das Wissen
Ziele:
■ Erfahrungen sammeln
■ Kennzahlen erfassen
■ Probleme frühzeitig finden und beheben
■ Vertrauen in das Migrationsvorgehen erzeugen
Zu beachten:
■ Kleine Auswahl repräsentativer Anwendungen
■ Abkürzungen und Vereinfachungen erlaubt
■ Wichtig: Saubere Aufzeichnung

15. 2. Für Alignment
in der Organisation sorgen

16. Alignment gelingt nur mit greifbaren Zielen
Quelle: Cloud Migration Studie 2021 von IDG und QAware
Unsere Ziele:
1. Sicherheit und Stabilität
2. Dauer der Migration
3. Künftige Betriebskosten
4. Enabling der Organisation
5. Migrationskosten
Inspect
Adapt
Align
Communicate

17. Metriken machen den Erfolg greifbar
Mehr Metriken: Data-Driven DevOps: Use Metrics to Guide Your Journey, Ian Head, George Spafford, 2017 Gartner Research ID G00327470
https://www.gartner.com/en/documents/3760663/data-driven-devops-use-metrics-to-guide-your-journey
Zeit von
Commit eines
Changes bis
Freigabe für
Produktion
Lead Time
For
Change
Anteil fehl-
geschlagener
Changes
Change
Failure
Rate
Häufigkeit
von
Produktions-
Deployments
Deploy-
ment
Frequency
Lösungszeit
für Fehler in
Produktion
Mean
Time to
Recovery
Anteil der
Qualitätspro-
bleme, die in
Produktion
sichtbar
werden
Defect
Escape
Rate
Zeit von
Anforderung
bis Umset-
zung inklusive
Prozess
Mean
Turn-
Around
Time
Zeit zwischen
Commit und
Deployment
in Produktion
Cycle
time

18. Eine saubere Planung ist die Basis von allem
Plan
■ Vertrauen in den Erfolg
■ Basis für Alignment
■ Basis für Agilität und
Adaptivität
Ziele
Constraints
Schätzung
durch
Entwickler
Mengengerüste
Kennzahlen
Kontextwissen

19. 3. Architektur und Blueprint

20. Ein Blueprint beantwortet die wesentlichen Fragen
1. Aufgabenstellung
2. Ausgangssituation
3. Migrationsstrategie
4. Zielbild
5. Entwicklungsrichtlinien
6. Lösungsbausteine
7. Lösungsstrategien

21. 4. Acceleration als
Modernisierungs-Ansatz

22. Treiber 1 für Acceleration: Kognitive Last als Bottleneck für
DevOps-Teams reduzieren
■ Intrinsic Cognitive Load
Grundlegende Komplexität und Wissen im
Problemraum → Müssen wir lernen
■ Extraneous Cognitive Load
Alles, was nicht zum eigentlichen Erkenntnisgewinn
beiträgt. Lenkt ab, verhindert Informations-
verarbeitung. → Reduzieren
■ Germane Cognitive Load
Verarbeitung der neuen Informationen, neue
Erkenntnisse ("value added" thinking)
→ Stiftet Wert
https://teamtopologies.com

23. Treiber 2: Die Spannung zwischen Weiterentwicklung und
Modernisierung verringern.
Foto von Henley Design Studio auf Unsplash
PO
Features

24. Ein zentrales Team beschleunigt, reduziert kognitive
Last und ermöglicht Skalierung
ARCHITECTURE
PARALLELE MODERNISIERUNGS-TEAMS
‣ Training Sessions
‣ Support Sessions
‣ Co-Location & remote
‣ Facilitiation: Cookbook, Code
Fests, Beispiel-Anwendungen, …
‣ Werkzeuge: Einheitliche
Entwicklungsumgebung,
Modernization Toolbox
‣ Lösungen: Framework-
Modernisierung, Base Images,
Edge Service, Ambassadors, …
ACCELERATION
‣ Architektur, Blueprint
‣ Migrationsdatenbank
COACHING

25. Modernisierungen exponentiell skalieren:
Beschleunigt das Projekt und minimiert Risiken
Vorbrenner Migration in der Breite Nachbrenner
Zeit
Anwendungen in
Modernisierung
Governance-
Aufwände
■ Transparenz
■ Alignment
■ Architektur
■ Blueprint
1 - 3 Monate 6 - 18 Monate 1 - 3 Monate
■ Eigenständige Modernisierungs-Teams
■ Zentral: Acceleration, Enabling, Facilitation,
Coordination
■ Quality
■ Stability
■ Cost Control

26. 5. Die Modernisierung einer
Anwendung

27. Bei der Anwendungsmodernisierung haben wir fünf
wesentliche Strategien zur Auswahl (5 Rs)
Die Software wird grundlegend überarbeitet.
Rearchitect
(Auch: Lift and Shift) Die Software wird bis auf Konfiguration
unverändert migriert.
Rehost
Die Software wird in begrenztem Maß angepasst, etwa um
ordentlich auf einer Cloud-Plattform zu laufen.
Refactor
Die Software wird komplett neu gebaut.
Rebuild
Die Software wird ersetzt, etwa durch ein Produkt, oder entfällt ganz.
Replace

28. Das Problem mit
Lift & Shift…

29. Das Problem mit Rearchitect und Rebuild …
Modernization
Application
Modernization #1
Modernization #2
Modernization #3
Legacy
Replacement
Treadmill

30. Cloud-friendly Maturity ist ein guter Trade-Off für Bestand
■ Containerization
■ 12-Factor App Principles
■ Microservices
■ Cloud-native Apps
■ Monolithic Deployment
■ Traditional Infrastructure
Cloud Alien Cloud-friendly Cloud Native

31. Besser Adaptiv.
Das richtige Muster für jede Anwendung
Auf cloud-native Maturity für Anwendungen, bei denen das mit
vertretbaren Aufwand möglich ist
Rearchitect
Cloud-native Software, cloud-geeignete Produkte.
Rehost
Auf cloud-friendly Maturity für nicht cloud-nativen Bestand.
Refactor
Neue Anforderungen, hoffnungslose Fälle, toxische Technologie,
Mainframes o.ä., cloud-ungeeignete Produkte.
Rebuild
Neue Anforderungen, hoffnungslose Fälle, toxische Technologie,
Mainframes o.ä., cloud-ungeeignete Produkte.
Replace

32. 6. Der Nachbrenner

33. Stability & Performance
Bei aller Vorsicht: Cloud-Migration und andere
Modernisierungen sind große Changes. Fehler
passieren.
■ Latenz: Teilsysteme sind plötzlich getrennt
oder sogar über Clouds verteilt
■ Dinge wurden "übersehen".
■ Es wurde nicht ausreichend getestet.
Empfehlung:
■ Hypercare-Phase mit zentraler Unterstützung
pro Anwendung vorsehen.
■ Metriken erheben und vor allem auswerten.
■ Nachsteuern wo nötig.

34. Cost Control
Die Erwartungen an Kosteneinsparungen werden oft
nicht erfüllt. Hauptgründe:
■ Defensive Überprovisionierung
■ Elastizität nicht umgesetzt
■ Kostentransparenz (noch) nicht hergestellt
Empfehlung:
■ Überprovisionierung zu Beginn ist gut und richtig.
Unbedingt zulassen!
■ Genauso: Nachgelagerte Themen wie
Betriebskosten hinten anstellen.
■ Kosten- und Auslastungs-Transparenz herstellen,
mit aktiven Kümmerer
■ Nachgelagerte Themen wie Elastizität angehen

35. Fazit

36. Fazit
■ Verlässliche Transparenz über den Ist-Zustand,
durch sorgfältige Analyse sowohl in der Breite als
auch in der Tiefe, konsolidiert in einer
Single-Source-of-Truth
■ Klar definierte Ziele, eine Organisation, die am
selben Strang zieht und klare Kommunikation. Die
Business-Sicht und die technische Basis müssen im
Einklang sein.
■ Gute Migrations- und Zielarchitekturen und einen
Blueprint für die Anwendungen
Der Weg in die Cloud lohnt sich. Doch um den Bestand erfolgreich in die Cloud zu migrieren und die Vorteile der
Cloud zu heben, ist Arbeit und strukturiertes Vorgehen angesagt. Es braucht:
■ Einen Ansatz, um die Modernisierung über die
Organisation zu skalieren
■ Eine adaptive Strategie für die
Anwendungsmodernisierung. Cloud friendly
hat sich bewährt.
■ Einen Nachbrenner, der sicherstellt, dass die
Kosten, Stabilitäts- und Performance- Ziele
erreicht werden.

37. qaware.de
QAware GmbH
Aschauer Straße 32
81549 München
Tel. +49 89 232315-0
info@qaware.de
twitter.com/qaware
linkedin.com/company/qaware-gmbh
xing.com/companies/qawaregmbh
slideshare.net/qaware
github.com/qaware
Danke für’s Zuhören
Welche Fragen habt ihr?