Embed Size (px)
Citation preview
Chicken Little, Cold Turkey .. oder was?
Welche Migrationsstrategie ist die Richtige?
3
Stephan Kaps
Techn. Projektleiter
Software-Architekt
JEE – SOA -Host
Java seit 2002Speaker &
Autor
ISTQB, ISAQB, IREB und ITIL zertifiziert
Leidenschaft sind neue
Technologien und Methoden
Agenda
Einleitung
Migrationsstrategien
Big Bang Approach (Cold Turkey)
Chicken Little
Database First
Database Last
Composite Database Approach
Butterfly Methodology
Zusammenfassung
Einleitung
Unter Migration versteht man
Jegliche Art von Umstellung
Migrationen sind
rein technische Transformationen
mit einer klaren Anforderungsdefinition
Zählen zum Software-Reengineering
Ziel ist
Fachliche Funktionalität beizubehalten
Weitere Ziele
Durchgängige
Systemintegration
Realisierung flexibler und
transparenter
Arbeitsabläufe
Einsparung von Personal
und Zeit
Arbeitserleichterungen
Produktivitätserhöhungen
Anforderungen
unterbrechungsfreien, sicheren, zuverlässigen Betrieb zu garantieren,
nur die Änderungen durchzuführen, die notwendig erscheinen, um aktuelle und zukünftig erwartete Anforderung abzudecken,
auf alle anderen Änderungen zu verzichten, um den Umfang und das Risiko der Migration zu verringern,
den alten Code so wenig wie möglich abzuändern, um Risiken zu minimieren,
Anforderungen (2)
den alten Code soweit abzuändern, dass
er die Migration unterstützt,
möglichst große Flexibilität einzubauen,
um zukünftige Änderungen zu erleichtern,
mögliche negative Auswirkungen der
Änderungen zu minimieren,
den Nutzen moderner Technologien und
Methoden zu maximieren.
Altsystem
Historisch gewachsen
Keine ausreichende
Dokumentation
Veraltete Betriebs- und
Entwicklungsumgebungen
Zahlreiche Schnittstellen
Hohe Komplexität
Mangel an Expertenwissen
Nachdokumentation
Wird herausgezögert, weil
Zunächst kein Mehrwert durch die Umstellung entsteht
Umstellungskosten entstehen
Erhöhte Ausfallrisiken entstehen
Gewachsener Umfang an Funktionen existiert
An Neuentwicklung meist kein Weg vorbei führt
Meist große Datenmengen existieren
Prozess
Prozess
Transformationsstrategien
Konversion
Kapselung
Neuentwicklung
Kann für jedes Modul
individuell bestimmt
werden
Portfolio Analyse
Übergabestrategie
Die Form der Übergabe
(cut-over)
Als Gesamtheit zu einem
bestimmten Termin oder
schrittweise
Wird bestimmt durch die
Umstellungsstrategie
Big Bang oder
inkrementell
Big Bang Approach
Big Bang Approach
komplette Neuentwicklung des Altsystems mit Hilfe moderner Entwicklungsmethoden, Architekturen, Tools und Datenbanken
Parallel zum Altsystem
Sind alle Tests bestanden, wird das Altsystem deaktiviert und das neue System übernimmt
Probleme und Risiken
Es muss ein besseres System versprochen
werden
Geschäftsregeln stehen niemals still
Spezifikationen sind rar
Nicht dokumentierte Abhängigkeiten
Die Datenmenge ist zu groß
Das Managen solch großer Projekte ist
kompliziert
Verspätung wird normalerweise nicht toleriert
Solche große Projekte blähen sich meist auf
Langwierige Analysen verhindern den Beginn
Die Liebe zum Altsystem blüht wieder auf
Vor- und Nachteile
PRO
Geringere Entwicklungskosten
Geschwindigkeit des Migrationsprozesses
CONTRA
Flash cut ist ohne eine Downtime von Datenbank oder Applikation nicht möglich
Chicken Little Strategy
Chicken Little Strategy
Inkrementelle
Migrationsstrategie
mit elf Schritten
Je kleiner die
Schritte, desto
kleiner das Risiko
Wenn ein Schritt
fehlschlägt, muss
nur dieser
wiederholt werden
Gateways
Bei der Chicken-Little-Alternative kommen Gateways zum Einsatz. Deren Aufgabe ist es:
Anfragen und Daten zwischen den betroffenen Komponenten zu übersetzen,
zwischen den betroffenen Komponenten zu koordinieren, um die Konsistenz bei Änderungen sicher zustellen,
Komponenten von Änderungen an anderen Komponenten abzuschirmen
Wann geeignet?
Unstrukturiert
alles in einem Modul
Hoher Sanierungsaufwand
Semistrukturiert
Z.B. Anwendungs- und Datenschicht eng miteinander verbunden
Gut strukturiert
Präsentation, Datenzugriff und Logik voneinander getrennt
Die 11 Schritte
1. Inkrementelle Analyse des
AltsystemsAnforderungen des Alt- und Ziel-Systems müssen erstellt
werden, eventuell muss das Altsystem mit Reverse-
Engineering Techniken analysiert werden.
Die 11 Schritte
2. Inkrementelle Strukturierung
des AltsystemsDefinierte Schnittstellen zwischen Modulen und
Datenbank-Services müssen gegebenenfalls erstellt
werden.
Das kann aufwändig bis unmöglich sein!
Die 11 Schritte
3. Inkrementelles Design der
Ziel-InterfacesAn dieser Stelle werden hauptsächlich die User-Interfaces
spezifiziert und es wird entschieden, ob ein Gateway
erstellt wird.
Die 11 Schritte
4. Inkrementelles Design der
Ziel-AnwendungenFunktionalität und Prozessflow der Alt-Anwendungen
werden übernommen oder neu entwickelt
Die 11 Schritte
5. Inkrementelles Design der
Ziel-DatenbankEventuell müssen Tabellen in relationalen Schemas anders
designed werden.
Die 11 Schritte
6. Inkrementelles Installieren
der Ziel-UmgebungAnforderungen werden identifiziert, installiert und
getestet.
Die 11 Schritte
7. Inkrementelles Erstellen und
Installieren der benötigten
GatewaysAnhand der Anforderungen (Funktionen, Architektur und
nicht-funktionalen Anforderungen) ist ein Gateway zu
entwickeln oder zu kaufen, um es daraufhin zu
installieren. Das kann sehr komplex sein!
Die 11 Schritte
8. Inkrementelles Migrieren der
Alt-DatenbankInstallation des Datenbankmanagementsystems (DBMS)
und Implementation des Schemas aus Schritt 5
Die 11 Schritte
9. Inkrementelles Migrieren der
Alt-AnwendungenAuswahl und Migration eines oder mehrerer Module
Die 11 Schritte
10. Inkrementelles Migrieren
der Alt-InterfacesAuswahl und Migration eines oder mehrerer Interfaces
Die 11 Schritte
11. Inkrementelles Umschalten
auf die ZielumgebungModul für Modul, Oberfläche für Oberfläche kann
umgeschaltet werden
Zusammenfassung
Chicken Little bedeutet im Endergebnis
dennoch eine komplette Neuentwicklung
des Systems, allerdings mit geringeren
Risiken als bei dem Big-Bang-Ansatz
Probleme
Komplexität bei der
Umstellung
Durch technische Kopplung von
Alt- und Neusystem
Großer Aufwand
Für eine Eigenentwicklung des
Gateways
Bis zur Unmöglichkeit
Aufteilung des Gesamtsystems in
kleine Pakete, die voneinander
unabhängig sind
Zusammenfassung
Cold Turkey Chicken Little
Risiko Groß Kontrollierbar
Fehleranfälligkeit Das ganze Projekt schlägt fehl Nur einzelne Schritte schlagen fehl
Ergebnisse Sofort nach Fertigstellung
sichtbar, evtl. aber nicht von
langer Dauer
Nutzen steigt stetig mit der
Entwicklung des neuen Systems
Ausblick Nicht vorhersagbar bis zum
Endergebnis
Konservativ optimistisch
Database First Approach
Database First Approach
auch Forward Migration Methodgenannt
Big Bang Migration der Datenbank
Forward Gateway notwendig
Applikationen und GUIs können inkrementell auf Zielplattform entwickelt werden
Entwicklung beeinflusst nicht den Betrieb des Altsystems
Neue Programmiersprachen und Reporting Tools können sofort verwendet werden
Probleme
Das Forward-Gateway zu entwickeln
kann komplex bis unmöglich werden
Der Markt setzt auf Reverse-Gateways
Das Altsystem muss klar definierte
Schnittstellen zum Datenbank-Layer
aufweisen
Evtl. viele externe Systeme, die auf
Altsystem zugreifen (z.B. Berichte)
Neue Datenbankstrukturen müssen
designed und ein Mapping implementiert
werden (z.B. Multiple Felder und
Periodengruppen)
Probleme
Das Altsystem muss klar definierte
Schnittstellen zum Datenbank-Layer
aufweisen
Fazit
Klar definierte Schnittstellen wird
es meist nicht geben
Großer „Sanierungsaufwand“ nötig
Es wird nichts zur Datenmigration
gesagt (was ist bei großen
Datenbeständen?)
Evtl. Performance-Probleme
Database Last Approach
Database Last Approach
Auch Reverse Migration Methodgenannt
Datenbank bleibt auf dem Altsystem
Anwendung und GUI wird in Zielumgebung neu entwickelt
Zugriff über Reverse-Gateways auf Daten des Altsystems
Probleme
Das Mapping wird vom Gateway
übernommen, dies kann komplex
und langsam sein
Ggf. Performance Probleme bei
neuen Anwendungen
Gateway muss Hilfsfunktionen
bereitstellen, um RDBMS
Funktionen zu ersetzen
Composite Database Approach
Composite Database
Approach
Auch Parallel Database Strategy genannt
Neue Datenbank parallel zur alten
Neue Anwendungen arbeiten mit neuer Datenbank
Daten-Duplikationen müssen synchron und konsistent gehalten werden
Forward- und Reverse-Gateways notwendig
Koordinator leitet Operationen weiter und stellt über Two-Phase-Commit (2PC) die Transaktionssicherheit her
Reverse
Merkmale
Meist eine Eigenentwicklung des Koordinators notwendig
Das kann fehleranfällig, zeit-und kostenintensiv und technisch unmöglich sein
Wenn möglich, eine Tabelle nach der anderen migrieren
Butterfly Methodology
Butterfly Methodology
Hier stehen die Daten im Mittelpunkt
Kommt ohne den Einsatz von Gateways aus
Zu Beginn initiale Datenmigration
Darauf aufbauen findet Neuentwicklung statt
Betrieb des Altsystem wird nicht beeinflusst
Funktionsweise
1. Sobald Datenmigration beginnt, wird Bestand des Altsystems eingefroren und mit Schreibschutz versehen
Ein Data-Access-Allocator (DAA) leitet von nun an alle Anfragen um. Änderungen werden in temporären Speichern verwaltet. Bei dem Aufruf bereits geänderter Informationen, werden diese aus dem temporären Speicher gelesen.
Funktionsweise
2. Überführung des Datenbestandes des Altsystems in das neue System mit Hilfe des „Chrysalizers“
Dies geschieht auf Grundlage definierter Transformationsregeln, die im Chrysalizerimplementiert sind. Dies geschieht ohne Datenverlust, da zwischenzeitliche Änderungen im ersten Temporärspeicher abgelegt werden.
Funktionsweise
3. Migration der Daten des
Temporärspeichers 1
Zwischenzeitliche Änderungen werden in
Temporärspeicher 2 geschrieben und der erste wird
mit Schreibschutz versehen.
Funktionsweise
4. Das geht so lange, bis die Dauer
der Migration des letzten
Temporärspeichers so kurz ist,
dass keine Änderungen mehr
stattfinden konnten
In diesem Stadium kann das Altsystem abgeschaltet,
der letzte Temporärspeicher überführt und das neue
System in Betrieb genommen werden.
Vorteile
Ermöglicht eine Migration
ohne Downtime
Man kann jederzeit
abbrechen
(Temporärspeicher wieder
zurückführen)
Parallele Neuentwicklung
kann umfangreiche Tests
mit aktuellen Daten
durchführen
Nachteile
Bei großen
Datenbeständen ist ein
hoher Hardwareeinsatz
notwendig (für eine große
Zahl an
Temporärspeichern)
Die Entwicklung des DAA
kann sehr aufwändig
werden
v / u
Ob die Butterfly-Methode erfolgreich
ist, hängt vor allem von dem Faktor v
/ u ab
u ist die Geschwindigkeit des Chrysalizers
v die Geschwindigkeit des DAA, neue
Temporärspeicher anzulegen.
Bei v = 0 ähnelt die Vorgehensweise der
Big-Bang-Strategie
bei v > u wird die Migration nie enden
Erfolgsfaktoren
ein gründliches
Verständnis des Alt-
und Zielsystems
eine fehlerfreie
Testdatenbank
(Initialmigration)
ein schneller
Chrysalizer
ein effizienter Data-
Access-Allocator
Zusammenfassung
Strategien
ColdTurkey beschäftigt sich mit einer Neuentwicklung des
Altsystems mit Hilfe moderner Entwicklungsmethoden aber mit
enormen Risikopotential, das mit dem BigBang seinen hoffentlich
positiven Abschluss findet.
ChickenLittle ist eine Migrationsstrategie mit der die vollständige
Neuentwicklung des Systems in elf kleine Schritte zerlegt wird,
die inkrementell durchgeführt werden.
Database-First migriert zuerst das Datenbanksystem auf ein
modernes System. Dafür ist der Einsatz eines Forward-Gateways
notwendig.
Database-Last kann nur auf Systeme mit definierter
Datenbackendschnittstelle angewandt werden, auf die aus dem
Zielsystems über Reverse-Gateways zugegriffen wird.
Composite Database ist eine Kombination aus Database First und
Last
Butterfly ist eine Strategie zur Migration, die ohne den Einsatz
von Gateways auskommt. Die Strategie unterstützt nur reine
Datenmigration und keine Kooperation zwischen Legacy-System
und Zielsystem.
Zusammenfassung
Keine allgemeine Empfehlung möglich
Geringe Änderungen am Datenschema =>
Chicken Little
Größere Schemaänderungen => Cold
Turkey
Entscheidung immer an jeweilige
Situation angepasst
Entscheidende Fragen
Umfang der Daten
Ist eine Downtime akzeptabel?
Kritikalität des Gesamtsystems
Verfügbares Personal
Ist das System in unabhängige Module zerlegbar?
aim42.org
Architecture
improvement method
OpenSource
Software evolution und
optimization
Sammlung von Pattern
und Best Practices für
die Phasen analyze,
evaluate und improve
Mal was anderes
Continuous Delivery =
Continuous Migration?
What about Feature Toggles?
Or Database Migration Tools?
work just simply smarter
● Continuous
Delivery
● Application
Lifecycle
Management
● BizDevOps
● Vorträge
● Artikel
● PoCs
● JIRA
● Jenkins
● Confluence
● Schulung
● Coaching
● Training
