Die neue atomare Einheit

Wie stehen Funktionen, Container und Serverless Computing zueinander?

| Autor / Redakteur: Chad Arimura* / Ulrike Ostler

Aufklärung: Chad Arimura erläutert die Begriffe Container, Funktionen sowie Serverless Computing und was sie bedeuten.
Aufklärung: Chad Arimura erläutert die Begriffe Container, Funktionen sowie Serverless Computing und was sie bedeuten. (Bild: gemeinfrei: distel2610/ Pixabay / CC0)

Chad Arimura war Gründer und Chef von Iron.io und ist nun Vice President Software Development bei Oracle. Er schreibt: “Container und Funktionen sind heiß, doch: Was genau ist der Unterschied zwischen den beiden? Ich habe dieses Gespräch in letzter Zeit oft geführt und es ist klar, dass es keine einfache Antwort gibt. In diesem Beitrag werde ich versuchen, eine Antwort zu geben.“ Nun denn:

Wie stehen Container und Funktionen miteinander in Beziehung? Hier die allgemeinen Definitionen:

Container: „Ein Container-Image ist ein leichtgewichtiges, eigenständiges, ausführbares Softwarepaket, das alles enthält, was zur Ausführung benötigt wird: Code, Laufzeit, Systemwerkzeuge, Systembibliotheken und Einstellungen“, so steht es auf der Docker-Website.

Funktionen hingegen sind Codeblöcke, idealerweise klein und zweckbestimmt. Im Rahmen von serverless computing werden sie über eine Functions-as-a-Service (FaaS)-Plattform koordiniert und terminiert, wie die Anbieterdienste AWS Lambda, Azure Functions und Google Cloud Functions oder Open Source Frameworks wie das Fn-Flow-Projekt von Oracle, OpenWhisk und OpenFaas.

Unter serverless ist eine Kategorie des Software-Designs zu verstehen, bei der sich die Abstraktionsschicht für Entwickler auf der Anwendungsebene befindet, oberhalb des Betriebssystems, der Infrastruktur und der Cloud IaaS-APIs. Mit anderen Worten: Entwickler denken nie an die Infrastruktur.

Die frühesten FaaS-Teilnehmer, Lambda, Azure, Google und OpenWhisk, bieten ein Application Programming Interface (API) oder ein Graphical User Interface (GUI) zum Hochladen von Code an. Es gibt keine Container. So ist der Benutzer an vorgefertigte Umgebungen und weniger ideale Systeme zur Verwaltung von Abhängigkeiten gebunden. Ein Twitter-Thread, initiiert von Kelsey Hightower, Google, verdeutlicht den aktuellen Stand des Denkens an dieses Modell (siehe: Abbildung): „Nachdem ich einige Serverless-Plattformen überprüft habe, kann ich den Wert im Umgang mit dem Quellcode nicht erkennen. Container-Images bieten einen besseren Rahmen.“

https://twitter.com/kelseyhightower/status/921527605110513665?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.com%2Fmedia%2Fc7974950f3ca9442864cf7d68695effa%3FpostId%3D51c879216b97
https://twitter.com/kelseyhightower/status/921527605110513665?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.com%2Fmedia%2Fc7974950f3ca9442864cf7d68695effa%3FpostId%3D51c879216b97 (Bild: Kelsey Hightower/Twitter)

Die neuere Generation von Frameworks indes, einschließlich unseres Fn-Projekts, sind „container native“, was bedeutet, dass der Docker-Container quasi darin quasi zuhause sind und jedes Image selbst als Funktion verwendet werden kann.

Das aber ist der Knackpunkt der Verwirrung:

Wenn die Funktion der Container ist und der Container eine Funktion ist, sind sie dann tatsächlich verschieden?

Was ist außerdem der Wert eines FaaS-Systems, wenn man einen Container einfach auf einer Plattform wie „Cloud Foundry“ oder „Kubernetes“ betreiben kann?

Funktion < Behälter

Ein Container kann alles enthalten, von einem Webservice über einen Millionen-LOC-Monolithen bis hin zu einem kompletten Datenbank-Management-System (DBMS) und der Datenschicht, in das DBMS schreibt. Container können ewig leben, horizontal skalieren (oder auch nicht), brauchen beispielsweise 20 Minuten zum Starten, 20 Tage zum Laufen und so weiter und so fort.

Das steht im Kontrast zu Funktionen, die typischerweise eine Reihe von Eigenschaften hat, wie diese:

  • short running: Funktionen leben für kurze Zeit und dann endet der Prozess. „Kurz“ ist natürlich subjektiv, aber nehmen wir an, wir sprechen von 5 Minuten oder sogar weniger.
  • flüchtig: Der äußere Container, in dem die Funktion ausgeführt wird, darf nur für einen einzigen Funktionsaufruf leben.
  • stateless: Die Funktion behält von Natur aus keinen Zustand. Alle Zustände müssen in strukturierte oder unstrukturierte Speicher verschoben werden.
  • Aufrufe: Funktionen werden durch definierte Ereignisse über HTTP, TCP oder ein anderes Protokoll aufgerufen.
  • single purpose: Funktionen haben einen einzigen klaren und definierten Zweck mit minimaler API-Oberfläche, das heißt: Sie nehmen einigermaßen kurzzeitig Input auf und liefern kurz und knapp den Output.
  • autark: Eine Funktion kann selbstständig ablaufen und ihren Zweck erfüllen. Obwohl eine Funktion wahrscheinlich nur ein Teil einer breiteren Gruppierung von Funktionen ist - so erstellen viele Funktionen eine API und eine Folge von Funktionen erzeugt einen „Flow“ - kann sie selbstständig laufen, solange sie die notwendigen Eingaben erhält.

Nun wird die Funktion mit ihren Eigenschaften in einen Container gepackt. Damit ergibt sich ein neue Bild von dem, was einen Container ausmacht, ein mächtiges Konzept, eine neue atomare Recheneinheit.

Eine atomare Recheneinheit

Bildlich gesprochen lässt sich das Software in Form von physikalischen Bausteinen denken. Das gibt es zum Beispiel eine Bildverarbeitungsfunktion oder eine Funktion für die Statusanalysen. Die Funktionen lassen sich gemeinsam nutzen, erweitern sowie zu Anwendungen zusammensetzen, „Composite Applications“ entstehen. Der Einsatz dieser atomaren Einheit versetzt also in die Lage, Software-Aquivalente aus Molekülen und komplexen Organismen zu konstruieren.

Die Antwort von Chad Arimura auf den Twet von Kelsey Hightower
Die Antwort von Chad Arimura auf den Twet von Kelsey Hightower (Bild: https://twitter.com/chadarimura/status/922504511788343297?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.com%2Fmedia%2Fb157b5657d8e9ed44372db225ed5aae5%3FpostId%3D51c879216b97)

Mit Containern entstehen nicht nur atomare Recheneinheiten, sondern diese bekommt auch alle Vorteile des Containers selbst, wie ein standardisiertes Verpackungsformat, das Laufzeitverhalten, Storage- und Transportrigenschaften. Darüber hinaus lassen sich Plattformen und Werkzeuge speziell für diese neue atomare Recheneinheit entwickeln werden. Daraus ist eine mittlerweile florierendes Ökosystem rund um Funktionen und Serverless Computing entstanden. Das ist es, was die Container-Metapher in erster Linie darstellt.

Funktionen als Einheit der Skalierung

Der Großteil an Software wurde mit der Absicht entwickelt, sie für viele Benutzer zu skalieren. Früher war das Prinzip dafür Scale-up (größere Maschinen), jetzt ist es Scale-out (mehr Maschinen). Das jetzt gültige Prinzip erlaubt im Gegensatz zum Scale-Up, bei dem größere Rechner kleine ersetzten ein deutlich feinkörnigeres Wachstum, so dass mit einer größeren Genauigkeit von einem einzigen Prozess aus skaliert werden kann.

Dafür sind weder Funktionsaufrufe noch Container oder Maschinen erforderlich. Diese Einheiten lassen sich schlichtweg wieder verwenden, um eine andere Operation auszuführen. Zudem können Funktionsaufrufe und Spin-Up-Container, die freien Ressourcen nutzen. Dies ist zwar eine vereinfachte Sichtweise, aber noch einmal: Die Eigenschaften der Funktionen in Verbindung mit der universellen Verpackung/Laufzeit der Behälter bieten eine viel effektivere Möglichkeit, Anwendungen zu skalieren.

Funktionen als Fakturierungseinheit

Das Abrechnungsmodell von „serverless“ stellt eine spannende Weiterentwicklung da. Anstatt Server oder VMs für Tage, Monate oder Jahre laufen zu lassen, bietet sich jetzt die Möglichkeit, viel granularer zu bezahlen, bezogen auf die Zeit, die eine Funktion in Anspruch nimmt - manchmal nur Millisekunden. Dies erlaubt, die Kosten zu reduzieren, insbesondere wenn es um wenig genutzten Applikationen oder etwa Iterationen beim Testen von Features geht.

Funktionen als Designeinheit

Design ist das beste Wort, das ich finden konnte, um das zu beschreiben, was ich als „das nächste SOA-Ding“ (SOA = Service Oriented Architecture) bezeichne. Funktionen, die in Containern mit eigenem Vertrag gepackt sind, sollten grundsätzlich von vielen genutzt werden können, damit Composite Applications erstellt und wiederverwendet werden können. Dies erfordert Werkzeuge für die Funktionsorchestrierung. Und das ist das Problem, was wir mit „Fn Flow“ lösen wollen.

* Chad Arimura war Gründer und Chef von Iron.io und ist nun Vice President Software Development bei Oracle.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45109711 / Anwendungen)