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

Vergleich von aktuellen Cloud-Plattformen

Wie bereits im zweiten Teil meiner Blog-Serie angedeutet, benötigt ihr innerhalb der Cloud 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 Entwicklung und Bereitstellung von eigenen Applikationen in der Cloud erfolgt nämlich innerhalb der PaaS-Schicht. Natürlich seid ihr nicht an einen bestimmten PaaS-Anbieter gebunden, sondern könnt selbst entscheiden. Um euch einen groben Überblick über verschiedene Technologien zu geben, möchte ich euch die Cloud-Plattformen OpenShift, Heroku, Goolge App Engine und Microsoft Azure kurz vorstellen und euch die aus meiner Sicht wichtigsten Merkmale nennen.

Die wichtigsten Dinge zuerst: Alle Plattformen bieten euch die Option, Container zu erstellen, setzen einen Service zur Orchestrierung ein, hosten eine Public-Variante ihrer Plattform, haben eine Möglichkeit, um Daten persistent zu speichern und unterstützen die Programmiersprachen Java, Ruby, Node.js, PHP und Python.

Bei OpenShift und Microsoft Azure habt ihr zusätzlich die Möglichkeit der Hybridisierung. Das heißt, ihr könnt eine eigene private Variante der Cloud in eurer eigenen lokalen Infrastruktur erstellen und bei Ressourcenknappheit Prozesse in die öffentliche Cloud verschieben.

Auch bei den Kosten für die Bereitstellung und Nutzung gibt es Unterschiede. OpenShift ist die einzige der genannten Plattformen, von der es eine Open-Source-Variante gibt. Bei Heroku ist die Nutzung des Dienstes bis zu einer Anwendungsgröße von 512 MB RAM kostenlos. Google stellt eine kostenlose Variante für die Nutzung von nichtkommerziellen Zwecken bereit und Microsoft bietet euch einen kostenfreien Testzugang mit einem Startguthaben von 170 Euro für die ersten 30 Tage.

Was die unterstützten Datenbanken angeht, bieten OpenShift und Heroku Alternativen, ihr könnt also eigenständig zwischen mehreren Datenbanken wählen. Anders ist es bei Google und Microsoft, denn dort könnt ihr nur auf die jeweils „hauseigenen“ SQL-Datenbanken zurückgreifen. Bei Microsoft Azure besteht zudem die Möglichkeit, vor die Datenbank eine API zu setzen, sodass sich die Datenbank beispielsweise wie eine MongoDB - eine dokumentenorientierte NoSQL-Datenbank - verhält.

Um euch die Entscheidung zu erleichtern, solltet ihr euch im Vorfeld folgende Fragen stellen:

• Wie hoch ist euer Budget?
• Ist bereits eine lokale Infrastruktur vorhanden und soll diese in die Cloud überführt werden?
• Welche organisatorische Cloud-Architektur (Public, Private oder Hybrid) wird bevorzugt?
• In welcher Programmiersprache soll eure Webanwendung entwickelt werden?
• Welches Betriebssystem bevorzugt ihr?
• Welche Technologien sollen eingesetzt werden?
• Ist die zu überführende Software bereits an bestimmte Technologien gebunden?

Die Entscheidung, welche Technologien eingesetzt werden sollen, kann ich euch natürlich nicht abnehmen. Vielmehr kommt es auf eure konkreten Anforderungen an.

Nachdem ich euch in meinem letzten Beitrag bereits Docker vorgestellt habe, möchte ich euch nun weitere wichtige Technologien näher bringen, die ihr in diesem Zusammenhang kennen solltet.

Kubernetes

Die Hauptaufgabe von Kubernetes lässt sich mit dem Motto „Container-Schiffe brauchen einen Steuermann“ exakt beschreiben. Kubernetes dient der Orchestrierung von Docker-Containern. Dabei werden verschiedene Docker-Container in Pods zusammengefasst. Ein Pod ist übrigens die Bezeichnung für die Gruppierung von einem oder mehreren Docker-Containern, die zusammen funktionieren. Jedem Pod wird ein physischer Rechnerknoten zugewiesen. Dadurch teilen sich die im Pod zusammengefassten Container einen Namensraum, eine IP und einen Port. Gegenüber Docker sind die Container durch Kubernetes „lokal“ zueinander und können direkt miteinander kommunizieren. Auf einem Kubernetes-Knoten laufen die Dienste zur Containerverwaltung und Docker. Docker ist hierbei weiterhin für das Starten der Container und das Herunterladen der jeweiligen Images verantwortlich. In der unten gezeigten Grafik könnt ihr auf der rechten Seite ein Beispiel für die Darstellung der Kubernetes-Architektur „Node“ erkennen. In der linken Bildhälfte ist der Kubernetes-Master dargestellt, der für das „Managen“ der einzelnen Nodes verantwortlich ist. Konfigurationsanpassungen für den Master können übrigens über das Tool „kubectl“ abgesetzt werden.

VirtualBox

Das Virtualisierungstool „VirtualBox“ ermöglicht es euch, ein anderes Betriebssystem als Gastsystem auszuführen. Euer eingesetztes Gastsystem greift dann bei der Virtualisierung auf die Ressourcen des Hostsystems zu. VirtualBox ist kostenfrei und kann auf allen gängigen Betriebssystemen installiert werden. Um die identische Entwicklungsumgebung in VirtualBox auf mehreren Rechnern automatisiert erstellen zu können, wird Vagrant genutzt. Bei Vagrant handelt es sich um ein Systemkonfigurationswerkzeug, das euch eine automatisierte Installation einer virtuellen Maschine anhand einer Konfigurationsdatei (Vagrantfile) ermöglicht. Ein Vorteil sind hier die Vagrant-Boxen. Dabei handelt es sich um ein Paketformat für Vagrant-Umgebungen, das bereits konfigurierte Betriebssystemabbilder enthält. Eine solche Box könnt ihr auf jeder Plattform verwenden, die Vagrant unterstützt. So könnt ihr eine identische Arbeitsumgebung aufbauen. Zudem habt ihr die Möglichkeit, eigene benutzerspezifische Boxen zu erstellen und diese dann anschließend als Vagrant-Box auf eurem Datenserver bereitzustellen.

Gitlab

GitLab ist eine Webanwendung zur Versionsverwaltung. Sie ermöglicht es euch, den aktuellen Quellcode lokal zu klonen, Änderungen durch Commits hochzuladen und die Änderungen in den bestehenden Code einzupflegen.

Sonatype Nexus Repository OSS (Nexus)

Sonatype Nexus Repository OSS stellt euch einen Repository Manager für das Build Tool „Maven“ bereit. Ein Build oder Build-Prozess bezeichnet im Übrigen einen Vorgang, durch den ein fertiges Anwendungsprogramm automatisiert erzeugt wird. Nexus ermöglicht euch den Zugriff auf Bibliotheken und Artefakte, die zur Erstellung eines Builds oder innerhalb des Build-Prozesses benötigt werden. Ein Vorteil des Nexus Repository Managers ist, dass er als Proxy für einen anderen Nexus Repository Manager fungieren kann.

YAML

Bei Yet Another Markup Language - kurz YAML - handelt es sich um eine Auszeichnungssprache, die an XML angelehnt ist. Da OpenShift auf Kubernetes aufsetzt, nutzt es dessen YAML-Files für die Konfiguration und Erstellung von Pods. Somit lassen sich mit YAML Dateien erstellen, die ihr ins Git-Repository hochladen könnt und eine identische Konfiguration durch Kubernetes innerhalb der OpenShift-Umgebungen auf unterschiedlichen Rechnern ermöglichen.

Ausblick

Wie gesagt, ich kann euch die Entscheidung, welche Cloud-Plattform und Technologie eingesetzt werden soll, nicht abnehmen. Hier kommt es auf eure jeweiligen Anforderungen an. Ich hoffe allerdings, dass ich bereits mit den beschriebenen Technologien ein wenig Licht ins Dunkel bringen konnte. Auch im nächsten Teil meiner Blog-Serie geht es spannend weiter, denn ich werde auf die Liveness- und Readiness-Probe, Secrets, Sticky Sessions, Service Account und Makefile näher eingehen.

Weitere Beiträge dieser Blog-Serie:

Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 2)
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: https://www.slideshare.net/erialc_w/kubernetes-50626679