Die Zeiten der Cloud als Buzzword sind vorbei. Sie ist real und in unser aller IT-Alltag angekommen. Nun schwirren die nächsten tollen Wörter durch die Gegend, doch was bedeutet das alles eigentlich in der Praxis?
Genau dieser Frage möchte ich auf den Grund gehen indem ich einerseits hier einfach dieses Vokabular um Erklärungen ergänze und andererseits auch, vor allem in den folgenden Teilen dieser Serie, aus meinem Alltag als Developer berichte und euch erzähle welche und wie diese neuen Technologien die Art wie wir Software bauen verändert haben.

Docker

Docker ist an sich eine Plattform zur Virtualisierung. Aber anders als bei VM-Ware oder Virtualbox packt Docker die OS Userspaces in die einzelnen so genannten Container, lauffähige Virtuelle Applikation, gleiche OS Teile werden aber mit anderen Containern geteilt.
Docker virtualisiert Anwendungen und nicht ganze “Computer” oder Server. Aber schön nach der Reihe.
Docker läuft auf diversen Linux Distributionen, es gibt aber auch Möglichkeiten Docker unter OS X zu betreiben. Dort läuft zu allererst der DockerHub. Dieser dient so zu sagen als Runtime/Host für alle Docker Container, also die lauffähigen, von einander isolierten Applikationen.
Docker Images hingegen sind portable Abbildungen eines Containers. Mittel solcher Images können viele der darin gepackten Applikationen inklusive Konfiguration, diese steht im Dockerfile, als neue Container am DockerHub erzeugt werden. Außerdem können diese Images auch verwendet werden um Container daraus auf anderen DockerHubs zu erzeugen.
Worin liegt aber nun der Vorteil gegenüber VM-Ware und Co.? Während der Entwicklung von Applikationen und darüber hinaus ist es meist nötig verschiedene Umgebungen der selben Applikation herzustellen. Eine und oder mehrere Versionen für den oder die Developer, eine für die Qualitätsicherung und natürlich auch für den Echtbetrieb.
Docker vereinfacht einerseits die Bereitstellung von Anwendungen, weil die Container, die alle nötigen Pakete enthalten, leicht als Dateien transportiert und installiert werden können, ohne sich um das darunterliegende Betriebssystemkümmern zu müssen und andererseits gewährleisten Container die Trennung der auf einem Rechner genutzten Ressourcen. Das bedeutet obwohl die Container alle am selben geteilten Host laufen und so viel weniger Resourcen benötigen, kommen sie sich nicht in die Quere weil sie praktisch in einer Art eigener Sandbox laufen.

Kubernetes

Kubernetes ist ein OpenSource Container Manager. In Cloud Architekturen ist es nötig effizient und automatisch neue Server Instanzen zu starten und sie so konfigurieren zu können, dass sie mit dem Rest der Serverflotte und dem Rest der Welt interagieren können. Die gesamte Architektur skaliert also nach Bedarf.
Um so etwas vollkommen automatisiert machen zu können kommt eben Kubernetes zum Einsatz. Es ist sozusagen der Stratege im virtuellen Rechenzentrum, der sich darum kümmert, dass immer genug Server, inklusive der darauf laufenden Applikationen, vorhanden sind um die Last auszuhalten.
Kubernetes startet, konfiguriert und stoppt, sofern korrekt konfiguriert, also immer so viele Container aller im gesamten System vorhandenen Applikationen um die tatsächlich vorhandene Hardware darunter ideal auszunutzen und das automatisch je nach anstehender Last für die einzelnen Applikationen.
Im Idealfall sieht es für die Nutzer (Kunden), die die einzelnen Applikationen nutzen, immer so aus als gäbe es die jeweilige Applikation nur einmal – verfügbar immer beispielsweise unter der selben URL – und diese läuft einfach immer sehr gut und performant, obwohl in Wirklichkeit bei hoher Last viele Instanzen und bei geringer Last nur wenige oder sogar gar keine Instanz im System läuft.
Ein weiterer Vorteil der leichtgewichtigen Docker Container ist nämlich, dass sie sehr schnell hochgefahren werden können, weil kein Betriebssystem booten muss, denn dieses läuft ja schon im DockerHub.
So ist es mit Kubernetes möglich das Meiste aus der vorhandenen Hardware herraus zu holen und diese ideal zu nutzen, weil die Resourcen immer so zugeteilt werden wie es die aktuelle Last verlangt. Denn meist ist es ja so, dass nicht immer alle Applikationen in einem Rechenzentrum zu jederzeit gleich viele Resourcen benötigen, sondern, dass es je nach Einsatzgebiet, Region der Nutzer, etc. zu großen Unterschieden in der aktuellen Nutzung kommt.
Kubernetes, wenn es richtig konfiguriert und verwendet wird, kann einem also gleichzeitig viel Geld sparen, weil man weniger Hardware benötigt und den Nutzern immer die best mögliche Performance bieten. Kurz gesagt, Schluss mit Servern, die sich den ganzen Tag langweilen und im Serverraum neben anderen Servern stehen, die vor lauter Last heiß laufen.

AppEngine

Nun kommen wir zu einem Service den es nur in der Google Cloud Platform gibt, jedoch gibt es vergleichbare Dienste auch bei anderen Anbietern.
AppEngine ist, ganz einfach gesagt, ein Application Server, eine Platform as a Service (PaaS).
Dieser Application Server erlaubt es Entwicklern Applikationen und Services zu hosten ganz ohne sich Gedanken über die Konfiguration dieses Application Servers oder gar des darunter liegende OS, Routing, Loadbalancing und so weiter zu machen. Alles was man tun muss ist seine Applikation zu entwickeln und sie auf der AppEngine zu deploynen.
Was dann passiert, passiert dank der oben genannten Tools, vollkommen automatisiert.
Je nach Last werden mehr oder weniger Instanzen der Applikation erzeugt und so konfiguriert, dass sie sofort miteinander und dem gesamten System zusammenarbeiten und nach Außen sieht es alles nach einer einzelnen Applikation aus.
Die Entwickler können sich also darum kümmern was sie am Besten können, entwickeln und das System skaliert und repliziert wie von Geisterhand.

Compute Engine

Dabei handelt es sich um klassische virtuelle Maschinen, die innerhalb der Google Cloud Platform gehostet werden. Andere Anbieter wie Amazon, stellen solche virtuellen Maschinen auch bereit, dort heißt dies EC2.
Diese Maschinen beinhalten ein Betriebssystem und ihnen werden direkt Resourcen (CPUs, RAM, etc.) zugeteilt.
Auch diese Maschinen können jederzeit repliziert werden, jedoch dauert dies länger und je nach Applikation die darauf läuft, muss diese “per Hand” in das Gesamtsystem eingebunden werden.
Im Gegensatz zur AppEngine hat man hier aber freie Hand was Konfiguration und Installationen von zusätzlicher Software und Libraries angeht. Jedoch muss man sich darum eben selbst auf jeder Instanz kümmern.

Managed VMs

Wir sehen also sowohl die Compute Engine als auch die AppEngine haben ihre Vor- und Nachteile, am Besten wäre es also diese beiden zu kombinieren und genau das sind Managed VMs.
Diese AppEngine Instanzen laufen auf managed Compute Engine Instanzen auf denen man sich das Betriebssystem aussuchen kann und auch zusätzliche Software und Libraries installieren kann, aber sie verhalten sich was automatische Skalierung und Replikation angeht wie AppEngine Container.

Ausblick

Nun haben wir mal ein paar Begriffe etwas näher erklärt und damit die Basis geschaffen, dass ich euch in den nächsten Teilen dieser Serie erzählen kann was wir davon wie verwenden und wie es uns damit geht.
Sollten ihr noch Fragen haben oder euch etwas Spezielles dazu interessieren, scheut euch nicht davor dies in den Kommentaren zu hinterlassen.