Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 2)

Lokale physische Hardware vs. Cloud-Dienste

Die Nutzung von physischer Hardware beziehungsweise von Cloud-Diensten hat jeweils ihre Vor- und Nachteile. Prinzipiell kann ich euch nicht zu der einen oder anderen Variante raten, denn es kommt vor allem auf eure konkreten Anforderungen an. Damit ihr euch aber selbst ein Bild machen könnt und seht, was für eure Zwecke besser geeignet ist, stelle ich diese beiden Varianten einmal gegenüber.

Der Einsatz von lokaler physischer Hardware hat den klaren Vorteil, dass ihr physischen Zugriff habt und auch beim Wegfall der Internetverbindung auf die Software zugreifen könnt. Das hört sich zunächst einmal gut an, allerdings müsst ihr beim Einsatz von lokaler Hardware auch mit langsamen Reaktionen auf Überlastungsspitzen rechnen. Außerdem seid ihr selbst für Backups sowie Aktualisierungen verantwortlich oder müsst eben die entsprechenden Ressourcen zur Systemwartung zur Verfügung haben. Zudem besteht das Risiko, dass Daten verloren gehen können.

Diese Nachteile sind gleichzeitig auch die Vorteile bei der Nutzung von Cloud-Diensten: Hier sind nämlich keine Ressourcen erforderlich, ihr habt geringe Kosten für eure IT und die Ausfallsicherheit ist durch den jeweiligen Anbieter garantiert. Zudem benötigt ihr keinen oder nur geringen Platz für eure Hardware. Ein weiterer Vorteil ist, dass Cloud-Dienste jederzeit skalierbar sind und nur dann bezahlt werden müssen, wenn ihr sie auch wirklich benötigt. Aber auch Cloud-Dienste haben einige Nachteile. Ohne Zugriff auf das Internet könnt ihr diese Dienste nicht nutzen. Außerdem ergibt sich ein Migrationsaufwand für bestehende Applikationen und es kann vorkommen, dass eine ältere oder selbstentwickelte Software nicht auf mehreren virtuellen Maschinen läuft.

Die Stärken der Virtualisierung – damit ist die Nutzung von Cloud-Diensten gemeint – bestehen vor allem im schnellen Neuaufsetzen von virtuellen Instanzen in zeitlichen Abständen und in der einfachen Möglichkeit, Wartungen durchzuführen. Auf diese Weise minimiert ihr die Ausfallzeit von wettbewerbsentscheidenden Anwendungen. Zudem stehen euch mehr interne IT-Ressourcen zur Verfügung, die ihr dann wiederum für andere Zwecke nutzen könnt.

Ein Problem stellt jedoch die Persistenz der jeweiligen Daten auf dem physischen und dem virtualisierten Server dar, denn hier können Abweichungen entstehen. Ich verrate euch, wie ihr diesem Problem entgegenwirken könnt. Erstellt ihr im laufenden Betrieb ein Abbild – einen sogenannten Snapshot– von eurem Server, könnt ihr dieses Abbild anschließend in einer virtuellen Umgebung nutzen. Somit ist es möglich, bei einem Ausfall des physischen Servers, den Betrieb weiterhin durch die virtuelle Serverinstanz aufrechtzuerhalten.

Möglichkeiten der Virtualisierung

Das schnelle Zerstören und Neuaufsetzen von virtuellen Instanzen ist ein klarer Vorteil. Hierdurch könnt ihr die Ausfallzeit von bestimmten Diensten gering halten und unkontrollierte Veränderungen - sogenannte Configuration Drifts - durch das Neuaufsetzen eliminieren. An dieser Stelle empfehle ich euch die Phoenixserver-Methode. Sie beschreibt, dass Server in regelmäßigen Abständen zerstört und anschließend neu aufgesetzt werden und zwar auf Grundlage einer wiederherstellbaren Sicherung (Snapshot).

Welche Möglichkeiten der Virtualisierung gibt es also konkret?

Nested Virtualization

Ein Verfahren zur Virtualisierung ist die Nested Virtualization. Hierbei handelt es sich um eine verschachtelte Virtualisierung, bei der eine virtuelle Instanz auf eine bereits vorhandene aufgesetzt wird. Ihr könnt Hypervisoren - beispielsweise Hyper-V, ESXi und KVM - innerhalb eurer virtuellen Maschinen installieren, um darauf weitere virtuelle Instanzen aufzusetzen. Die virtuelle Verschachtelung hat allerdings den Nachteil, dass es zu deutlichen Performanceverlusten bei CPU-intensiven Anwendungen kommt, weshalb ich euch den Einsatz der Nested Virtualization nur teilweise empfehle.

Container

Eine weitere Möglichkeit ist die Nutzung von Containern. Im Gegensatz zu virtuellen Maschinen stellen Container keine eigene Instanz dar, sondern greifen auf dem gleichen Kernel - also den Betriebssystemkern - wie der Host zu. Dieses Vorgehen hat den Vorteil, dass die Container auch direkt auf die Hardware des Host zugreifen können. Des Weiteren entfällt hierdurch ein zusätzlicher Hypervisor und die verfügbare CPU kann direkt für die Container-Anwendungen genutzt werden. Umsetzen könnt ihr das Ganze übrigens mit Docker.

Docker als geeignete Technologie

Innerhalb der Cloud benötigt ihr unterschiedliche Technologien, um funktionsfähige Anwendungen zu erstellen. Hier ist es wichtig, dass ihr für eure Applikation die passende Cloud-Plattform (PaaS) findet.

Die Open-Source-Software Docker dient hierbei zur Isolierung von Anwendungen mit Container-Virtualisierung. Diese Software verfolgt den Single-Process-Ansatz, bei dem einzelne und gekapselte Prozesse abgearbeitet werden. Dieser Ansatz ist besonders für serviceorientierte Architekturen (SOA) geeignet, da jeder Service in einen eigenen Docker-Container „gepackt“ werden kann. Für den Aufbau der Images setzt Docker auf ein Layer-System, bei dem jeder einzelne Layer „immutable“ - also unveränderlich - ist.

In der folgenden Abbildung erkennt ihr den Aufbau eines Docker Images. In diesem Beispiel wurde ein Apache Webserver (rot dargestellter Layer) auf einem Ubuntu Basis-Image (grüne Layer) aufgesetzt. Bei dem Basis-Image handelt es sich um kein klassisches Betriebssystem, da es nicht über einen eigenen Kernel verfügt.

Euer Vorteil bei der Nutzung des Immutable-Layer-Systems besteht darin, dass ihr für ein weiteres Image mit einer anderen Applikation die bereits erstellen Layer wiederverwenden könnt. Das ganze wird durch ein kurzes Beispiel sicherlich verständlicher: Beim Aufbau eines Tomcat Images können die grünen und blauen Layer erneut genutzt werden. Somit müssen die unteren Layer nur einmal in eurem System abgelegt werden, wodurch ihr viel Speicherplatz spart.

Die Wiederverwendung der Images ist ein weiterer Vorteil von Containern gegenüber virtuellen Maschinen. Wie die folgende Grafik zeigt, wird dies besonders bei der Instanziierung weiterer Container in eurem System deutlich.

Veränderungen, die bei der Ausführung des neu instanziierten Containers erzeugt werden, legt Docker in einem temporär beschreibbaren zusätzlichen Container ab - dem sogenannten Container Layer. Das hat den Vorteil, dass Docker für ein neu erstelltes Image nur den erstellten Container Layer in eurem System ablegt, indem auf die darunterliegenden Schichten verwiesen wird.

Ausblick

Ich hoffe, dass ich euch mit diesem Beitrag das ganze Thema „Virtualisierung“ etwas nähe bringen konnte. Auch im nächsten Teil meiner Blog-Serie geht es spannend weiter, denn ich werde aktuelle Cloud-Plattformen miteinander vergleichen und unter anderem auf Punkte wie Kubernetes, VirtualBox, Vagrant oder Gitlab näher eingehen.

Weitere Beiträge dieser Blog-Serie:

Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 1)
Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 3)
Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 4)
Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 5)

Bildnachweis: http://www.infoworld.com/article/3077875/linux/containers-101-dockerfundamentals.html