Grundlagen des Cloud Computings

Apps wandern in die Wolke

2. November 2018, 7:00 Uhr | Oliver Richter

Aufgrund des ständig wachsenden Cloud-Angebots stehen viele Unternehmen vor der Entscheidung, künftig Cloud-Dienste in Anspruch zu nehmen oder sogar ihre gesamte IT-Struktur in die Cloud zu verlagern. Jedoch ist vielen IT-Verantwortlichen bei der Entscheidung, Applikationen in die Cloud zu überführen, nicht bewusst, dass ein Wechsel mit einem sehr großen Aufwand verbunden und die Umstellung langwierig ist.

Die Cloud-Architekturen lassen sich in organisatorische und technische Arten aufteilen. Die organisatorischen Cloud-Architekturen unterscheiden sich nach dem Verhältnis zwischen Benutzer und Anbieter: Ein Benutzer nimmt die Cloud-Dienste in Anspruch, die der Anbieter bereitstellt. Vertreter organisatorischer Cloud-Architekturen sind die Public, Private und Hybrid Cloud. Public-Cloud-Provider veröffentlichen einen Cloud-Dienst und bieten dem Benutzer die Möglichkeit, den Dienst per Web-Portal zahlungspflichtig in Anspruch zu nehmen. Die Private Cloud differenziert sich nach "On-Premise" (in eigenen Räumlichkeiten) und "Off-Premise" (an einem entfernten Standort). Die dritte Option ist die Auslagerung bestimmter Funktionalitäten oder Lastspitzen aus der Private Cloud in die Public Cloud, bezeichnet als Hybrid Cloud.

Ein Bereitstellungsmodell für eine Hybrid Cloud deutet die US-Behörde NIST (National Institute of Standards and Technology) in ihrer Definition des Cloud Computings mit dem Cloud Bursting an. Die Architektur des Cloud Burstings ermöglicht es, erhöhte Auslastungen zu erkennen und bei erhöhter Auslastung einzelne Applikation oder virtuelle Maschinen (VMs) in eine Public Cloud zu verschieben.

Im Gegensatz zu den organisatorischen sind die technischen Cloud-Architekturen an funktionalen Eigenschaften orientiert. Das Bild zeigt den hierarchischen Aufbau der technischen Cloud-Architekturen. Die unterste Schicht bildet IaaS (Infrastructure as a Service). Hier erhält der Nutzer eine abstrahierte Sicht auf die verfügbaren Ressourcen eines Anbieters, zum Beispiel auf Massenspeicher oder Netzwerke. Darüber befindet sich die PaaS-Schicht (Platform as a Service). Sie richtet sich an Entwickler, da es sich hier um eine in die Cloud verlagerte Entwicklungs- und Laufzeitumgebung handelt. Die oberste Schicht ist der SaaS-Layer (Software as a Service). SaaS-Anwendungen richten sich direkt an den Endbenutzer, der sie als kostenpflichtige Leistung vom Cloud-Anbieter in Anspruch nimmt.

Möglichkeiten der Virtualisierung

Die Stärken der Virtualisierung liegen im schnellen Aufsetzen, Zerstören und Neuaufsetzen virtueller Instanzen. Damit lässt sich die Ausfallzeit bestimmter Dienste gering halten, unkontrollierte Veränderungen (Configuration Drifts) lassen sich mittels Neuaufsetzen eliminieren. An dieser Stelle bietet sich die Phoenix-Server-Methode an: Laut dieser sollte man Server in regelmäßigen Abständen zerstören und anschließend auf Grundlage einer wiederherstellbaren Sicherung neu aufsetzen.

LL11S04a ohne Rand
Überblick über die Schichten bei technischen Cloud-Architekturen. Bild: Oliver Richter

Ein Verfahren zur Virtualisierung ist die sogenannte "Nested Virtualization" (verschachtelte Virtualisierung). Hier setzt man eine virtuelle Instanz auf einer bereits vorhandenen virtuellen Instanz auf: Hypervisoren wie Hyper-V, ESXi und KVM lassen sich innerhalb von VMs installieren, um auf ihnen weitere virtuelle Instanzen zu betreiben. Die virtuelle Verschachtelung führt derzeit noch zu deutlichen Performance-Verlusten bei CPU-intensiven Anwendungen. Deshalb ist der Einsatz der Nested Virtualization nur teilweise zu empfehlen.

Eine weitere Möglichkeit ist die Nutzung von Containern. Im Gegensatz zu VMs stellen Container keine eigene Instanz dar, sondern greifen auf den gleichen Kernel wie der Host zu. Dies hat den Vorteil, dass Container direkt die Hardware des Hosts nutzen können. Des Weiteren entfällt so ein zusätzlicher Hypervisor und die verfügbare CPU lässt sich direkt für die Containeranwendungen nutzen.

Docker und Kubernetes

Den Quasi-Standard für Containerisierung bildet Docker. Docker verfolgt den Einzelprozessansatz, bei dem einzelne gekapselte Prozesse abgearbeitet werden. Der Einzelprozessansatz eignet sich besonders für Service-orientierte Architekturen, da jeder Service so in einem eigenen Docker-Container laufen kann. Für den Aufbau der Images setzt Docker auf ein Schichtensystem, bei dem jede Schicht unveränderbar ("immutable") ist. Der Vorteil: Bereits erstellte Schichten (Layers) lassen sich für ein weiteres Image mit einer anderen Applikation wiederverwenden. So muss das IT-Team den Layer nur einmal im System ablegen, was Speicherplatz spart. Dies ist ein weiterer Vorteil von Containern gegenüber VMs, da diese für jedes Neuaufsetzen von der Ausgangsbasis aufzubauen sind und dabei jedes Mal ein gesamtes Image erzeugt wird. Besonders deutlich wird dieser Vorteil bei der Instanziierung weiterer Container.

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

LL11S04Tabelle
Die vorgestellten Plattformen unterscheiden sich unter anderem in der unterstützten Architektur.

Die Hauptaufgabe von Kubernetes lässt sich mit dem Motto "Containerschiffe brauchen einen Steuermann" exakt beschreiben: Kubernetes dient der Orchestrierung von Docker-Containern. Kubernetes fasst hierfür verschiedene Docker-Container in sogenannten "Pods" zusammen. Jedem Pod wird ein physischer Rechnerknoten zugewiesen. Dadurch teilen sich die im Pod zusammengefassten Container einen Namensraum, eine IP-Adresse und einen Port. Gegenüber der Standardversion von Docker sind die Container durch Kubernetes "lokal" zueinander und können direkt miteinander kommunizieren.

Aufbau einer Entwicklungsumgebung

Die Entwicklung und Bereitstellung von eigenen Applikationen innerhalb der Cloud erfolgt innerhalb der PaaS-Schicht. Unterschiedliche PaaS-Plattformen stehen zur Auswahl (siehe Tabelle). Alle untersuchten Plattformen bieten die Möglichkeit, Container zu erstellen, setzen einen Service zur Orchestrierung ein, hosten eine Public-Variante ihrer Plattform, können Daten persistent speichern und unterstützen die Programmiersprachen Java, Ruby, Node.js, PHP und Python. OpenShift und Microsoft Azure bieten zusätzlich die Option, eine eigene private Variante der Cloud in der eigenen lokalen Infrastruktur zu erstellen und bei Ressourcenknappheit Prozesse in die Public Cloud zu verschieben. OpenShift ist die einzige der untersuchten Plattformen, von der es eine Open-Source-Variante gibt. Bei den unterstützten Datenbanken bieten OpenShift und Heroku mehrere Alternativen an, während Google und Microsoft nur ihre hauseigenen SQL-Datenbanken offerieren.

Schlussendlich liegt die Entscheidung, für welche Plattform man sich entscheidet, an folgenden Fragestellungen:

  • Verfügt das Unternehmen bereits über eine lokale Infrastruktur, und will es diese in die Cloud überführen?
  • Wie hoch ist das Budget?
  • Welche organisatorische Cloud-Architektur bevorzugt das Unternehmen?
  • In welcher Programmiersprache will es die Web-Anwendung entwickeln?
  • Will es die internen Daten anderen Dienstleistern übergeben?
  • Ist die zu überführende Software bereits an bestimmte Technologien gebunden?

Auswahl der passenden PaaS-Plattform

Auf der Suche nach der passenden PaaS-Umgebung für die bestehende Applikation sollte man vorab eine Scorecard erstellen, um zu prüfen, ob es überhaupt sinnvoll ist, die bestehende Applikation in die Cloud zu überführen, oder ob man die Applikation besser innerhalb der PaaS-Umgebung neu entwickeln sollte (Kosten-Nutzen-Verhältnis). Idealerweise stellt die PaaS-Umgebung Templates bereit, um den Pod in wenigen Schritten zu starten und die Applikation lauffähig zu bekommen. Der Nachteil an vorhandenen Templates ist jedoch, dass diese auf Images zugreifen, bei denen die Entwickler eventuell wenig Wert auf hohe Sicherheit gelegt haben. Daher ist es besonders im kommerziellen Bereich wichtig, selbst auf die Sicherheit zu achten und gegebenenfalls Module innerhalb kritischer Pods zu installieren.

Oliver Richter ist Software Engineer bei Adesso, www.adesso.de.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu saperion AG

Weitere Artikel zu Pixelpark

Weitere Artikel zu StudiVZ

Matchmaker+