Erfahrungsbericht Migration nach Azure: Ein Überblick

Das gesamte System lief in virtuellen Instanzen auf einem nicht gesicherten Hostsystem. Das System stand in einem Rechenzentrum, das neben seiner suboptimalen Lage neben eine Großschweißerei auch öfters schon Probleme mit der Netzanbindung hatte. 

Nach einigen Überlegungen (Kosten, Zeit, Skalierbarkeit, Verfügbarkeit) haben wir uns dann entschieden das gesamte System nicht wieder eins-zu-eins in einem anderen Rechenzentrum hochzuziehen, sondern in die Microsoft Azure Cloud zu migrieren. 

Dabei galt es verschiedene Services aus dem folgenden System verlustfrei und mit möglichst geringer Downtime zunächst cloud-ready zu refaktorisieren und anschließend umzuziehen:

• 2 IIS Webserver (Shopsystem mit versch. Schnittstellen-Applikationen)
• 2 IIS „AppServer“ (versch. Schnittstellen-Applikationen und Verwaltungsjobs)
• 2 Datenbankserver (Cluster)
• 2 Domaincontroller (Failover & Dateiverwaltung / Kundenuploads)
• 2 Cache-Server
• 2 Loadbalancer (auf die Datenbank-, IIS- sowie Cache-Server)
• 1 Log-Server
• VPN in die Produktionssysteme im Werk

Problemstellung

Das Shopsystem selber hat neben seiner Anbindung an die Produktionshallen

• 24/7 Betrieb
• Produktionssystem vs Webshops
• Subkunden / Subshops / Schnittstellenbenutzer
• Externe Dienste (BillPay / UPS, Paypal, …)
• Umsatz im mittleren 5-stelligen Bereich / Tag
• Feature-Entwicklung parallel zur Migration

Herausforderungen

Vor und während der Migration gab es etliche Herausforderungen. Die wohl größte war, dass das bestehende System über mehrere Jahre gewachsen, von einem komplett anderen Team (bereits nicht mehr in der Firma) und gleichzeitig keine strukturelle Dokumentation zu finden war. 

Daher wusste niemand, in welcher Weise Mitarbeiter der Produktion oder automatisierte Prozesse auf verschiedenste Schnittstellen, Dateien (es gab ein überall eingebundenes Netzlaufwerk) und Dienste zugriffen. Wir haben dies „U-Boote“ bzw „U-Boot-Dienste“ genannt.

Des weiteren gab es Legacy-Dienste, die eigentlich nicht mehr in Benutzung sein sollten, aber von manchen U-Boot-Diensten weiterhin benutzt wurden.

Während man solche Dinge durch genaues Analysieren und im Notfall durch sukzessives Aus- und Anschalten herausfinden kann, war ein viel größeres Problem die absolut unwartbare und nicht dokumentierte Code-Basis. 

Ein Beispiel: Es gab keinerlei Datenzugriffsebenen, jedes Modul arbeitete direkt auf der Datenbank, was oft zu Cache-Invalidierungs-Problemen führte. Zudem gab es keinerlei Tests, sodass wir nie wussten, ob wir mit einer Änderung nicht an einer anderen Stelle etwas kaputt machten. Dies hätte man durch ein aufwendiges Refactoring lösen können, wenn wir nicht zu der nächsten Herausforderung gekommen wären:

Der Kunde wollte dies nicht. Es sollte möglichst schnell der „as-is“-Stand in die Cloud gebracht werden bei gleichzeitiger Neu-Entwicklung verschiedener Features. Teilweise wurden diese sogar vom Kunden als „Blocker“ priorisiert, sodass die Arbeit an der Cloud-Migration zum Erliegen kam.

Dies führte dann aber auch zu einem enormen Zeitdruck, als der Kunde uns nach einer Aufwandsschätzung (wohl gemerkt: geschätzt ohne Feature-Neuentwicklung) mitteilte, dass der Vertrag mit dem bestehenden Hoster bereits zum Ende des Jahres gekündigt war.

Keine Optimale Ausgangslage.

Lösungsansatz

Da das gesamte System unüberschaubar groß und nicht wirklich einzuschätzen war, haben wir uns dafür entschieden kein „Big-Bang-Deployment“ durchzuführen, bei dem alle Systeme gleichzeitig umgeschaltet werden, sondern schrittweise mit ausführlicher Verprobung einzelner Prozesse zu migrieren. 

Gleichzeitig konnten wir dadurch an verschiedene Stellen nach dem Pfadpfinderprinzip arbeiten und zumindest die nötigsten Code-Umstrukturierungen und Verbesserungen durchführen.

Insbesondere der frühe Umzug der Datenbank hatte den Vorteil, dass wir mittels Azure Boardmitteln anschließend verschiedene Dienste ausgiebig vorher testen und so auch ohne eine weitere Downtime das ganze System in die Cloud überführen konnten. Zudem lassen sich dadurch die Systeme auch parallel betreiben, da die Daten in der gleichen Datenbank landen. Letztendlich ermöglichte diese Entscheidung auch das fehlerfreie Ausschalten der Alt-Systeme zwei Tage vor Weihnachten unter Volllast.

Zusammengefasst haben wir also die folgenden Schritte im Laufe von ca 6 Monaten durchgeführt:

1. Analyse des Alt-Systems
2. Erweitertes Logging aktivieren / einführen
3. Testumgebung schaffen (bereits in der Cloud)
4. DB umziehen (einzige Downtime ->  ca 1.5 h)
5. Cache umziehen (inkl. Refactoring)
6. Firewalls vorbereiten auf Testumgebungen
7. Kleinere Services verproben und migrieren (Serversystem für Serversystem)
8. Datei-Upload Refactoring (hierzu wird es einen gesonderten Artikel geben)
9. Größere Dienste zunächst im Parallelbetrieb laufen lassen (möglich, da bereits Cloud-DB verwendet wurde)
10. Schrittweises Abschalten der alten Infrastruktur
11. Sichern der alten Infrastruktur

Fazit / Lessons Learned

Im Folgenden dann noch eine kurze Liste unserer „Lessons Learned“:

• Sukzessive Migration (insbesondere Datenbank!) war die richtige Entscheidung
• Babysteps in konkrete Phasen mit ausreichender Testumgebung schneiden
• Sich trauen, zu wechseln
• Kunden auf „HickUps“ vorbereiten (auch alle Stakeholder über Infrastrukturänderungen informieren)
• Explorationsphasen erhöhen und Ergebnissicherung erzwingen
• Ausreichend Zeit (auch für Refactorings) einplanen
• Team motiviert halten & Erfolge feiern
• Exzessives Versionieren
• Bei guter Vorbereitung kann man sogar während des Weihnachtsgeschäfts die alte Infrastruktur abschalten (–> wollten wir nicht, aber es wurden sehr unerwartet Fakten geschaffen)

Nächste Schritte

Nach dem erfolgreichen Umzug aller Systeme freut sich das gesamte Team nun darauf, die volle Funktionalität der Cloud auszunutzen. Insbesondere stehen die folgenden Punkte an, für die es dann noch entsprechende weitere Erfahrungsberichte geben wird.

• Aufbau einer Continous Delivery Deployment Pipeline (inkl. Test, Staging und Entwicklungssystemen)
• Erweitertes Monitoring & Analyse
• Autoscaling (DB, App-Instanzen, WebServices, …)

Abschließend lässt sich sagen: Da wir insbesondere mit Testumgebungen und Skalierbarkeit bzw. Versionierbarkeit von ganzen Umgebungen in der Azure Cloud so gute Erfahrungen gemacht haben, können wir jedem Online-System die Migration in die „Wolke“ wärmstens ans Herz legen.