In der heutigen, sich rasant verändernden digitalen Landschaft stellt die Cloud-Migration eine zentrale Unternehmensstrategie dar. Gerade für Unternehmen, die auf traditionelle On-Premises- oder Private-Cloud-Infrastrukturen angewiesen sind, ergeben sich oft Herausforderungen hinsichtlich Skalierbarkeit, Betriebskomplexität und Innovationsgeschwindigkeit. Der Schritt in die Cloud ist für diese Unternehmen nicht nur eine technische Umstellung, sondern auch eine transformative Chance zur Bewältigung dieser Hürden und zur Erschließung neuer Möglichkeiten.
Ein treffendes Beispiel hierfür liefert einer unserer Kunden aus der Automobilbranche. Im Rahmen eines Kundenprojekts haben wir ein zentrales System auf Basis von Kubernetes in der Private Cloud des Kunden von Grund auf konzipiert und kontinuierlich weiterentwickelt. Dieses System stand nun vor der Herausforderung, in die AWS-Cloud migriert zu werden.
On-Premises Systemlandschaft
Bei dem zu migrierenden System handelt es sich um eine weltweit verfügbare und hochspezialisierte Software, die für eine Vielzahl unterschiedlicher Kundenkommunikationen zuständig ist und somit wichtige Geschäftsprozesse abbildet. Sie wurde in einer Kubernetes-basierten Container-as-a-Service-Lösung (CaaS) betrieben und umfasst im Wesentlichen folgende Komponenten:
- 22 Spring-basierte Microservices
- Datenbank (On-Premises MongoDB Service)
- Message Broker (ActiveMQ)
- Logging- und Monitoring-Tools, wie Prometheus, Grafana, Logstash und Opensearch
Der Erfolg des Systems hängt stark von seiner Zuverlässigkeit und Effizienz ab. Doch die Einschränkungen der On-Premises-Plattform wurden nach und nach immer deutlicher. Probleme mit Skalierbarkeit, Wartung und technologischen Begrenzungen führten zu dem Wunsch, in die Cloud zu migrieren.
Cloud-Migration – eine Herausforderung
Eine Cloud-Migration ist allerdings aufwendig und bindet Ressourcen. Im täglichen Projektgeschäft stehen Produktivität und Umsatzgenerierung meist der Wartung und Aktualisierung der Systemlandschaft gegenüber. Fortwährende Entwicklung – und damit das Schaffen neuer Mehrwerte für Kunde und Endnutzer – sichert den Projekterfolg und kann daher höchstens reduziert, aber nicht pausiert werden. Ein “Jetzt machen wir erstmal alle Migration“ war für uns eine Wunschvorstellung, die sich in der Praxis jedoch nicht umsetzen ließ. Die Herausforderung einer Migration bei laufendem Betrieb und fortwährender Weiterentwicklung war somit gegeben.
Zur Abschätzung des Aufwands für die Migration mussten notwendige Änderungen an Infrastruktur und Technologien geprüft werden. Dabei spielten auch die Kosten für den Betrieb in neuer Umgebung eine große Rolle. Hierfür analysierten wir mögliche Laufzeitumgebungen in der Cloud und stellten Schätzungen der Betriebskosten auf.
Zusammen mit dem Kunden diskutierten wir die Vorteile einer Migration und das Inkaufnehmen der damit verbundenen Aufwände und Kosten. So konnten wir dem Kunden beispielsweise Kostenersparnisse durch die effiziente Nutzung von Cloud-Ressourcen und Produktivitätsgewinne durch den Wegfall vieler Wartungsaufgaben in Aussicht stellen. Dies gilt allerdings nur, wenn man sich intensiv mit dem Zielsystem befasst und die von AWS bereitgestellten Stellschrauben bestmöglich nutzt. Andernfalls können die Kosten im Betrieb in der Cloud sogar manchmal höher sein.
Nach erfolgter Kosten-Nutzen-Analyse und der Entscheidung für die Migration stellte sich für uns die Frage: Wann wagen wir den Sprung in die Cloud?
Die Zeit ist gekommen!
Wie so häufig wurde der Zeitpunkt fremdbestimmt. Es gab kritische Faktoren, die uns die Entscheidung abnahmen:
Erstens näherte sich der Lebenszyklus der bestehenden On-Premises-Plattform und ihrer MongoDB-Komponente dem Ende. Bis 2025 würde die On-Premises-Infrastruktur nicht mehr unterstützt werden. Auch der MongoDB-Service sollte bis Ende 2024 auslaufen. Diese bevorstehenden Sundowns machten den Wechsel in die Cloud nicht nur zu einer strategischen Wahl, sondern zu einer Notwendigkeit.
Zweitens zeigte der wachsende Bedarf an regional getrennter Datenverarbeitung, insbesondere in Bereichen mit Compliance- und Latenzanforderungen, die Grenzen der aktuellen Plattform auf. Durch den Wechsel in die Cloud könnte das System diese Herausforderungen mit einer regional getrennten Architektur und Infrastruktur bewältigen.
Schließlich versprach der Wechsel zu AWS erhebliche Chancen für mehr Flexibilität und Wachstum. Das robuste Ökosystem von AWS bietet eine Vielzahl von Diensten, die gut zu unseren Anforderungen passen – von Datenbanklösungen bis hin zu fortschrittlichen Monitoring-Funktionen.
Leider ist nicht alles Gold, was glänzt. Neben den vielen Freiheiten und Möglichkeiten, die die Cloud bietet, bedeutet der Sprung in die Cloud auch das Verlassen des privaten Raumes des Kunden und somit das Verlagern von Verarbeitung und Datenspeicherung in die Hände eines Dritten (AWS). Dadurch entstehen deutlich höhere Anforderungen an die Verarbeitungs- und Datensicherheit – insbesondere, wenn man mit sensiblen Kundendaten arbeitet.
Verifizierungsprozess
Um diesem hohen Sicherheitsanspruch gerecht zu werden, haben wir einen Verifizierungsprozess durchlaufen, bei dem unser System auf Herz und Nieren geprüft wurde. Dabei wurde nahezu jedes Element unserer Systemlandschaft in Hinblick auf Sicherheit und Schutz der Daten betrachtet und bewertet.
So wurde beispielsweise sichergestellt, dass alle Endpunkte durch state-of-the-art Authentifizierungs- und Autorisierungsmechanismen geschützt sind. Auch Themen wie Zugriffskontrolle, Logging- und Backup-Konzept wurden unter die Lupe genommen. Zudem lag ein Fokus auf der Integration von Tools für Static Application Security Testing (SAST) und Software Composition Analysis (SCA), wie beispielsweise Blackduck und Coverity.
Erfreulicherweise ergab sich daraus nur ein geringer Anpassungsbedarf, da wir unser System bereits größtenteils cloud-ready konzipiert und aktuelle Sicherheitsstandards implementiert haben.
Neben diesem Verifizierungsprozess, der uns eine ganze Zeit begleitet hat, stand uns eine weitere große Herausforderung bevor:
Was tun mit der Datenbank?
Aufgrund des bevorstehenden Sundowns des MongoDB-Services mussten wir nach einer Alternative suchen. Die Auswahl an Datenbanken und Diensten ist vielfältig, aber Zeit und Budget sind knapp. Nach einer intensiven Analyse unserer Möglichkeiten und dem einen oder anderen Test in der Cloud-Umgebung entschieden wir uns für die Migration zur AWS-nativen DocumentDB.
Einen Deep Dive mit Analysen und Hintergründen zu dieser Technologieentscheidung werden wir in einem weiteren Blogbeitrag veröffentlichen.
Ziel-Infrastruktur
Unsere bisherige Infrastruktur bestand im Wesentlichen aus einer Sammlung von Kubernetes-Ressourcen, die wir versioniert abgelegt und zum Aufsetzen und Ändern der Infrastruktur über eine automatisierte Pipeline deployt haben. Da wir durch die On-Premises-CaaS-Lösung keine Befugnisse außerhalb des Kubernetes-Clusters hatten, war dies eine tragbare Lösung.
In der Cloud verlangte es allerdings nach einem eher prozeduralen Ansatz, um den viel größeren Infrastruktur-Scope zu bewältigen. Somit entschieden wir uns, Terraform für das Aufsetzen der Infrastruktur zu verwenden.
Dadurch war es uns außerdem leicht möglich, unsere Infrastruktur für die Vielzahl unterschiedlicher Laufzeitumgebungen für alle Regionen und Stages zu vervielfältigen.
Aufgrund des engen Zeithorizonts wechselten wir nur auf die nötigsten AWS-Komponenten für den Betrieb unseres Systems. So kamen neben Komponenten zur Gewährleistung der Netzwerkkommunikation im Wesentlichen das Amazon EKS (Elastic Kubernetes Service) mit EC2 Instanzen, eine ECR (Elastic Container Registry), Cloudwatch, S3-Buckets und natürlich die DocumentDB zum Einsatz. Wenige Komponenten, wie ActiveMQ oder Prometheus und Grafana, betrieben wir vorerst weiterhin selbst.
Zudem haben wir die Chance der Migration und die gewonnene Gestaltungsfreiheit genutzt, um unsere Infrastruktur effizienter und kosteneffektiver zu gestalten. So haben wir zum Beispiel unsere Container-Registry und Komponenten, die die Kommunikation in das Netzwerk des Kunden sicherstellen, in einem zentralen AWS-Account gebündelt, anstatt sie je Laufzeitumgebung einzurichten und vorzuhalten. Außerdem haben wir uns entschieden, eine unserer Test-Stages nicht mehr konstant bereitzuhalten, sondern sie dynamisch bei Bedarf hochzufahren. Auch die Typen der EC2-Instanzen haben wir entsprechend ihrer Aufgabe und Last gewählt und die Nutzung von AWS Saving Plans bzw. Spot-Instanzen in Betracht gezogen, wodurch sich die Kosten weiter reduzieren.
Herausforderung Umsysteme
Eine weitere Herausforderung stellten unsere Umsysteme dar, von denen wir eine Vielzahl von Events erhalten. Diese müssen rechtzeitig und vollständig bei uns verarbeitet werden, um ein korrektes Verhalten zu gewährleisten. Da unser System kritische Kundenkommunikation sicherstellen muss, sind zeitliche Abweichungen oder gar der Verlust von Events fachlich problematisch und daher nicht akzeptabel.
Durch die Migration war eine Downtime nicht zu vermeiden. Zum Verarbeitungsstart in der neuen Cloud-Umgebung sollten allerdings alle neuen und versäumten Events auch im neuen System empfangen und dort prozessiert werden. Das machte eine Parallelversorgung und einen Nachversand nicht zugestellter Events durch die Event-Provider notwendig.
Zudem vertreibt unser Kunde eine Smartphone-App, die ebenfalls auf unser System zugreift. Leider ist hier der Wechsel auf unsere neue Umgebung nur über das Ausspielen einer neuen App-Version möglich. Allerdings werden neue App-Versionen meist über mehrere Tage hinweg ausgerollt. Einige Kunden deaktivieren sogar automatische Updates von Apps und verbleiben somit länger auf einer alten Version, die nach der Migration die von uns bereitgestellte Funktionalität verlieren würde.
Um diese Herausforderung zu lösen haben wir uns entschlossen, unsere alten Domains auf die neue Umgebung zeigen zu lassen. Um Ausfallzeiten durch DNS Caches, die noch die alte Adresse halten, zu vermeiden, haben wir zusätzlich ein Forwarding der App Calls aus der On-Prem-Umgebung in die Cloud eingerichtet. So konnten wir einen reibungslosen Übergang von der alten in die neue Umgebung gewährleisten.
Vertrauen durch ein Proof of Concept schaffen
Alle Technologieentscheidungen waren getroffen. Der Plan für die Zielarchitektur und Infrastruktur stand. Bevor die vollständige Migration allerdings umgesetzt wurde, führten wir ein Proof of Concept durch, um die getroffenen Entscheidungen zu validieren.
In dieser Phase richteten wir die grundlegende AWS-Infrastruktur ein, prüften die erforderlichen Zugriffskanäle und testeten die Fähigkeit von DocumentDB, Produktionsdaten zu verarbeiten.
Der Proof of Concept war entscheidend, um mögliche Herausforderungen frühzeitig zu erkennen. Er zeigte den Bedarf an Feinabstimmung des Migrationsprozesses und bereitete uns auf die Komplexität neuer Technologien vor.
Migration-Day
Dann war es endlich so weit. Der Tag der Migration war gekommen. Zwar hatten wir die Migration zuvor bereits auf Test-Stages verprobt, jedoch noch nie gemeinsam mit den migrierten Produktionsdaten. Zudem war unklar, ob der Wechsel gemeinsam mit allen Umsystemen reibungslos funktioniert.
Wir starteten also mit der Migration und drückten dabei die Daumen: Das alte Produktivsystem wurde heruntergefahren und die neue produktive Infrastruktur hochgefahren. Die containerisierten Services wurden deployt und die Produktionsdaten migriert. Auch die Umsysteme stellten planmäßig auf unsere neue Umgebung um. Das System nahm problemlos seine Arbeit auf. Ein voller Erfolg!
Vielen Dank an die Kollegen von devlix und teems.it, die uns im Rahmen des Projekts und bei der Migrationsarbeit tatkräftig unterstützt haben.
