Allgemeines zu Cloud-Migration

In die Jahre gekommene Softwareapplikationen wurden meist mit einer Architektur entwickelt, die wir fachsprachlich als Monolithen bezeichnen. Monolithen zeichnen sich durch schwere Wartbarkeit und veraltete Technologien aus. Zudem ist ihre Anpassung sehr kostspielig.

Oft sind diese alten Softwareapplikationen aber unverzichtbar und verursachen so eine Zwickmühle. Zum einen möchte man wenig Risiko eingehen, gemäß dem Prinzip "never change a running system", doch gleichzeitig möchte man wettbewerbsfähig bleiben und nicht den Anschluss verlieren. Die Cloud-Migration kann viele Vorteile mit sich bringen, wie einfachere Skalierbarkeit, höhere Zuverlässigkeit, schnellere Leistung und Reduzierung der Betriebskosten.

Doch was genau ist eine Cloud-Migration?

Unter Cloud-Migration versteht man den Prozess der Verlagerung einer Anwendung in die Cloud. Dabei stehen Ihnen fünf Strategien zur Verfügung, die erstmals 2011 im Gartners "5 Rs"-Modell definiert wurden. Rehost (Lift & Shift), Refactor, Rearchitect, Rebuild und Replace.

Migration Roadmap & Strategy

Doch wann lohnt sich eine Cloud-Migration und welches ist die optimale Strategie für Ihren Anwendungsfall? Der erste Schritt ist die Entwicklung einer Migrationsstrategie. Jede Software ist unterschiedlich und es gibt nicht "die eine" Migrationsstrategie, die für alle Applikationen angewendet werden kann. Schauen wir uns die unterschiedlichen Cloud-Migrationsstrategien näher im Detail an und welche Vor- oder Nachteile sie mit sich bringen.

Rehost

Icon: Rehost

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.

Refactor

Bei Refactor wird der Code der Anwendung soweit angepasst, dass Platform-as-a-Service Dienste verwendet werden können. Der größte Teil der Anwendungslogik bleibt unberührt.

Vorteile

- Dieser Ansatz spart Kosten und erfordert oftmals kein großes Entwicklungsprojekt.

- Fangen Sie klein an und skalieren Sie nach Bedarf. Durch die Plattformumstellung können Sie einige Arbeitslasten in die Cloud verlagern, mit der Cloud-Umgebung experimentieren, Lehren ziehen und dann zu anderen Arbeitslasten übergehen, ohne einen großen Migrationsaufwand in Kauf nehmen zu müssen.

- Sie können Cloud-native Funktionalitäten nutzen, wie automatische Skalierung, verwaltete Speicher- und Datenverarbeitungsdienste, Infrastructure-as-Code und vieles mehr.

Nachteile

- Um den Arbeitsaufwand zu minimieren, müssen Sie sich an gängige, gut bekannte Cloud-Komponenten halten. Spezialisierte Komponenten erfordern oft dramatische Änderungen an der Anwendung und lohnen sich unter Umständen nur dann, wenn sie einen hohen geschäftlichen Nutzen bieten oder eine Nutzung unvermeidlich ist.

- Sie müssen in eine grundlegende Automatisierung investieren, die ein gewisses Maß an Flexibilität beim Betrieb des Systems in der Cloud bietet.

Icon: Refactor

Rearchitect

Icon: Rearchitect

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.

Rebuild

Rebuild ist die Neuentwicklung der bestehenden Softwareapplikation als Cloud-native-Lösung. Sie ist die kosten- und zeitintensivste Migrationsstrategie – allerdings aber auch die mit Abstand beste, wenn es um die Ausnutzung aller Vorteile von Cloud-Computing geht.

Vorteile

- Eine Cloud-native Lösung bietet Agilität, Skalierbarkeit, Zuverlässigkeit und bedarfsgerechte Ressourcen Nutzung.

- Es bietet optimale Bedingungen für die Umsetzung eines DevOps-Prozesses.

- Softwareupdates können wöchentlich, täglich, stündlich oder sogar nach abgeschlossener Funktion erfolgen.

- Veraltete Technologien werden durch neue und moderne Technologien ersetzt.

- Die neue Applikation bekommt nur die Funktionen, die sie tatsächlich benötigt.

Nachteile

- Im Vergleich zu den anderen ist das Rebuild die Kosten- und zeitintensivste Strategie.

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

Icon: Rebuild

Replace

Icon: Replace

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.

Mixed

Ein sehr beliebtes Verfahren ist die Rebuild/Rearchitect- und die Rehost- Strategie zu kombinieren. Das Rebuild/Reachitect erfolgt hier schrittweise, nachdem die alte Anwendung mit der Rehost-Strategie in die Cloud gebracht wurde. Es besteht eine Koexistenz der alten Anwendung und den neuen Microservices, die nach und nach Funktionen der alten Anwendung ersetzen. Die alte Anwendung bleibt dabei unberührt. Erfolgt eine Benutzeranfrage kann entweder auf das Altsystem weitergeleitet werden oder auf den neuen Microservice. Nachdem alle Komponenten aus der alten Anwendung als Microservices implementiert wurden, kann die alte Anwendung abgeschaltet werden.

Icon: Mixed

Software Modernisierung am Beispiel der Rearchitect-Strategie

Aufgrund der genannten Vorteile ist der Rearchitect Ansatz ein guter Mittelweg, um eine gewachsene Software besser zu strukturieren. Deshalb gehen wir anhand eines fiktiven Beispiels genauer auf diese Vorgehensweise ein.

Dafür ist zunächst ein grundlegendes Verständnis für Container und deren Orchestrierung notwendig, die im weiteren Verlauf des Artikels näher betrachtet werden.

Traditionell vs. virtualisiert vs. containerisiert

Graphic: Traditional

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.

Graphic: Virtualized

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.

Graphic: Containerized

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

Orchestrierung von Containern mit Kubernetes

Container können die Arbeit bereits deutlich erleichtern, indem die Anwendung durch das Starten weiterer Container skaliert oder bei einem Fehler neugestartet werden kann. Diese Schritte müssen jedoch manuell durchgeführt werden. Oftmals besteht eine Anwendung außerdem aus verschiedenen, voneinander abhängigen Containern, die miteinander verknüpft werden müssen. Um diese Arbeit zu erleichtern, wird eine zusätzliche Plattform benötigt, die sich um die Verbindungen der Container kümmert, automatisch die Skalierung anpassen kann oder fehlerhafte Container neu startet. Dies wird auch als Container Orchestrierung bezeichnet.

Die bekannteste Container-Orchestrierungstechnologie ist das von Google entwickelte Kubernetes. Es punktet mit einer großen Palette an Funktionalitäten und ist bei den großen Cloud-Plattform-Anbietern vertreten.

Aufbau eines Kubernetes Clusters

Ein Cluster in Kubernetes ist ein Zusammenschluss aus mehreren Nodes (physikalische Server), von denen einer oder mehrere als Master bezeichnet werden. Diese sind zuständig für die eigentliche Orchestrierung der Container.

Die kleinste Einheit in Kubernetes wird als POD bezeichnet. Sie können einen oder mehrere Container hosten, wobei üblicherweise lediglich einer gehostet wird. Sogenannte Deployments ermöglichen die Überwachung dieser PODs und können auf Fehler reagieren, indem der POD und der darin enthaltene Container neu gestartet werden. Sollte ein ganzer Node fehlerhaft sein, werden die darin laufenden PODs automatisch auf die übrigen Nodes ausgelagert, um weiterhin eine laufende Applikation zu gewährleisten. Zusätzlich sind Update Strategien möglich, die ebenfalls ein Stoppen der Applikation umgehen können.

Ein weiterer wichtiger Bestandteil von Kubernetes sind die Services, die die Kommunikation der PODs untereinander sowie nach außen erleichtern. Dazu zählt auch der LoadBalancer, der den Zugriff auf die Nodes vereinheitlicht, sollte die Anwendung auf mehrere Nodes verteilt sein. Dabei wird ebenfalls die Last gleichmäßig über die PODs verteilt

Graphic: Kubernetes

Vorgehensweise bei der Software-Modernisierung

Mit dem Wissen über Container und deren Orchestrierung kann die eigentliche App Modernisierung angegangen werden. Im ersten Schritt erfolgt die Analyse der bestehenden Anwendung. Schauen wir uns den Ist-Zustand unserer Anwendung an:

Graphic: Monolithisch

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.

Graphic: Microservice

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.

Graphic: Microservice Containerized

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.

Vorteile der Lösung

  1. Optimale Voraussetzung zur Durchführung der DevOps Prinzipien (für mehr Infos zum Thema DevOps bei M&M: https://www.mm-software.com/de/devops-in-der-softwareentwicklung)
  2. Eine moderne und skalierbare Microservice-Architektur.
  3. Die in unserem Beispiel extrahierten Microservices können unabhängig voneinander entwickelt, getestet und deployed werden.
  4. Jeder dieser Microservices fokussiert sich auf genau eine Aufgabe.
  5. Die Microservices können mit unterschiedlichen Technologien entwickelt werden.
  6. Die Orchestrierung und Skalierung der Container erfolgt mittels Kubernetes.
  7. Erweiterbares Microservice-basiertes Front- und Backend.
  8. Plattformneutrale Implementierung.

Fazit

Die Software-Modernisierung ist kein leichtes Unterfangen und es bedarf einer gründlichen Voruntersuchung, um die passende Migrationsstrategie zu finden. Die Strategie kann sich dabei von Anwendung zu Anwendung unterscheiden und hängt von mehreren Faktoren ab. Nach der Migration in die Cloud profitieren Sie durch Agilität, Skalierbarkeit, höhere Zuverlässigkeit, schnellere Leistung und Reduzierung der Betriebskosten. Auf den Weg dahin sollten Sie die Komplexität und die aufkommenden Fallstricke nicht unterschätzen.

Nutzen Sie Expertenwissen, um Ihr Projekt zum Erfolg zu führen. Das Team von M&M berät Sie umfassend. Gemeinsam mit Ihnen entwickeln und realisieren wir die passende Strategie.

Autoren

Daniel Marcek
Group Leader - Software Applications

Timon Kammerer
Software Developer

Dirk Stadtherr - Sales Manager
Dirk Stadtherr

Dirk Stadtherr

Sales Manager

Standort: St. Georgen
E-Mail: dsr@mm-software.com
Tel.: +49 7724 9415-2507

Jörg Olsen
Jörg Olsen

Jörg Olsen

Sales Manager

Standort: Hannover
E-Mail: jon@mm-software.com
Tel.: +49 511 13220646

Sprache der Seite ändern