So modernisieren Sie Apps für die Cloud

Das Thema Anwendungen für die Cloud modernisieren lässt sich aus unterschiedlichen Perspektiven betrachten: Die Benutzer erhoffen sich von der Modernisierung eine bessere Experience, höhere Zuverlässigkeit, bessere Performance und im Idealfall Funktionen, die häufiger bereitgestellt werden.

Architekten, Softwareentwickler und DevOps-Engineers haben wiederum jeweils unterschiedliche Antworten auf die Frage, was Anwendungsmodernisierung bedeutet. Der Grund: Es gibt mehrere technische Ansätze für die App-Modernisierung - und die optimale Wahl ist nicht immer offensichtlich.

Eine Workflow-Anwendung, die von Dutzenden von Benutzern genutzt wird und in den neuesten Versionen von Java und MySQL geschrieben wurde, lässt sich beispielsweise leicht im Lift-and-Shift-Verfahren in die Public Cloud verschieben. Bei diesem Ansatz muss nur wenig Code umgeschrieben werden - wahrscheinlich sind jedoch Konfigurationsänderungen, eine CI/CD-Aktualisierung und Test-Automatisierungen, die noch einmal durchlaufen werden müssen. Läuft dieselbe Anwendung hingegen auf einem Mainframe und ist in Cobol geschrieben, ist die Wahrscheinlichkeit sehr groß, dass sie überarbeitet werden muss, bevor sie in der Cloud läuft.

Es allerdings noch einige Optionen, die zwischen "Lift & Shift" und einer Komplettüberholung liegen. Dieser Artikel betrachtet die wichtigsten App-Modernisierungsoptionen.

App-Modernisierung: Wichtige Faktoren

Unternehmen verfügen oft über Hunderte bis Tausende von Legacy-Applikationen, Anwendungen mit beträchtlichen technischen Schulden und andere, bei denen eine Migration Vorteile für Benutzer oder Unternehmen bringt. Je nachdem, welche geschäftlichen Anforderungen und technischen Herausforderungen dabei anliegen, verwenden Architekten und technische Leiter einen entsprechenden Modernisierungsansatz.

Dabei sollten zunächst die Auswirkungen auf den Geschäftsbetrieb und die Benutzer berücksichtigt werden: Unternehmenskritische Anwendungen mit hohem Nutzungsgrad erfordern andere technische Ansätze als Anwendungen, die episodisch genutzt werden. Jede Modernisierung erfordert die Kommunikation mit den Benutzern, Tests und die Schulung der Mitarbeiter in Bezug auf veränderte Workflows.

CIO's are still use legacy apps like IMS -- and they are more costly, and less rewarding than you might think.

CIOs modernize their applications #portfolio for several reasons: to attract top talent, reduce license and support fees, and improved flexibility and adaptability. pic.twitter.com/VRGLFh13jk

— CIO Tech Talk (@CIOTechTalk) August 5, 2021

Nitha Puthran, Senior Vice President of Cloud and Infrastructure beim Technologiedienstleister Persistent Systems, gibt einen Überblick über einige der Business-Faktoren bei der Auswahl von Ansätzen und Fahrplänen zur App-Modernisierung: "Eine der größten Herausforderungen für Unternehmen besteht darin, zu erkennen und zu wissen, welche Anwendungen in welcher Reihenfolge verschoben, neu strukturiert oder neu geschrieben werden sollten. App-Modernisierung erfordert, eine Balance zwischen Time-to-Market, Skalierbarkeit, Kostenoptimierung, der Minimierung künftiger technischer Schulden und der betrieblichen Ausfallzeit zu finden."

Wie DevOps-Teams von App-Modernisierungen profitieren, erklärt Garth Fort, Chief Product Officer bei Splunk: "Eine Cloud-Migration kann viele Vorteile mit sich bringen, etwa Kostensenkungen, Verbesserungen bei Security und Ausfallsicherheit sowie eine einfachere Skalierung der Servicebereitstellung für Kunden. Für DevOps-Teams kann es die Agilität und Produktivität der Mitarbeiter verbessern, so dass sie sich auf die Customer Experience fokussieren können."

Apps für die Cloud modernisieren: 5 Tipps

DevOps-Teams und -Architekten sollten die geschäftlichen, technischen, betrieblichen und sicherheitsrelevanten Faktoren jeder App prüfen und anschließend folgende Ansätze zur Modernisierung von Apps für die Cloud in Betracht ziehen:

1. Unnützes ausmustern

Haben Sie noch Anwendungen für Modems, Fax-Geräte oder andere veraltete Technologien in Betrieb? Falls ja: Wenn Applikationen Funktionen ausführen, die nicht mehr benötigt werden, gibt es nur eine geeignete Modernisierungsstrategie: sie außer Betrieb zu nehmen.

Die Entscheidung, eine Anwendung stillzulegen, ist manchmal einfach zu fällen - etwa wenn die Anwender dem zustimmen oder das keine geschäftlichen Auswirkungen hat. Werden Anwendungen nur wenig genutzt oder erfüllen eine Geschäftsfunktion, sollte ihr Business-Wert gegenüber den Modernisierungs- und den laufenden Supportkosten abgewogen werden.

"Um die Benutzerfreundlichkeit zu verbessern, sollten Unternehmen die Strategie der Stilllegung in Betracht ziehen. Legacy-Anwendungen abzuschaffen, kann zu mehr Effizienz und damit zu einer besseren Customer Experience führen. Die verringerte Angriffsfläche führt zudem auch zu mehr Sicherheit", argumentiert Amit Patel, Senior Vice President bei Consulting Solutions.

2. Apps ersetzen

Nach Meinung des Splunk-CPO kann es sinnvoll sein, Anwendungen mit SaaS-, kommerziellen oder quelloffenen Alternativen zu ersetzen, wenn proprietäre Lösungen nicht mehr erforderlich sind. "Eine Applikation zu ersetzen bedeutet, dass ein Unternehmen sich nicht mehr auf seine eigenen maßgeschneiderten Anwendungen verlässt, sondern auf vorgefertigte von Drittanbietern umsteigt, die in einer Cloud gehostet werden", erklärt Fort.

Beispiele hierfür sind etwa Tools für das Kundenbeziehungsmanagement, Content-Management-Systeme oder kundenspezifische Workflow-Tools, die entwickelt wurden, als die entsprechenden SaaS-, kommerziellen oder Open-Source-Lösungen die Geschäftsanforderungen nicht erfüllen konnten. Heute finden Geschäftsanwender bei Drittanbietern möglicherweise bessere und billigere Optionen im im Vergleich zu ihrer veralteten, proprietären Lösung.

3. Anwendung in die Cloud verlagern

Applikationen, die die Geschäftsanforderungen unterstützen und auf einem supportfähigen Softwarestack laufen, können möglicherweise verlagert werden. Anstatt diese auf dedizierter Hardware oder virtuellen Maschinen laufen zu lassen, können Architektur- und DevOps-Teams technische und geschäftliche Vorteile durch eine Relokalisierung in Cloud-Umgebungen erzielen. So kann es beispielsweise einfacher sein, Entwicklungs- und Testumgebungen zu konfigurieren, die Produktion automatisch zu skalieren und Disaster-Recovery-Umgebungen zu konfigurieren, wenn die Anwendung in einer Public oder Private Cloud läuft.

Bob Quillin, Chief Ecosystem Officer beim Plattformanbieter vFunction, mahnt jedoch: "Migration ist nicht gleich Modernisierung. Es gibt DevOps-Vorteile, die mit der Lift-and-Shift-Migrationsmethode erzielt werden können. Fast alle Unternehmen erzielen kurzfristige Vorteile - nur machen viele Führungskräfte den Fehler, zu glauben, die Arbeit wäre damit getan."

Eine App Relocation könne zwar Flexibilität in Sachen Infrastruktur sowie Security-Verbesserungen bieten und die Kosten senken, löse aber nicht die Probleme mit dem Support der Anwendung und dem zugrunde liegenden Code, erklärt Quillin. "Ein Monolith in der CloudCloud hat die gleichen Probleme wie On-Premises - langsame Entwicklungsgeschwindigkeit, mangelnde Skalierbarkeit und Schwierigkeiten in Sachen Wartung. Diese Phase wird als 'Lift-and-Shift-Regret' bezeichnet, da die Kosten steigen und die Vorteile der Cloud immer noch unerreichbar sind. Um mit diesem Mythos aufzuräumen, muss die Migration im Kontext einer größeren, strategischeren Modernisierungsstrategie gesehen und geplant werden." Alles zu Cloud Computing auf CIO.de

4. Replatforming für nützliche Komponenten

Viele interpretieren "Lift and Shift" als eine Migrationsoption, die eine minimale Beteiligung des Entwicklungsteams sowie keine Code-Upgrades oder größere Konfigurationsänderungen erfordert. Die Hoffnung liegt dabei darin, von den Vorteilen der Migration profitieren zu können, ohne zusätzlichen Aufwand und Kosten.

Zwischen dem Code und der Infrastruktur befinden sich jedoch Datenbankplattformen, Frameworks und Komponenten - und die Möglichkeit, diese während der Migration zu replizieren. Obwohl für ein Replatforming im Allgemeinen Entwickler erforderlich sind, kann es sein, dass keine wesentlichen Änderungen am Code notwendig sind, insbesondere wenn standardisierte oder nahezu gleichwertige Plattformen in den Stack aufgenommen werden.

Tomer Shiran, Mitbegründer und Chief Product Officer beim Datenspezialisten Dremio, nennt ein Beispiel: "Anstatt ein veraltetes Data Warehouse oder einen Data Lake in die Cloud zu verlagern, bietet eine Cloud-Migration die Möglichkeit, offene Lakehouse-Architekturen und Data-Mesh-Ansätze für die Datenverwaltung zu übernehmen."

Cloud-Architekten können Data Warehouses und Data Lakes modernisieren, um sie als Public-Cloud-Services bereitzustellen, die Betriebs- und Kostenvorteile bieten. Andere Replatforming-Optionen umfassen die Migration von Service-Bussen, die Umstellung auf die Standard-CI/CD-Tools eines Unternehmens oder der Wechsel eines Content Delivery Networks.

5. Wiederverwendung, Refactoring oder Neuaufbau

Wenn sich Architekten und Devops-Teams für ein Code-Upgrade im Rahmen der App-Modernisierung entscheiden, stehen ihnen mehrere Möglichkeiten offen:

• Vorhandene Datenmodelle, Dienste und APIs der Anwendung werden wiederverwendet, das Benutzererlebnis jedoch neu gestaltet.

• Code-Refactoring, um Performance, Sicherheit, Wartbarkeit und andere nichtfunktionale Upgrades zu verbessern.

• Module und Funktionen werden neu aufgebaut, um die Funktionalität zu verbessern, Fehler zu beheben oder technische Schulden zu reduzieren.

"Die Refactor- und Rearchitect-Strategie ist zwar der teuerste Ansatz, sollte aber in Betracht gezogen werden, wenn Unternehmen zu einem agileren DevOps-Modell übergehen wollen", empfiehlt Patel. "Diese Strategie hilft auch bei der kontinuierlichen Innovation und trägt letztlich zur Leistungssteigerung bei."

DevOps-Teams können jedoch auch iterative Ansätze in Betracht ziehen. So können sie beispielsweise zunächst Anwendungen neu hosten, die auf supportfähigen Plattformen laufen, um die betrieblichen Vorteile der Private oder Public Cloud zu nutzen. Anschließend können sie in Betracht ziehen, Applikationen wiederzuverwenden, die nicht häufig aktualisiert werden und andere Anwendungen umgestalten, bei denen ein geschäftlicher Bedarf für häufige Verbesserungen besteht.

Die Modernisierung von Anwendungen ist nicht frei von Kosten und Risiken. Bei Unternehmen mit Tausenden von Anwendungen kann es Jahre dauern, das Portfolio vollständig zu modernisieren. DevOps-Teams und -Architekten sollten alle Faktoren prüfen, bevor sie die Modernisierungsstrategie für eine App auswählen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation InfoWorld.