Seite 2 - Möglichkeiten und Stolpersteine beim Replatforming

Lesezeit
3 Minuten
Bis jetzt gelesen

Seite 2 - Möglichkeiten und Stolpersteine beim Replatforming

23.03.2022 - 14:00
Veröffentlicht in:
Schritt 1: Priorisierung und Evaluation
Natürlich spiegelt ein solches Szenario nicht immer den Geschäftsalltag wider. Sauberes, schrittweises Vorgehen kostet viel Zeit und kollidiert oft mit ambitionierten Go-to-Market-Vorstellungen. Aus diesem Grund sind größere Replatforming-Maßnahmen keine Seltenheit. Nichtsdestotrotz gilt es, auch hier priorisiert und systematisch vorzugehen. Dazu zählt im ersten Schritt, kritische Problempunkte der Infrastruktur zu identifizieren: Handelt es sich um das eingangs beschriebene End-of-Life-Problem, sprich sind keine Updates zur Sicherstellung des reibungsfreien Betriebs mehr möglich? Oder geht es vielmehr darum, dass das System aus technologischer Sicht nicht mehr guten Gewissens zu verantworten ist?

Der Antwort auf diese Fragen folgt eine Evaluation der technischen Optionen: Wie lässt sich die bestehende Infrastruktur sinnvoll modernisieren und erweitern, damit sie nicht nur den Business-Anforderungen genügt, sondern stabil und sicher läuft? Gleichzeitig spielen die Kosten eine Rolle. Bestimmte Kernkomponenten wie ERP-Systeme sind in der Regel kostspielig und basieren auf Lizenzen mit entsprechenden Laufzeiten. Ein Parallelbetrieb ist hier ökonomisch nicht sinnvoll. Daraus ergibt sich eine Quadratur des Kreises: Es geht nicht schnell, günstig und gleichzeitig einfach. Die Priorität ist daher entscheidend und die IT-Administration sollte in diesen Prozess stets involviert werden.

Schritt 2: Konnektivität und Datenmigration prüfen
Ist die Entscheidung hinsichtlich der zu adaptierenden Komponenten gefallen, geht es an die Umsetzung. Hierbei ist zunächst die Anbindungsfrage hinsichtlich der Komponente zu klären: Handelt es sich um eine API-Integration? In dem Fall erleichtert sich die Anbindung deutlich, da sich bestehende Schnittstellen nutzen lassen, um die Systeme zu verbinden. Dabei ist lediglich sicherzustellen, dass die Komponente sauber mit der API kommuniziert. Ist das gewährleistet, lässt sich die alte Komponente ab- und die neue zuschalten.

Dieser Fall betrifft jedoch nur Anwendungen, die keine umfassende Datengrundlage benötigen. Im Fall eines E-Commerce-Systems etwa ist zusätzlich die Datenmigration vorzubereiten, da sonst schnell ein Leck in der Datenkonsistenz entsteht. Je nach Größe des E-Commerce-Systems werden diverse Daten im Millisekundentakt aktualisiert oder kommen hinzu. Hier einen "Freeze" durchzuführen, bedeutet im Zweifelsfall später, mit veralteten Daten weiterzuarbeiten. Daher empfiehlt sich ein Parallelbetrieb der neuen und alten Komponente für eine gewisse Zeit. Das neue System läuft im Hintergrund mit und sobald es ausreichend getestet wurde, wird das alte System abgeschaltet. Dieses Vorgehen ist nicht unüblich, denn es beinhaltet einen gewissen Fallback-Plan dar.

Schritt 3: Deployment und Testing
Mit Blick auf das Deployment im Zuge eines Replatformings empfiehlt sich ebenfalls ein behutsames Vorgehen. In den letzten Jahren – getrieben durch Best Practices in Continuous Integration und Deployment (CI/CD) – war dafür das sogenannte "Blue/Green-Deployment" durchaus beliebt: Auf einem skalierbaren System wird dafür erst nur ein kleiner prozentualer Anteil der Server mit der neuen Komponente bespielt und geprüft, ob etwaige Fehler auftreten. Ist das der Fall, kommt das alte System wieder ins Spiel. Läuft es problemlos, weitet sich die Verteilung sukzessive aus, bis die neue Komponente vollständig ausgerollt ist.

Dieser Ansatz ist jedoch nur in bestimmten Szenarien nutzbar, denn er erfordert spezifische Infrastrukturkapazitäten und auch Applikationen, die ein solches Vorgehen erlauben. Alternativ dazu können Unternehmen zu "Rolling Deployments" oder "Phased Rollouts" greifen. Diese Varianten machen in der Regel weniger technische Schwierigkeiten und erlauben (im Fall von Rolling Deployments) die Rückwärtskompatibilität.

Wichtig ist dafür jedoch, dass der verwendete Loadbalancer Benutzerpersistenz unterstützt, damit der dedizierte Nutzer-Traffic stets an denselben Server geht. Denn die Persistenz der Sitzungen kann bei Rolling Deployments zum Problem werden, wenn der Datenverkehr eines Anwenders an einen Server läuft, der eine andere Version der Software ausführt.

Nun gibt es aber Szenarien, in denen aus unterschiedlichen Gründen kein Parallelbetrieb möglich ist. Um hier ein möglichst reibungsfreies Replatforming umzusetzen, ist ein klassischen "Staging" unumgänglich. Wichtig ist hier eine gute Testabdeckung mit durchdachten Testszenarien und möglichst hoher Testautomatisierung. Die zwei geläufigsten Ansätze für das Testing lauten "Test Driven Development" (TDD), sprich es wird erst das Testszenario geschrieben und dann der Code, und "Test After Development" (TAD). Hier wird der Test erst nach der Entwicklung beziehungsweise Implementierung geschrieben.

Nachdem das Replatforming wie eingangs beschrieben in der Regel mit neuen Features einhergeht, gilt es zudem, Tests auf unterschiedlichen Ebenen durchzuführen, etwa Unit-Tests, Integrationstests oder auch Ende-zu-Ende-Tests. Unabhängig davon, welcher Ansatz Verwendung findet: Letztlich basiert der Erfolg sämtlicher Tools, auch zur automatischen Aktualisierung von Komponenten, auf einem soliden Testing-Ansatz.

Automatisierte Unterstützung in der Qualitätssicherung
Damit kommen wir zum letzten Schritt, der Fehlerbehebung. Hierbei gilt es sicherzustellen, dass die neuen Komponenten dauerhaft zusammenarbeiten. Nachdem in modernen Systemen unzählige Komponenten miteinander sprechen sollen, ist eine manuelle Aktualisierung kaum mehr zeitgemäß. Doch es gibt eine Vielzahl von Werkzeugen, um diesen Prozess zu automatisieren. Egal ob für PHP, npm oder Docker-Images: Kostenlose Tools wie "Renovate Bot" melden automatisch, wenn es Updates für bestimmte Komponenten gibt, prüfen diese gegen die Pipeline und spielen sie gegebenenfalls automatisch ein.

Hier zeigt sich nochmals deutlich, warum die Testabdeckung so wichtig ist: Sind keine Tests definiert, finden Updates kontinuierlich statt, ohne dass deren reibungsfreie Funktion sichergestellt wird. In Verbindung mit hoher Testabdeckung und Vertrauen in das eigene Continuous-Integration-Werkzeug lassen sich regelmäßig automatisierte Updates vornehmen, komplett ohne manuellen Aufwand. Somit werden IT-Administratoren entlastet und können sich um wichtigere Aufgaben in der Qualitätssicherung kümmern.

Fazit
Das Aufgabenspektrum von Administratoren wächst mit zunehmender Komplexität von IT-Systemen. Da scheint es zunächst nicht intuitiv, Replatforming-Überlegungen zusätzlich auf die To-Do-Liste zu packen. Doch indem fehleranfällige Systeme durch neue ersetzt werden, lassen sich alte Schwachstellen beheben, was den Verwaltungsaufwand insgesamt reduziert. Admins können diesen Prozess unterstützen, indem sie einen strukturierten Übergang ermöglichen, intelligent priorisieren und immer wieder bestehende Prozesse und Funktionen auf den Prüfstand stellen. Denn eines ist sicher: Jedes System ist irgendwann veraltet. Anstelle eines umfangreichen Replatformings alle paar Jahre sollten Unternehmen aber dazu übergehen, ihre Infrastruktur so zu gestalten, dass fortlaufender Austausch und Optimierung von Komponenten möglich sind.

Seite 1: Replatforming richtig angehen
Seite 2: Evaluation, Konnektivität, Testing


<< Vorherige Seite Seite 2 von 2


ln/Bernd Alter, Technical Director bei Turbine Kreuzberg

Ähnliche Beiträge

Im Test: Heimdal Patch & Asset Management

Ein zeitgemäßes Patchmanagement darf sich angesichts der vielfältigen Bedrohungen nicht allein auf die Microsoft-Produkte konzentrieren, sondern muss sich auch verbreiteten Drittanbieteranwendungen widmen. Der dänische Anbieter Heimdal Security geht noch einen Schritt weiter und hat eine ganze Suite zum Schutz vor Cyberbedrohungen im Programm. Mit dem Fokus auf das Patchen haben wir uns das cloudbasierte Angebot genauer angesehen.

Device-Management mit Microsoft Intune und Office 365 - Zwei Wege, ein Ziel

Um Geräte im Netzwerk oder mobile Geräte, die auf das Netzwerk zugreifen, zu verwalten, bietet sich für Unternehmen entweder Office 365 Mobile Device Management oder Microsoft Intune an. Ein Unterschied zwischen den beiden Lösungen besteht vor allem im Preis. Während das Device-Management zu vielen Abonnements in Office 365 gehört, muss Microsoft Intune gesondert abonniert werden. In diesem Beitrag stellen wir beide Ansätze vor.