Neuer Glanz für "betagte" Softwarelösungen: Software-Modernisierung durch Cloud-Migration – Teil 2

Die einfachste und schnellste Variante der Cloud-Migration ist die Rehost-Strategie. Eine Anwendung, die bisher lokal läuft, wird mithilfe von Infrastructure-as-a-Service in eine Cloud-Umgebung gebracht. Der Umzug der Anwendung erfolgt ohne Änderungen am Source Code. Einmal in die Cloud-Umgebung gebracht, braucht man sich nicht mehr um Themen, wie Hardwareausfälle, Verwaltung der Infrastruktur, Anschaffung und Bereitstellung von Hardware und Disaster Recovery zu kümmern. Um diese Dinge kümmert sich dann der Cloud Provider und Sie können sich voll und ganz auf das Wesentliche konzentrieren - die Weiterentwicklung Ihrer Anwendung.

Vorteile

- Keine Code- oder Architekturänderungen

- Anwendungen werden ohne Anwendungs- oder Infrastrukturänderungen in der Cloud neu gehostet, wodurch teure Entwicklungs- und Testkosten entfallen.

Nachteile

- Legacy-Anwendungen sind nicht skalierbar und lassen keine verteilten Arbeitslasten zu, wie dies bei Cloud-nativen Anwendungen der Fall ist.

- Lokale Anwendungen können nach der Migration unter Latenz- oder Performanceproblemen leiden, da sie nicht für die Cloud-Umgebung optimiert oder modifiziert wurden.

Das Ziel von Rearchitect ist, die Softwarearchitektur so anzupassen und so zu optimieren, dass sie perfekt in einer Cloud-Umgebung läuft. Die monolithische Anwendung wird in lose gekoppelte Microservices aufgeteilt, die mithilfe von Containern unabhängig hochskaliert, getestet, ausgetauscht und verwaltet werden können.

Vorteile

- Sie können langfristig Kosten senken, indem Sie den tatsächlichen Ressourcenbedarf mit der Cloud-Infrastruktur abgleichen. Die Fähigkeit zur bedarfsgerechten Skalierung senkt den Ressourcenverbrauch und sorgt für einen nachhaltigen Return On Investment.

- Mit Cloud-nativen- und Microservices-Architekturen können Anwendungen schnell an neue Kundenanforderungen angepasst werden, indem neue Funktionen hinzugefügt oder bestehende Funktionen modifiziert werden.

- Durch die Nutzung von Platform-as-Service-Diensten ist eine erhöhte Ausfallsicherheit garantiert.

Nachteile

- Ein Refactoring ist ressourcen- und kostenintensiver, da es komplexer ist als die Rehost-Strategie.

- Es erfordert fortgeschrittene Kenntnisse des Codes, der Automatisierung und des DevOps Prozesses.

- Ein falsches Refactoring bedeutet, dass evtl. viele Bereiche der Anwendung geändert werden müssen, sodass ein hohes Fehlerrisiko auf Code-, Konfigurations- und Infrastrukturebene besteht. Jeder Fehler kann zu Verzögerungen, erhöhten Kosten und möglichen Ausfällen führen.

Die Replace- Strategie verfolgt den Ansatz, die bestehende Anwendung mit einer auf dem Markt bestehenden Software-as-a-Service-Lösung zu ersetzten.

Vorteile

- Es ist keine Neuentwicklung oder Änderung der bestehenden Anwendung erforderlich.

- Diese Strategie verspricht Zeit- und Kostenersparnis.

Nachteile

- Individuelle Anpassungen sind entweder bedingt oder gar nicht möglich.

- Die Applikation ist nicht individuell nach Ihren Wünschen entwickelt. Daher kann sie entweder weniger Funktionalitäten oder nicht benötigte Funktionalitäten aufweisen.

Im traditionellen Deployment werden die Anwendungen auf physischen Servern ausgeführt. Alle Anwendungen teilen sich das gleiche Betriebssystem und Ressourcen. Alle Abhängigkeiten werden auf dem Betriebssystem installiert, weshalb eine Isolation nur durch weitere Hardware möglich ist.

Als Lösung wurde die Virtualisierung eingeführt. Damit können mehrere virtuelle Maschinen auf der CPU eines einzigen physischen Servers ausgeführt und Anwendungen zwischen Virtuellen Maschinen (VMs) isoliert werden. Virtualisierung schafft die Voraussetzungen für eine effektivere Ausnutzung der Ressourcen in einem physischen Server und bietet eine bessere Skalierbarkeit, da eine Anwendung einfach hinzugefügt oder aktualisiert werden kann. Jede VM ist eine vollständige Maschine, auf der alle Komponenten, einschließlich ihres eigenen Betriebssystems (auf der virtualisierten Hardware) ausgeführt werden.

Container sind ähnlich wie Virtuelle Maschinen aber wesentlich leichtgewichtiger. Ähnlich wie eine VM hat ein Container sein eigenes Dateisystem, einen Anteil an CPU, Speicher und Prozessor. Da sie von der zugrundeliegenden Infrastruktur entkoppelt sind, sind sie portabel. Anders als bei einer VM teilen sich die Container das Betriebssystem.

Durch Container ergeben sich folgende Vorteile:

- Agile Anwendungserstellung und -bereitstellung

- Ressourcenisolierung: vorhersehbare Anwendungsleistung

- Optimale Ressourcennutzung

In einer monolithischen Architektur teilen sich alle Funktionen dieselbe Code-Basis und verwenden dabei dieselbe Technologie. Der Datenzugriff erfolgt über eine zentrale Datenbank. Änderungen an der Anwendung oder neue Funktionen sind kostspielig und schwierig und des Weiteren muss die komplette Anwendung bei Änderungen oder Funktionserweiterungen neu deployed werden.

Im zweiten Schritt wird die monolithische Architektur in eine Microservice Architektur überführt.

Die verschiedenen Funktionen werden in Microservices ausgelagert. Jeder Microservice hat eine unterschiedliche Code-Basis und es können unterschiedliche Technologien zum Einsatz kommen. Jeder Microservice hat dabei seine eigene Datenhaltung und ist für diese ausschließlich verantwortlich. Die Zugriffe auf die Daten erfolgen dabei auch ausschließlich über den Microservice und deren http- Schnittstelle. Änderungen an der Anwendung oder neue Funktionen hinzuzufügen geht schnell und einfach. Bei Änderungen oder Funktionserweiterungen ist nur der jeweilige Microservice betroffen und muss ausgetauscht werden.

Nachdem die Microservice Architektur steht, wird im nächsten Schritt die Anwendung containerisiert.

Die Microservices werden in Container verpackt und deployed. Jeder Microservice wird durch einen POD repräsentiert, der die notwendigen Container enthält, um die Funktionen des Microservices zu realisieren. Kubernetes übernimmt die Orchestrierung der Container und kümmert sich um die Lastverteilung und Wiederherstellung der Container.  Die synchrone Kommunikation von außen erfolgt mittels http z.B. REST API. Die Kommunikation zwischen den Microservices erfolgt in erster Linie asynchron und ereignisbasiert über einen Event Bus. Dadurch werden die Microservices entkoppelt und ihre Autonomie und Unabhängigkeit durch Dezentralisierung der Daten gewährleistet.