So klappt die Anwendungsmigration Vom Desktop in die Cloud – Ein Leitfaden für die Praxis

Von Elena Bochkor und Dr. Veikko Krypczyk*

Der Weg für viele Business-Applikationen führt in die Cloud, oder zumindest in den Browser mit einem lokalen Webserver. Das gilt auch für bestehende Anwendungen, wenn diese im Zuge einer Migrationsstrategie fit für die Zukunft gemacht werden. Analyse, Vorgehensweise und Werkzeuge müssen idealerweise aufeinander abgestimmt werden.

Software-Migration resultiert aus der Notwendigkeit, das Dilemma einer veralteten Softwaretechnologie und den zu hohen Kosten einer Neuentwicklung aufzulösen.
Software-Migration resultiert aus der Notwendigkeit, das Dilemma einer veralteten Softwaretechnologie und den zu hohen Kosten einer Neuentwicklung aufzulösen.
(Bild: Antoine - stock.adobe.com)

Der technologische Wandel im Bereich der Softwarearchitekturen zwingt Unternehmen dazu, regelmäßig Anpassungen und Veränderungen vorzunehmen. Im Bereich der Geschäftsanwendungen können dabei zum Beispiel Desktop-, Web- und Cloudbasierte Architekturmuster in zeitlicher Abfolge unterschieden werden. Web-Applikationen haben die Installation, Bereitstellung und Wartung gegenüber einer lokal installierten Desktop-Anwendung erheblich vereinfacht.

Ein Browser auf den Client-Rechnern der Nutzerinnen und Nutzer genügt und das gesamte Management der Anwendungsstruktur wird zentralisiert über den Server erledigt. Mit dem Übergang in die Cloud gelingt es, diesen Prozess weiter zu vereinfachen. Die notwendige Infrastruktur wird dabei in die (Public) Cloud ausgelagert. Es entfallen die typischen Aufgaben der Hard- und Softwarebereitstellung auf Systemebene.

Auch in Fragen der Datensicherheit (Backup) und der Verfügbarkeit des Dienstes sind die Angebote von Public-Cloud-Providern in der Regel den Möglichkeiten des eigenständigen IT-Hostings überlegen. Cloud-basierte Softwaresysteme können bei Änderungen in den Anforderungen sehr zeitnah auch in einem großen Umfang skalieren. Eine Gegenüberstellung der Gesamtkosten (Hardware, Systemsoftware, Wartung, Personal usw.) gegenüber den nutzungsabhängigen Kosten des Cloud-Dienstes fallen meist zu Gunsten eines Outsourcings der Infrastruktur aus.

Das Unternehmen kann sich dabei in Fragen seiner Digitalstrategie auf die weitere Entwicklung seiner Geschäftsprozesse und der Unterstützung durch Software konzentrieren, statt Ressourcen für die Bereitstellung und den Betrieb der IT-Infrastruktur zu binden. Für neu zu erstellende Anwendungen wird man dabei unmittelbar eine aktuelle Technologie und Softwarearchitektur verwenden und beispielsweise diese direkt so konzipieren, dass sie in der Cloud betrieben werden.

Abb. 1. Anforderungen an eine Business-Applikation.
Abb. 1. Anforderungen an eine Business-Applikation.
(Bild: Krypczyk / Bochkor)

Für bestehende Applikationen gilt es Maßnahmen zur Aktualisierung zu prüfen. Unter dem Stichwort „Cloud-Migration“ versteht man einen Prozess zur Verlagerung von Rechenressourcen, wie Daten, Anwendungen und IT-Prozesse, in eine Cloud-Umgebung. In diesem Fall geht es um eine Software-Migration. Ausgangspunkt sind dabei oft bestehende Anwendungssysteme, zum Beispiel in Form einer Windows-Desktop-Applikation.

Diese sind seit vielen Jahren im Betrieb und haben sich aus fachlicher Perspektive bewährt. Nicht mehr zeitgemäß sind dagegen der Applikationstyp (Desktop, statt Web), die Architektur, die Benutzeroberfläche (Design, Layout, Bedienung) und weitere Aspekte aktueller Softwaretechnologie. Eine vollständige Neuentwicklung ist meist sehr aufwändig, daher sind Migrationsszenarien willkommen.

In diesem Artikel geht es um ausgewählte Aspekte einer solchen Softwaremigration mit dem Ziel, wesentliche Teile dieser Software in die Cloud zu verlagern. Selbst wenn die Applikationen „on Premises“ verbleiben sollen, lassen sich Themen wie Software-Verteilung, Plattformunabhängigkeit und selbst Remote Work durch webbasierte Anwendungen, die im Browser laufen, vereinfachen.

Die Business Web-Applikation

Viele Business-Anwendungen stellen an den Entwicklungsprozess typische und damit vergleichbare Anforderungen. Diese Anforderungen (Abb. 1 und Tabelle) sind in einem möglichen Softwaremigrationsprozess zu berücksichtigen.

Anforderungen Ist-Zustand (Desktop-Anwendung) Ziel der Software-Migration (in der Cloud gehostete Web-Applikation)
Dialogfelder Zahlreiche Formulare und komplexe Dialogmasken für die Erfassung einer Vielzahl von Einzeldaten sind typisch für Geschäftsanwendungen. Es sollte gelingen ein Großteil dieser Formulare automatisch zu migrieren, um diese nicht komplett neu erstellen zu müssen.
Datenbanken Nutzung diverser, meist SQL-basierte Datenbanken. Die Ebene der Datenbanken sollte bei einer Migration des Frontend (Client-Applikation) nicht betroffen sein.
Businesslogik Diese ist oft komplex und wurde im Laufe des Lebenszyklus der Anwendung angepasst und weiterentwickelt. Weitgehende Übernahme der Programmlogik, zum Beispiel Berechnungen, Prüfalgorithmen usw.
Entwicklungszyklus Zum Einsatz kamen oft integrierte Entwicklungsumgebungen wie Visual Studio. Das User Interface wird meist in einem grafischen Designer und komponentenbasiert erstellt, zum Beispiel mit Windows Forms. Dieser ist so zu gestalten, dass die Time-To-Market minimiert wird. Die Softwaremigration muss mit einem vertretbaren Zeit- und Ressourcenaufwand realisierbar sein.
Deployment Installation und Wartung sind i.d.R. aufwändig und müssen manuell auf den Client-PC vorgenommen werden. Daher ist der Prozess oft fehleranfällig und verursacht hohe Wartungskosten. Die Verteilung der Applikationen erfolgt zentral über einen in der Cloud gehosteten Server. Der Wartungsaufwand wird minimiert, d.h. häufige Updates sind ohne Eingriffe der Nutzerinnen und Nutzer umsetzbar.
User Experience Die Anwendung ist oft in Fragen des Designs und der Bedienung nicht mehr zeitgemäß (Stichwort: „graue Formulare“). Man setzt heute auf visuell attraktive Steuerelemente, welche die Erfassung der Daten oder die Auswahl von Optionen vereinfachen. Das Farbschema, Schriftarten und Schriftgrößen der Anwendung müssen individuell abgestimmt werden. Die gesamte Gestaltung muss eine responsive Darstellung auf Geräten mit unterschiedlichen Bildschirmen ermöglichen. Die User Experience muss eine Barrierefreiheit der Anwendung auf allen Ebenen sicherstellen.

Web-Migration

Um eine bestehende Desktop-Applikation in eine Web-Anwendung zu transformieren, muss als erstes eine sorgfältige Analyse der bestehenden Legacy-Applikation durchgeführt werden. Entscheidende Faktoren sind beispielsweise Programmiersprache, Framework, Entwicklungsumgebung, verwendete Bibliotheken usw.

Viele Desktop-Applikationen wurden historisch häufig ausschließlich für das Betriebssystem Windows entwickelt. Dabei kam sehr oft die Grafikschnittstelle Windows Forms zum Einsatz, welches ein Erstellen des User Interfaces im grafischen Designer von Visual Studio erlaubt. Programmiert wurde mit Visual Basic .NET oder C#. Genutzt wurde dabei das .NET-Framework als universelle Klassenbibliothek. Diese Art von Applikationen sind aus heutiger Sicht technologisch, in Fragen der User Experience und der Softwarearchitektur veraltet.

Software-Migration kann nur dann funktionieren, wenn es gelingt, relevante Bestandteile der bestehenden Software zu transformieren. Der Kernbestandteil dieser Art von Applikationen ist die Nutzung des .NET-Frameworks, d.h. die Algorithmen verwenden die Klassen und APIs dieses Frameworks. Es gilt zu prüfen, welche Möglichkeiten es gibt, um .NET-basierte Anwendungen vom Applikationstyp einer Desktop-Anwendung in eine Web-Anwendung zu überführen. Aktuell sind dazu zwei relevante Ansätze auf dem Markt: Blazor Web-Applikationen und Wisej.NET. Beide Technologien sollen nachfolgend kurz skizziert werden.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Abb. 2. Hosting-Modelle Blazor-Server und Blazor WebAssembly.
Abb. 2. Hosting-Modelle Blazor-Server und Blazor WebAssembly.
(Bild: Microsoft)

Blazor ist ein Open Source Framework von Microsoft, um Web-Applikationen mit .NET-Technologie zu erstellen. Das Framework ist primär – als Alternative zu den JavaScript-Frameworks – auf das Erstellen von neuen Anwendungen ausgerichtet. Da jedoch serverseitig gegen das .NET-Framework programmiert wird, kann man es auch einsetzen, um Teile einer bestehen .NET-Anwendung zu migrieren. Das betrifft die Businesslogik der Software. Für eine Web-Applikation auf der Basis von Blazor gibt es zwei unterschiedliche Hosting-Modelle: Blazor Server und Blazor WebAssembly (siehe Abb. 2).

Beim Hosting-Modell Blazor Server wird auf dem Server eine Single Page Applikation (SPA) gerändert und diese wird an den Client ausgeliefert. Zum Client werden JavaScript und Markup gesendet und die Daten und Benutzereingaben laufend mittels der Bibliothek SignalR zwischen Client und Server ausgetauscht. Die Vorteile sind eine geringe Downloadgröße und damit ein schneller Start der Anwendung, eine hohe Kompatibilität auf Clientseite und eine sichere Codeausführung auf dem Server. Als Nachteil ist eine größere Netzwerklast durch einen permanenten Datenaustausch zwischen Client und Server zu nennen.

Apps auf der Basis von Blazor WebAssembly werden dagegen auf dem Client ausgeführt. Die Blazor-App, die jeweiligen Abhängigkeiten und die .NET-Runtime werden dazu initial vom Server heruntergeladen. Da der gesamte Code direkt im Client läuft, kann die Applikation gut skalieren. Jedoch ist der initiale Download groß, was zu einer längeren Startzeit führt. Danach läuft die App performanter.

Blazor Apps basieren final auf HTML, CSS und JavaScript. Programmiert wird jedoch in C# (Business Logik) und der Razor-Syntax (User Interface und Datenbindung). Der Razor-Code ist eine Markup Syntax zum Einbetten von C#-Code in HTML. Diese Vorgehensweise macht es möglich, dass man den üblicherweise statischen Code von HTML dynamisiert.

Das Vorgehen hat jedoch auch Nachteile und Grenzen. Aus Sicht der Architektur der App kann die „Vermischung“ von HTML und C# (Razor-Syntax) schnell undurchsichtig werden. Die Wartbarkeit in großen Softwaresystemen kann darunter leiden. Zwar basiert Blazor auf einer konsequenten Anwendung von Komponenten zum Erstellen des User Interfaces. Einen grafischen Designer gibt es jedoch nicht. Die Benutzeroberfläche muss manuell im Quellcode erstellt werden. Eine Hilfe bietet das Feature Hot Reload. Damit kann die Oberfläche während der Ausführung über Anpassungen im Quellcode verändert werden. Werden Funktionen nicht unmittelbar durch das Blazor-Framework abgedeckt, dann kann man JavaScript-Funktionen adressieren. Wird dieses jedoch zu häufig notwendig, dann verkompliziert man den Entwicklungsprozess und der Vorteil in der Vereinfachung der Entwicklung durch Blazor sinkt dann schnell wieder. Für Softwaremigrationen ist der Ansatz auf eine Transformation des Quellcodes zur Businesslogik begrenzt. Die Benutzeroberfläche einer bestehenden .NET basierten Desktop-Anwendung kann nicht migriert werden. Diese muss man komplett neu erstellen auch die Programmlogik verändert anbinden (Data Binding).

Abb. 3. Architektur von Wisej.NET.
Abb. 3. Architektur von Wisej.NET.
(Bild: wisej.com)

Die Idee, Web-Applikationen mit .NET als Technologie zu kombinieren, verfolgt auch das Framework Wisej.NET. Dieses eignet sich besonders für die Migration von Windows Form-Anwendungen zu Web-Applikationen. Es kann jedoch auch für Neuentwicklungen verwendet werden. Das Framework integriert sich nach der Installation direkt in Visual Studio. Es bietet einen grafischen Designer zum Erstellen der Benutzeroberflächen. Das Vorgehen ist dem Handling bei einer Windows Forms-Anwendung nahezu identisch.

Das Entscheidende erfolgt im Hintergrund: Auf dem Server wird die .NET-Anwendung ausgeführt. Die Basis für das User Interface bilden dabei visuelle Controls. Diese werden als .NET-Komponenten zur Designzeit im grafischen Designer erstellt und konfiguriert. Die Komponenten werden im Client, d.h. im Browser 1:1 in Form von JavaScript-Klassen mit Hilfe der Bibliothek qooxdoo oder anderer Komponentenbibliotheken wie DevExtreme, Syncfusion EJ2 oder Kendo UI abgebildet. Auf diese Weise entsteht ein visuelles Abbild der Applikation im Browser zur Laufzeit auf der Basis von JavaScript, welche zuvor zur Designzeit in .NET implementiert wird. Zwischen Server und Client findet ein optimierter Datenaustausch auf der Basis von Ajax-Anfragen und JSON-basierten Antworten statt (Abb. 3).

Updates am Client, zum Beispiel aufgrund von Anforderungen zur Änderung der Benutzeroberfläche, werden auf diese Weise sehr effizient und performant realisiert. Ein großer Benefit dieses Ansatzes liegt in der Effizienz der Gestaltung des User Interface:

  • Mittels des grafischen Designers können die passenden Steuerelemente aus der Palette entnommen und auf dem Formular platziert werden. Über Eigenschaften wird das Layout und das Design konfiguriert. Für Web-Applikationen ist diese Vorgehensweise aus Sicht der Entwicklung eine Sonderstellung. Es beschleunigt den Prozess zur Erstellung des User Interfaces erheblich.
  • Bei der Migration einer bestehenden Anwendung aus Windows Forms wird ein Großteil der Steuerelemente automatisch in die neue Technologie überführt. Das gilt für alle Standard-Controls für eine bestehende Windows Forms-Anwendung. Controls von Drittanbietern müssen ersetzt werden. Dazu bietet Wisej.NET eine umfassende Palette an modernen Controls. Diese Auswahl kann um weitere Controls von Drittanbietern oder JavaScript-Steuerelementen erweitert werden.
  • Das Look & Feel aller in Wisej.NET verwendeten Controls ist modern und entspricht den Anforderungen einer zeitgemäßen Web-Applikation. Migriert man eine bestehende Windows Forms-Anwendung profitiert diese automatisch von einem umfassenden Design-Facelift (Abb. 4).
  • Das Design der App und der einzelnen Steuerelemente kann gemeinsam (Theming) oder einzeln nach den individuellen Vorgaben, zum Beispiel gemäß einem Corporate Design des Unternehmens, angepasst werden. Das kann toolgestützt erfolgen, d.h. ein manuelles Editieren von CSS-Dateien ist nicht notwendig.

Bei der Migration von Anwendungen geht es um die Transformation aller Bestandteile des Softwaresystems. Beim Wechsel von einer Desktop- zu einer Web-Anwendung sind u.a. Lösungen für folgende Features zu erarbeiten:

  • Mehrbenutzerbetrieb: Web-Applikationen sind von Hause aus auf einem Betrieb für mehrere Nutzer ausgelegt, ggf. muss eine Account-Verwaltung in die Software integriert werden.
  • Nutzung lokaler Hardware und Schnittstellen: Bisher lief die Applikation lokal auf dem Windows-Rechner. Nunmehr wird diese auf dem Server ausgeführt und der Client greift auf diesen über den Browser zu. Für die mögliche Ansteuerung von Hardware und Schnittstellen sind individuelle Lösungen zu erarbeiten.
  • Features: Bei einer Softwaremigration werden üblicherweise auch neue Feature in die Anwendung integriert und nicht mehr benötigte Funktionen entfernt. Dieser Vorgang ist jedoch vom eigentlichen Vorgang der Migration zu trennen.
  • Architektur-Anpassungen: Für .NET-Applikationen hat eine umfassende Erneuerung des Frameworks stattgefunden. Das bisher eingesetzte .NET-Framework bis Version 4.8 war auf das Betriebssystem Windows begrenzt. Ab Version .NET 5 (ehemals .NET Core) handelt es sich um ein plattformübergreifendes Framework. Bestehende Applikationen sollten daher auch in das neue .NET-Framework überführt werden. Wisej.NET unterstützt beide Varianten. Bis NET 4.8 ist man an eine Installation auf einem IIS-Server unter Windows gebunden. Bei Nutzung von .NET 6.0 und höher kann die Applikation ebenfalls auf Linux-Servern installiert werden. Es ergeben sich neue und vereinfachte Optionen zur Bereitstellung, die wir am Ende des Artikels noch vorstellen.

Abb. 4. Die Migration zur Web-App führt schon an sich zu einem umfassenden Redesign.
Abb. 4. Die Migration zur Web-App führt schon an sich zu einem umfassenden Redesign.
(Bild: Krypczyk / Bochkor)

Eine Web-Applikation ist von Hause aus flexibel in der Bereitstellung. Wie diese als Cloud-Applikation verfügbar gemacht werden kann, wird im kommenden Abschnitt dargestellt.

Cloud-Migration

Web-Applikationen können auf Servern bereitgestellt werden, welche in Eigenregie betrieben werden. Eine Alternative ist die Nutzung eines Public-Cloud-Services. Optionen sind beispielsweise AWS (Amazon) oder Azure (Microsoft). Dabei basiert der gesamte Betrieb der Applikation auf einer neuen Architektur. Nachfolgend wird das Deployment über Microsoft Azure vorgestellt.

Abb. 5. Der Webserver ist mit wenigen Schritten vollständig als Web-App in Azure konfiguriert.
Abb. 5. Der Webserver ist mit wenigen Schritten vollständig als Web-App in Azure konfiguriert.
(Bild: Krypczyk / Bochkor)

Damit besteht eine besonders effiziente Möglichkeit die Bereitstellung einer Web-Applikation direkt aus Visual Studio vorzunehmen. Mittels Continuous Deployment kann direkt nach einem erfolgreichen Build aus der Entwicklungsumgebung Visual Studio die Verteilung der App – in diesem Fall zum Service von Azure – vorgenommen werden. In Azure wird dazu der Service Web-App konfiguriert (Abb. 5).

Eine wichtige technische Einstellung ist der Runtimestapel. Da .NET 6 plattformübergreifend arbeitet, können als Betriebssystem sowohl Windows als auch Linux gewählt werden. Ist die betreffende Applikation noch nicht auf das neue .NET-Framework umgestellt, muss man hier die .NET-Framework Version 4.8 einsetzen und zwingend ein Windows System in Azure konfigurieren. Basiskonfigurationen zur App (Name, Domain, Zertifikat, Region, Serviceplan von Azure) müssen festgelegt werden. Danach kann die Ressource im Azure Portal erstellt werden. Mittels eines Veröffentlichungsprofils wird die Web-Applikation direkt aus Visual Studio in Azure bereitgestellt. Die Applikation läuft dann auf dem Server von Azure und ist über das Internet über jeden beliebigen Browser zu erreichen. Die Architektur der App ist in Abbildung 6 skizziert.

Abb. 6. Architektur des in die Cloud migrierten Softwaresystems.
Abb. 6. Architektur des in die Cloud migrierten Softwaresystems.
(Bild: Krypczyk / Bochkor)

Auf Seiten des Clients ist man durch den Einsatz einer Web-App flexibel und kann nahezu jedes Endgerät nutzen. Für besondere Anforderungen mobiler Applikationen, zum Beispiel einen Zugriff auf Sensoren und Gerätefunktionen, gibt es Wisej.NET Mobile. Hierbei handelt es sich um eine native App für iOS bzw. Android, welche der Web-App einen erweiterten Zugriff auf die gesamten Funktionen des mobilen Gerätes erlaubt. Sämtliche Infrastruktur, d.h. Hard- und Software werden über die Public-Cloud verfügbar gemacht. Das betrifft sowohl das Hosting des Servers inklusive der Frameworks .NET und Wisej.NET als auch beispielsweise die Datenbanken, welche ebenfalls in Azure abgebildet und betrieben werden können.

Geplant ist eine Hybrid-Version, die mittels Integration mit .NET MAUI einen Offline-Betrieb von Wisej.NET-Apps auf allen gängigen Plattformen ermöglichen wird, inklusive Zugriff auf lokale Geräte-Schnittstellen.

Fazit

Software-Migration resultiert aus der Notwendigkeit, das Dilemma einer veralteten Softwaretechnologie und den zu hohen Kosten einer Neuentwicklung aufzulösen. Für einen Großteil von bestehenden Legacy-Applikationen kann dieses erfolgreich und mit einem vertretbaren Aufwand realisiert werden. Der Artikel hat es konzeptionell anhand von .NET-basierten Applikationen auf der Basis von Windows Forms beschrieben. Das Ergebnis sind moderne Web-Applikationen, welche den aktuellen Anforderungen in Funktion und Design entsprechen und vollständig in der Cloud betrieben werden können.

* Über die Autoren
Elena Bochkor arbeitet am Entwurf und Design von Anwendungen und Webseiten. Dr. Veikko Krypczyk ist Softwareentwickler, Trainer und Fachautor und u.a. auf die Themen .NET, WinUI 3, .NET MAUI und Softwaremigration spezialisiert. Trainings und Workshops zu diesen und anderen Themen können Sie unter diesem Link anfragen und die Agenda vorab einsehen.

Bildquelle: Larinet

Artikelfiles und Artikellinks

(ID:49426357)