Block 04 – Softwaremigration¶

Lernziele¶

Du kannst die wichtigsten Migrationsansätze erklären und vergleichen
Du kannst den Unterschied zwischen Monolith und Microservices beschreiben
Du kannst erklären was Caching ist und welche Probleme es löst
Du kannst beschreiben warum Migrationen scheitern und wie man das verhindert

1. Was ist eine Softwaremigration?¶

Eine Softwaremigration ist der Prozess, ein bestehendes System in einen neuen Zustand zu überführen. Das kann bedeuten:

Ein System auf neue Hardware oder in die Cloud verschieben
Eine Applikation auf eine neuere Version aktualisieren
Daten von einem System in ein anderes übertragen
Eine Architektur grundlegend umbauen

Wichtig: Eine Migration ist kein Neustart – das bestehende System läuft weiter, bis die Migration abgeschlossen ist. Das ist der Hauptunterschied zu einer Neuinstallation.

2. Migrationsansätze¶

Es gibt verschiedene Strategien wie man eine Migration angeht. Die Wahl hängt ab von: Risikotoleranz, verfügbarer Downtime, Teamgrösse und Komplexität des Systems.

Big Bang Migration¶

Das gesamte System wird auf einmal migriert. An einem definierten Zeitpunkt (Cutover) wird das alte System abgeschaltet und das neue aktiviert.

gantt
    dateFormat  YYYY-MM-DD
    section Big Bang
    Altes System läuft      :a1, 2024-01-01, 2024-03-01
    Vorbereitung & Test     :a2, 2024-02-01, 2024-03-01
    Cutover (Downtime)      :crit, a3, 2024-03-01, 2024-03-02
    Neues System läuft      :a4, 2024-03-02, 2024-04-01

Vorteile: - Einfach zu planen – klarer Schnitt - Kein paralleler Betrieb nötig - Schnell abgeschlossen

Nachteile: - Hohes Risiko – wenn etwas schiefläuft, ist alles ausgefallen - Downtime oft unvermeidbar - Schwierig rückgängig zu machen

Geeignet für: Kleine Systeme, unkritische Applikationen, kurze Migrationen

Phased Migration (Stufenmigration)¶

Das System wird schrittweise migriert – Komponente für Komponente, Modul für Modul.

gantt
    dateFormat  YYYY-MM-DD
    section Phased
    Modul A migrieren   :a1, 2024-01-01, 2024-02-01
    Modul B migrieren   :a2, 2024-02-01, 2024-03-01
    Modul C migrieren   :a3, 2024-03-01, 2024-04-01
    Abschluss           :a4, 2024-04-01, 2024-04-15

Vorteile: - Geringeres Risiko – Fehler betreffen nur einen Teil - Kein kompletter Ausfall - Lerneffekt: Jede Phase verbessert die nächste

Nachteile: - Alter und neuer Stand müssen parallel betrieben werden - Komplexere Planung - Dauert länger

Geeignet für: Grosse, komplexe Systeme, kritische Produktionsumgebungen

Parallel Operation¶

Altes und neues System laufen gleichzeitig. Daten werden in beide Systeme geschrieben, bis das neue System bewiesen hat, dass es funktioniert.

Vorteile: - Maximale Sicherheit – Rückfall auf altes System jederzeit möglich - Echte Vergleichsdaten zwischen alt und neu

Nachteile: - Doppelter Aufwand (zwei Systeme betreiben) - Teuer - Datenkonsistenz zwischen zwei Systemen ist komplex

Geeignet für: Hochkritische Systeme (Banking, Medizin)

Vergleich¶

	Big Bang	Phased	Parallel
Risiko	❌ Hoch	✅ Gering	✅ Minimal
Downtime	❌ Ja	⚠️ Teilweise	✅ Nein
Aufwand	✅ Gering	⚠️ Mittel	❌ Hoch
Rückfallmöglichkeit	❌ Schwierig	⚠️ Möglich	✅ Jederzeit

3. Warum scheitern Migrationen?¶

Migrationen scheitern häufiger als man denkt. Die häufigsten Ursachen:

Ursache	Beschreibung
Unvollständige Datenmigration	Nicht alle Daten wurden übertragen oder sind korrumpiert
Fehlende Tests	Das neue System wurde nicht ausreichend getestet
Unterschätzte Abhängigkeiten	System A hängt von System B ab – das wurde vergessen
Kein Rollback-Plan	Bei Problemen gibt es keinen definierten Weg zurück
Mangelnde Kommunikation	Benutzer wurden nicht informiert, IT-Teams nicht koordiniert
Unterschätzte Downtime	Die Migration dauert länger als geplant

Im Modul 158: Du erstellst einen Projektplan mit einem definierten Cutover-Zeitpunkt und einem Rollback-Punkt. Das ist kein bürokratischer Overhead – es ist die Lektion aus unzähligen gescheiterten Migrationen.

4. Monolith vs. Microservices¶

Die Architektur einer Applikation beeinflusst massgeblich wie und ob sie migriert werden kann.

Monolith¶

Eine monolithische Applikation ist als einzelne Einheit gebaut. Alle Komponenten (Benutzeroberfläche, Geschäftslogik, Datenbankzugriff) sind eng miteinander verbunden und laufen als ein Prozess.

flowchart TD
    subgraph Monolith
        UI[UI] --> BL[Geschäftslogik]
        BL --> DB[Datenbankzugriff]
        BL --> AUTH[Authentifizierung]
        BL --> MAIL[E-Mail]
    end

Vorteile: - Einfacher zu entwickeln und debuggen - Einfaches Deployment (eine Applikation deployen) - Geringere Latenz (keine Netzwerkkommunikation zwischen Komponenten)

Nachteile: - Schwer zu skalieren – du musst immer das gesamte System skalieren - Ein Fehler kann das gesamte System zum Absturz bringen - Mit der Zeit wird der Code komplex und schwer wartbar ("Big Ball of Mud")

WordPress ist ein Monolith. Webserver, PHP, Datenbank und alle Plugins laufen eng gekoppelt zusammen.

Microservices¶

Eine Microservice-Architektur teilt die Applikation in viele kleine, unabhängige Dienste auf. Jeder Dienst hat eine einzige Aufgabe und kommuniziert mit anderen über APIs.

flowchart TD
    GW[API Gateway] --> US[User Service]
    GW --> PS[Post Service]
    GW --> MS[Mail Service]
    GW --> AS[Auth Service]
    US --> DB1[(User DB)]
    PS --> DB2[(Post DB)]

Vorteile: - Einzelne Dienste können unabhängig skaliert werden - Fällt ein Dienst aus, läuft der Rest weiter - Teams können unabhängig an verschiedenen Diensten arbeiten - Jeder Dienst kann in der besten Sprache/Technologie für seine Aufgabe gebaut sein

Nachteile: - Deutlich komplexer zu betreiben (viele Dienste, viele Deployments) - Netzwerkkommunikation zwischen Diensten erzeugt Latenz - Debugging ist schwieriger (Fehler über mehrere Dienste verteilt)

Vergleich¶

	Monolith	Microservices
Komplexität	✅ Gering	❌ Hoch
Skalierbarkeit	⚠️ Nur komplett	✅ Gezielt
Ausfallsicherheit	❌ Single Point of Failure	✅ Teilausfälle möglich
Deployment	✅ Einfach	❌ Komplex
Geeignet für	Kleine bis mittlere Systeme	Grosse, verteilte Systeme

5. Caching¶

Caching bedeutet, Daten oder Berechnungsergebnisse zwischenzuspeichern, damit sie beim nächsten Zugriff schneller zur Verfügung stehen.

Das Problem ohne Cache¶

Jede Anfrage an eine WordPress-Seite löst aus: 1. PHP verarbeitet die Anfrage 2. Datenbankabfragen werden ausgeführt 3. HTML wird generiert 4. Antwort wird gesendet

Bei 1000 gleichzeitigen Besuchern: 1000 × dieselben Datenbankabfragen.

Mit Cache¶

flowchart LR
    C[Client] --> CA{Cache\nvorhanden?}
    CA -->|Ja| R1[Gecachte Antwort\nsofort]
    CA -->|Nein| PHP[PHP + DB]
    PHP --> CA
    PHP --> R2[Antwort generieren\n+ Cache speichern]

Caching-Ebenen¶

Ebene	Beschreibung	Tool
Browser Cache	Browser speichert CSS, Bilder lokal	HTTP-Header
Server Cache	Fertige HTML-Seiten werden gespeichert	WordPress-Plugins (WP Super Cache)
Objekt Cache	Datenbankabfragen werden im RAM gespeichert	Redis, Memcached
CDN Cache	Statische Dateien weltweit verteilt	Cloudflare, AWS CloudFront

Cache Invalidierung¶

Das schwierigste Problem beim Caching: Wann ist ein Cache veraltet?

Wenn du einen Blogpost aktualisierst, muss der alte gecachte HTML-Code gelöscht werden – sonst sehen Besucher noch den alten Inhalt. Dieser Prozess heisst Cache Invalidierung.

"There are only two hard things in Computer Science: cache invalidation and naming things." – Phil Karlton

Testfragen¶

Erkläre den Unterschied zwischen Big Bang und Phased Migration. Wann würdest du welchen Ansatz wählen?
Nenne drei häufige Gründe warum Migrationen scheitern.
Was ist ein Rollback-Plan und warum ist er bei jeder Migration wichtig?
Was ist der Hauptunterschied zwischen einem Monolithen und Microservices?
WordPress ist ein Monolith. Nenne einen Vor- und einen Nachteil dieser Architektur im Kontext der Migration.
Was ist Caching und welches Problem löst es bei WordPress?
Was bedeutet Cache Invalidierung und warum ist sie schwierig?
Du hast eine WordPress-Seite mit 10'000 täglichen Besuchern. Welche Caching-Ebenen würdest du einsetzen?