IT-Budgets werden oft von der Aufrechterhaltung alter Dinge aufgezehrt – allen voran: Legacy-Systeme. Mit den richtigen Strategien und Methoden können allerdings eine Vielzahl von älteren Anwendungen so modernisiert werden, dass sie zukünftig schneller und kostengünstiger wieder auf der Höhe der Zeit sind, sie also leichter von neuen Technologien profitieren können. Fangen Sie damit besser frühzeitig an: denn machen wir uns nichts vor, heute wird die Legacy-Software von morgen entwickelt.

Wir geben Ihnen einen Überblick zu den drei grundlegenden Ansätzen für die kontinuierliche Modernisierung bestehender Anwendungen. Damit diese bereit für den Übergang zu modernen Architekturen sind und als Basis für zukünftige Applikationen dienen können.

Es war einmal.. vor nicht allzu langer Zeit, da wurden Anwendungen in Programmiersprachen kodiert und in ein Format kompiliert, das für bestimmte Prozessoren und Betriebssysteme einmalig war. Diese Applikationen waren in der Regel eigenständig, tendenziell groß und liefen in lokalen Rechenzentren. Jedermann ging davon aus, dass sie lange Lebensspannen haben. Sie wurden unter Einsatz umfangreicher Development-Lifecycle-Methoden entwickelt, mit engen und im Voraus festgelegten Anforderungen sowie langwierigen Entwicklungsplänen. Inzwischen nennt man sie „monolithische Legacy-Systeme“ – also die Dinosaurier der Unternehmensanwendungen. Sie erfüllten einst ihren Zweck, können mit technischen Innovation und neuen Geschäftsanforderungen aber nicht mehr Schritt halten.

Die Entwicklung hat sich gewandelt zu DevOps-Prozessen. Diese lenken die Erstellung von Microservices, welche auf Containern bereitgestellt und in beliebigen Clouds betrieben werden. Damit wurde der Entwicklungsprozess beschleunigt: weg von einer Wasserfall-Methodologie mit direkten Anforderungen und langen Fristen zwischen Spezifikation und Freigabe, hin zu iterativen Methoden mit häufigen Freigaben von neuen Funktionalitäten. Und diese werden nun ergänzt um kooperative DevOps-Praktiken mit automatisierter und kontinuierlicher Integration und Auslieferung. Der Trend in der Anwendungsarchitektur ist die Aufspaltung der Funktionalität in Komponenten. All-In-One-Anwendungen werden in separate Ebenen entkoppelt: Schnittstelle, Logik und Daten. Moderne, Service-orientierte Architekturen ermöglichen die Erstellung von Anwendungen mittels dedizierter Services bis hin zu Microservices und Application Programming Interfaces (APIs), worüber hochspezialisierte Komponenten für andere Anwendungen verfügbar sind.

Die Anwendungsbereitstellung ist dadurch wesentlich flexibler geworden. Applikationen sind nicht mehr eng an die Hardware gebunden und werden gemäß unabhängiger Standards geschrieben, beispielsweise Java Platform Enterprise Edition (Java EE), sodass sie in zahlreichen Hardware-Kombinationen und Betriebssystemen eingesetzt werden können. Virtuelle Maschinen (VMs) und Container ermöglichen außerdem ein einfaches Verpacken und Bereitstellen auf verschiedenen Hosts. Heutzutage ist es üblich, dass Anwendungen auf mehreren Servern in unterschiedlichen Rechenzentren, Private und Public Clouds bereitgestellt werden. Das beschleunigt den Einsatz und verbessert Performance sowie Verfügbarkeit.

Software-Komponenten rund um eine Anwendung werden als „Stack“ bezeichnet. Genauer gesagt beinhaltet ein kompletter Software-Stack die erforderlichen Komponenten für Entwicklung und Bereitstellung einer Anwendung sowie die angewandte Methodologie und Hardware, auf der sie betrieben wird. Unternehmen wollen gern von neuen Cloud-Technologien profitieren und haben teilweise schon moderne Anwendungen implementiert. Gleichzeitig betreiben sie aber meist noch viele herkömmliche „Legacy-Stacks“. Und es stellt sich die Frage, wie man mit diesen Verfahren soll.

Die Modernisierung von Anwendungen hat primär zwei Ziele: Vorhandene Funktionalitäten und Daten möglichst weiterverwenden sowie die Vorteile neuer Prozesse, Produkte und Technologien für alte Anwendungen nutzbar machen.

Bei den folgenden drei Ansätze geht es darum, einerseits die Lebensdauer und Nutzbarkeit bestehender Anwendungen zu verlängern, andererseits eine Änderung des kompletten Portfolios zu vermeiden sowie letztlich Anwendungen und deren Architektur sukzessive zu überarbeiten. In keinem Fall ist das vollständige Neuentwickeln einer Anwendung erforderlich. Selbst monolithische Anwendungen können so von einer Modernisierung profitieren und schrittweise aktualisiert werden.

1. Lift and Shift
   Lifting and Shifting modernisiert die Art und Weise der Verpackung und Bereitstellung. Vorhandene Komponenten werden auf einer modernen Plattform ausgerollt. Ein bekanntes Beispiel ist der Einsatz von Virtualisierung, wobei die Anwendung zusammen mit dem Betriebssystem gepackt und anstatt auf dezidierter Hardware auf einer virtuellen Maschine betrieben wird. Dieser Ansatz führt an sich nicht zu einer Modernisierung der Anwendungsarchitektur. Er bewirkt allerdings, dass Unternehmen eine moderne Plattform nutzen können und einen Zeitpuffer für die spätere Überarbeitung erhalten.
   
   Lift and Shift kann die Performance verbessern, wenn Anwendungen auf aktueller und schnellerer Hardware ausgeführt werden. Die Bereitstellung von Applikationen auf modernen Plattformen wird damit auch flexibler. Darüber hinaus können die Betriebskosten reduziert werden, durch die Ausmusterung alter Server und einem zentralisiertem Management.
   
   So können beispielsweise Anwendungen in VMs oder in Container verpackt und auf einer PaaS-Umgebung (Platform-as-a-Service) in der Cloud ausgeführt werden. Zusätzlich zu den damit einhergehenden Infrastruktur-Vorteilen, können Sie von einer nahtlosen Entwicklunsumgebung mit Automatisierungen profitieren, die Continuous Integration und Continuous Delivery (CI/CD) umfasst.
   
   
2. Erweiterung mit neuen Schichten (Augmentation)
   Die Erweiterung oder Augmentierung mittels neuer Schichten (sog. Layer) ist ein Ansatz, der bestehende Funktionalität für neuen Anwendungen und Kanäle zugänglich macht. Das spart Zeit und Kosten, weil vorhandene und bewährte Funktionen nicht neu entwickelt werden müssen.
   
   Dazu wird eine zusätzliche Anwendungsschicht kreiert, welche bestehende Anwendungen und Daten umhüllt und mit einer Schnittstelle versieht, die dann für neue Applikationen zugänglich ist – eine Art Adapter zwischen alt und neu. Für gewöhnlich müssen Legacy-Anwendungen dazu nicht angepasst werden, was besonders dann hilft, wenn der Quellcode nicht mehr verfügbar ist oder eine Modifizierung zu riskant wäre.
   
   Besonders in Kombination mit Lift and Shift wird die Bereitstellung und Verwaltung bestehender Anwendungen dadurch einfacher und kostengünstiger. Weitere neue Anwendungen und Services können dann auf einer aktuellen Architektur entwickelt werden und dennoch auf bestehende API-Funktionen zurückgreifen. Und mit der Zeit können diese alten Funktionen obsolet werden.
   
   
3. Umschreiben (Rewrite)
   Das Umschreiben kann als Teil einer umfassenden Modernisierungsstrategie die anderen kurzfristigen Ansätze ergänzen, also im Zusammenspiel mit Lift and Shift sowie Augmentation erfolgen. Es ist letztlich der einzige Weg, um die Anwendungsarchitektur für einen modernen Stack zu aktualisieren.
   
   In der Regel ist dies die unattraktivste der drei Optionen, da sie sich erst langfristig rechnet. Dennoch gibt es Fälle, in denen ein Umschreiben die einzige Option ist, beispielsweise bei sehr alten Anwendungen, die auf nicht länger unterstützten Betriebssystemen laufen. Ohne Sicherheits-Updates durch den Hersteller stellen diese Umgebungen ein Sicherheitsrisiko dar. Oftmals fehlen auch schlicht die internen Fähigkeiten für den Weiterbetrieb.
   
   Einzelne Funktionen sollten dann möglichst nach und nach migriert werden statt sofort alles neuzuschreiben. Dabei hilft die Augmentierung mit zusätzlichen Schichten. So wird der Weg für eine schrittweise Modernisierung der Anwendungsarchitektur bereitet und im Laufe der Zeit können alte Programmteile umgeschrieben und ausgemustert werden (das sog. „Strangler Pattern“). Metaphorisch wächst die neue Anwendung über den alten monolithischen Stamm, bis dieser am Ende ganz verschwindet. Kleinere Funktionalitäten werden identifiziert und sukzessive durch Microservices, Applikationsdienste oder Serverless-Funktionalitäten ersetzt.

Welcher Ansatz der richtige ist, hängt von vielen Faktoren ab – der Applikation, dem Unternehmen und dem Kontext. In der Regel erfordert die Modernisierung eine Kombination dieser Methoden. Lift and Shift ist dabei grundsätzlich die günstigste Möglichkeit. Die Augmentierung mit neuen Schichten kann kostspieliger sein, da Entwicklungsaufwand entsteht, ist jedoch schneller umsetzbar als das Umschreiben, welches in jedem Fall die teuerste und zeitaufwändigste Option ist.

Die Aufgabe, ein größeres Anwendungsportfolio zu modernisieren, kann entmutigend sein, insbesondere wenn dieses auf älteren Stacks und überholter Hardware basiert. Aufwand und Kosten zu schätzen ist schwierig. Es ist daher ratsam das Problem aufzuspalten, wenige Anwendungen gleichzeitig zu migrieren und über Teilschritte schneller von den Vorteile neuer Technologien zu profitieren.

Für die Anwendungsentwicklung mit Ihrem eigenen Entwicklerteam, unterstützen wir Sie darüber hinaus gern mit passenden Red Hat Lösungen. Zusammen mit unserem Partner bringen wir Ihnen die Welt der modernen Software-Entwicklung näher und vermitteln die Kultur rund um agile DevOps-Prozesse.

Das Red Hat Portfolio an Middleware-Produkten bietet Entwicklern, Architekten und IT-Leitern moderne Werkzeuge, um Anwendungen zu erstellen, zu integrieren und zu automatisieren. Die Lösungen greifen ineinander und unterstützten die kostengünstige sowie skalierbare Entwicklung, Implementierung und Ausführung von Geschäftsanwendungen. Red Hat Middleware kann lokal, in der Cloud oder innerhalb einer Container-Plattform, wie Red Hat OpenShift, ausgeführt werden.