Docker ist die führende Umsetzung von Linux Containern - kein Wunder, hat Docker die Idee von Containern als leichtgewichtige Alternative zu Virtualisierung erst populär gemacht. Inzwischen hat sich das Ökosystem deutlich weiterentwickelt. Google hat mit dem Kubernetes Projekt den defacto Standard für Scheduling und Verwaltung von Containern und zugehörigen Resourcen geschaffen. Neben Docker existieren mit rkt (CoreOS) und CRI-O (Open Container Initiative) weitere Container Runtimes für das mittlerweile gesetzte OCI Image Format. Relativ neu dabei sind die Werkzeuge buildah zum Bauen von Containern und podman zur Ausführung mittels CRI-O (beide von Project Atomic, RedHat).

Warum entstehen unterschiedliche Runtimes und Build-Toolchains? Welche Vorteil für Nutzer im Kontext von Docker oder Kubernetes ergeben sich daraus?

Der Trend weg von großen, schwerfälligen Applikationsservern hin zu Microservices und Containern wird durch die Cloud als Ablaufumgebung stark beschleunigt. Konsequent weitergedacht erhält man noch kleinere Dienste, Nanoservices, die lediglich einzelne Funktionen umsetzen. Als minimale Deploymenteinheit lässt sich darüber eine feingranulare Skalierung erzielen, und durch verringerten Overhead eine kosteneffiziente Nutzung der Infrastruktur realisieren. Vorreiter war Amazon mit Lambda, doch auch andere Cloud Anbieter zogen schnell nach, und bieten Function-as-a-Service (FaaS) oder "serverless" Umgebungen an.

Kubernetes als De-facto-Standard für containerbasierte Cloudinfrastruktur bietet von Haus aus zwar kein vergleichbares Modell an, jedoch gibt es mit Oracle Fn, Kubeless und Open Whisk zahlreiche Projekte, die FaaS als OpenSource Plattform für den Einsatz in eigener Cloudinfrastruktur oder auch öffentlichen Kubernetes Cloud-Runtimes ermöglichen wollen.

Im folgenden wird ein kurzer Blick auf Kubeless in Kombination mit Java geworfen. Ausschlaggebend für diese Auswahl war ein relativ unkompliziertes Setup, wodurch die Hemmschwelle für Experimente verringert wird.