Serverless Computing in der AWS Cloud

Buchholz.

1 Serverless Computing

Serverless – das ist der neue Trendbegriff, wenn es um aktuelle Cloud-Technologien geht. Dabei ist der Begriff selbst zunächst irreführend, geht es eben genau nicht darum, dass wir jetzt Programmcode in der Cloud ausführen können, ohne dafür Server zu betreiben! Natürlich benötigen wir nach wie vor Server – wir kommen bloß nicht mehr mit ihnen in Berührung, weder physisch (Hardware) noch logisch (virtualisierte Serverinstanzen).

Bei Serverless Computing geht es vielmehr darum, dass wir Ressourcen in der Cloud nutzen, ohne uns um deren Verwaltung, wie z. B. OS- und Runtime-Updates, Verfügbarkeit und Skalierung, kümmern zu müssen. Diese Aufgabe übernimmt der Cloud-Betreiber (bzw. -Anbieter) vollständig für uns. Wir können uns damit voll und ganz auf das Implementieren und Betreiben unserer Anwendungen konzentrieren, ohne uns von Aufgaben, wie den zuvor genannten, ablenken zu lassen. Zusätzlich werden die von uns genutzten Ressourcen auch noch nach einem „echten" pay-per-use-Modell abgerechnet, also nicht mehr stundenweise, sondern wirklich nur nach dem, was wir auch nutzen. Wenn wir nur 100 ms nutzen, werden auch nur 100 ms abgerechnet.

In diesem Kapitel schauen wir uns die grundlegenden Konzepte von Serverless an und beleuchten den Weg hin zu Serverless. Auch wenn von vielen Personen Serverless mit NoOps in einem Satz genannt wird, ist es genau das nicht. Serverless hat sehr viel mit dem DevOps-Gedanken gemein, auch das werden wir beleuchten, bevor wir uns verschiedene Beispiele aus der Serverless-Welt anschauen.

1.1 Quickstart

Für die ganz Eiligen unter uns, die wissen möchten, wie eine serverlose Funktion aussieht, hier eine HelloWorld-Funktion für den AWS Lambda Service.¹ AWS Lambda ist eben jener Service in der Amazon Cloud, der es uns ermöglicht, Code auszuführen, ohne Server bereitstellen und verwalten zu müssen. Die HelloWorld-Funktion ist einmal in JavaScript (bzw. für die Node.js-Umgebung, Listing 1.1) und einmal in Java (Listing 1.2) geschrieben:

const handler = (event, context, callback) => {

  callback(null, 'Hallo ' + event.name);

}

Listing 1.1: AWS-Lambda-Funktion in JavaScript/Node.js

import com.amazonaws.services.lambda.runtime.Context;

public class Hello {

  public String handler(Map event,

                          Context context) {

    return Hallo + event.get(name);

  }

}

Listing 1.2: AWS-Lambda-Funktion in Java

Eine Funktion wird erst durch ein Event gestartet, da Serverless generell ereignisgetrieben (event-driven) ist (ein Ereignis könnte z. B. das Speichern einer Datei in Amazon S3 oder ein HTTP Request am API Gateway sein). Anders könnte der „real pay per use-Gedanke, also dass wir nur bezahlen, was wir auch wirklich nutzen, nicht umgesetzt werden, in diesem Falle beispielsweise mit einem einfachen Event-Objekt: {name: Serverless"}. Die Rückgabe von beiden Funktionen ist: Hallo Serverless. Mehr dazu in Kapitel 2.

Wie wir sehen, ist Serverless-Code kein Hexenwerk, sondern ganz normale JavaScript-Funktionen oder Java-Methoden (in einer Klasse), aber auf jeden Fall zustandslos. Es ist der Umfang und Gültigkeitsbereich (Scope), der ein anderer ist als bei bisherigen „kompletten" Anwendungen. So sollte eine Funktion nur eine einzige Aufgabe haben. Wenn bei Microservices und DDD² ein Service je Domain betrieben wird, ist es eine Funktion je Zweck oder Aufgabe bei Serverless. Man könnte das beispielsweise als Nanoservice bezeichnen.

Serverless bedeutet allerdings nicht nur Funktionen und AWS Lambda, wie wir im Laufe des Kapitels sehen werden.

1.2 Nur Amazon Web Services?

Dieses Buch konzentriert sich, wie der Titel schon sagt, auf serverlose Dienste in der AWS Cloud. AWS ist mit Lambda und Co. sicherlich der bekannteste Cloud-Anbieter am Markt, jedoch nicht der einzige. Alle großen Mitbewerber haben ebenfalls Serverless-Lösungen im Portfolio, jedoch unterscheiden diese sich in deren Leistungsumfang:

Microsoft: Azure Functions³

Google: Google Cloud Functions⁴

IBM: OpenWhisk⁵

IBM stellt mit OpenWhisk eine FaaS-Lösung bereit, die einerseits in der IBM-eigenen Bluemix Cloud läuft, aber auch von Anwendern in einer eigenen (Cloud-)Umgebung (On-Premise) betrieben werden kann. Die Nutzung einer öffentlichen Cloud-Umgebung ist damit also nicht Voraussetzung. Damit erhält man zunächst aber nur eine FaaS-Umgebung, also die Möglichkeit, Code auf Funktionsebenen zu deployen und auszuführen. Bis daraus eine komplette Serverless-Umgebung beim Anwender lokal vor Ort wird, ist jedoch ein nicht zu unterschätzender Aufwand nötig. Das darf nicht außer Acht gelassen werden.

Der Quellcode von OpenWhisk steht als Open-Source-Software unter der Apache Lizenz Version 2 zum Download und zur Nutzung zur Verfügung. Interessierte Entwickler können bei der Entwicklung von OpenWhisk mitarbeiten, der Quellcode des Projekts wird auf GitHub gehostet.⁶

Tabelle 1.1: Übersicht einiger FaaS-Cloud-Anbieter

Neben diesen bekannten Anbietern gibt es auch noch eine ganze Reihe an kleineren (Nischen-)Anbietern, die an dieser Stelle nicht alle aufgezählt werden können. Eine Recherche bei Google sollte jedoch schnell ein paar brauchbare Ergebnisse liefern.

Ein Vergleich, welcher Anbieter wie stark im Markt vertreten ist, ist schwer aufzustellen. Amazon ist, wie oben bereits erwähnt, mit AWS Lambda und Co. sicherlich der populärste Vertreter, aber wie sieht es mit den anderen aus? Mithilfe von Google Trends⁷ lässt sich zumindest die relative Häufigkeit der Suche nach den einzelnen Diensten feststellen. Die Zeitreihe beginnt im November 2014, als AWS den Lambda-Service auf der re:invent, der AWS-Hauskonferenz, vorgestellt hat:

Wie zu erwarten liegt AWS Lambda auf dem ersten Platz. Das generelle Interesse am Thema Serverless ist fast halb so groß wie der Gesamtanteil von AWS Lambda, was wahrscheinlich auch an der Popularität des Serverless Frameworks liegt (ein Framework zur Verwaltung aller serverlosen Ressourcen und Assets, siehe dazu Kapitel 5.3). Auf dem zweiten Platz, mit nur knapp einem Fünftel des Anteils von AWS Lambda, folgt Microsoft Azure Functions. IBM OpenWhisk und Google Cloud Functions sind weit abgeschlagen.

Abbildung 1.1: Google Trend für Serverless Cloud Services, 11/2014 bis 06/2017

Die Trendanalyse kann unter http://bit.ly/serverless-google-trend gerne individuell verändert und aktualisiert werden.

Diese Trendanalyse ist vielleicht nicht repräsentativ, sie zeigt jedoch ziemlich deutlich, wie die Interessen der Internetnutzer verteilt sind.

1.3 Das Serverless-Computing-Manifest

Es scheint, als lieben wir in der Softwarebranche Manifeste. Immer wenn ein neues Prinzip kommuniziert und etabliert wird (werden soll), wird ein Manifest dafür erstellt. Wir kennen aus der Vergangenheit als bekanntestes Manifest (die IT-Welt zugrunde gelegt, die Weltgeschichte mal außen vor gelassen) das Agile Manifest⁸, das Manifest für Software Craftmanship⁹ oder auch das Reaktive Manifest¹⁰.

Natürlich gibt es mittlerweile auch ein Manifest für die Serverless-Bewegung. Allerdings findet sich hierfür kein dedizierter und gesicherter Ursprung, das Manifest wird aber auf mehreren Webseiten und Konferenzen einheitlich zitiert. Meine Recherche ergab eine erstmalige Nennung des Manifests und Aufzählung der Inhalte im April 2016 auf dem AWS Summit in Chicago in einer Präsentation namens „Getting Started with AWS Lambda and the Serverless Cloud"¹¹ von Dr. Tim Wagner, General Manager für AWS Lambda and Amazon API Gateway.

Serverless Computing Manifesto

Functions are the unit of deployment and scaling.

No machines, VMs, or containers visible in the programming model.

Permanent storage lives elsewhere.

Scales per request. Users cannot over- or under-provision capacity.

Never pay for idle (no cold servers/containers or their costs).

Implicitly fault-tolerant because functions can run anywhere.

BYOC – Bring Your Own Code.

Metrics and logging are a universal right.

Das Manifest beschreibt die Grundprinzipien von serverlosem Computing sehr gut. Eine wortwörtliche Übersetzung ist, wie so oft, schwierig, deshalb schauen wir uns die einzelnen Punkte etwas ausführlicher an. Den meisten Prinzipien werden wir auf den folgenden Seiten und in den kommenden Kapiteln dieses Buchs noch mehrfach begegnen.

Functions are the unit of deployment and scaling.

Die Einheit für die Bereitstellung, Ausführung und Skalierung von Code ist eine Funktion. Keine komplette Anwendung, einfach eine Funktion. Diese Funktion ist für eine bestimmte Aufgabe zuständig (ähnlich dem Single-Responsibility-Prinzip¹²) und bearbeitet nichts anderes als das, wofür sie erstellt wurde. Eine Servlet-Funktion mit einer Berechnung ist im Serverless-Prinzip also schon zu viel, da sie sich um a) den Servlet-Mechanismus kümmert und b) die Berechnung selbst ausführt.

No machines, VMs, or containers visible in the programming model.

Serverlose Services werden nur über ein API angesprochen, nie über Maschinen-, VM- oder Container-Adressen, diese sind komplett transparent für den API-Nutzer. Für die Nutzung des API stellt der Serviceanbieter ein SDK bereit, mit dem der Zugriff möglich wird. Wo die entsprechende Hardware (auch VMs und Container bedürfen letztendlich einer Hardware) eigentlich steht, auf der der Code ausgeführt wird, ist nicht ersichtlich. Kein SSH, keine Konsole, keine Serverprozesse.

Permanent storage lives elsewhere.

Die Ausführung von serverlosen Services oder Funktionen ist komplett transient und zustandslos. Wie der Serviceanbieter die Umgebung bereitstellt, ist ihm überlassen, der Nutzer kann und darf sich nicht darauf verlassen, dass die Umgebung nach deren Ablauf noch zur Verfügung steht. Sollen Daten nach der Funktionsausführung noch für andere Services bereitstehen, müssen diese in einem anderen persistenten Medium (oder Service) abgelegt werden. Dies ist auch Aufgabe der Funktion, die die Daten berechnet/erzeugt hat. Unabhängig davon kann der Serviceanbieter Container oder Umgebungen cachen, wenn er feststellt, dass die gleiche Funktion mehrmals hintereinander ausgeführt wird, so dass eine höhere Performanz erzielt werden kann. Darauf darf sich ein Nutzer jedoch nicht verlassen.

Scales per request. Users cannot over- or under-provision capacity.

Die verwendete Umgebung skaliert automatisch mit der Anzahl der Requests. Hierfür sorgt der Serviceanbieter bzw. Cloud-Provider, in dem er die Ausführungsumgebungen überwacht. Der Nutzer kommt nicht mit diesen Aufgaben und Anforderungen in Berührung, er stellt nur die Funktionen bereit, die ausgeführt werden sollen. Soll eine Funktion mehrfach parallel ausgeführt werden, da viele Requests bzw. Events dies erfordern, so wird sichergestellt, dass die Funktion mehrfach parallel und unabhängig voneinander ausgeführt wird (eine Obergrenze von gleichzeitig maximal auszuführenden Funktionen ist aber dennoch je nach Cloud-Anbieter möglich).

Never pay for idle (no cold servers/containers or their costs).

Ein Nutzer von serverlosen Services zahlt nur deren reine Nutzung, nicht dafür, dass die Services für ihn bereitstehen. Wenn ein Nutzer also nur einmal am Tag für eine Minute einen Service nutzt, zahlt er auch nur für diese eine Minute am Tag und nicht dafür, dass er die Funktion theoretisch jederzeit und mehrfach gleichzeitig ausführen könnte. Der Code der Funktion, die ausgeführt werden soll, muss jedoch auch in der Cloud-Umgebung abgelegt werden. Dieser darf nicht transient sein (sondern nur die Laufzeitumgebung, s. o.) und immer dann zur Verfügung stehen, wenn die Funktion ausgeführt werden soll. Demnach benötigt die Ablage des Funktionscodes Speicherplatz in einer Cloud-Umgebung. Damit wird der Speicherplatz genutzt, was zu einer Rechnungsstellung des in Anspruch genommenen Speicherplatzes führen kann. Die Kosten für Speicherplatz sind mittlerweile jedoch so immens gering, dass diese nicht ins Gewicht fallen sollten.

Dieses Prinzip gilt vorrangig für durch einen Cloud-Anbieter bereitgestellte Services. Wird eine Serverless- oder FaaS-Umgebung On-Premise betrieben (z. B. mit Apache OpenWhisk), ist das Abrechnungsmodell in der jeweiligen Organisation wahrscheinlich ein anderes.

Implicitly fault-tolerant because functions can run anywhere.

Wie in den vorangegangenen Punkten bereits erwähnt, ist für den Nutzer nicht ersichtlich, wo die Funktion ausgeführt wird. Muss und soll es auch nicht, denn der Anbieter entscheidet selbst, wo (in welchem Rechenzentrum, in welcher Umgebung etc.) ausreichend Kapazitäten zur Verfügung stehen, um die Funktion ausführen zu können. Die Funktion selbst darf auch nicht davon abhängig sein, wo sie ausgeführt wird, sie muss einfach überall laufen können (damit also keine Abhängigkeiten auf das darunter liegende Betriebssystem haben). Damit wird das System implizit fehlertolerant, da eine Ausführung nicht auf einen bestimmten Knoten oder eine dedizierte Umgebung, die potenziell nicht verfügbar sein könnte, beschränkt ist.

BYOC – Bring Your Own Code.

Alles, was zur Laufzeit an zusätzlichen Bibliotheken oder Modulen benötigt wird, muss die Funktion selbst mitbringen. Der Serviceanbieter stellt nur eine Ablaufumgebung (für eine spezifische Programmiersprache) zur Verfügung, ohne weitere Abhängigkeiten und/oder Erweiterungen. So steht für die Ausführung von JavaScript eben nur eine Node.js-Umgebung bereit und alle weiteren, zur Laufzeit benötigten JS-Bibliotheken (Packages), müssen die Funktionen mitbringen. Eine Java-Umgebung stellt eben nur ein JDK bereit, weitere Abhängigkeiten müssen mit der Funktion gebündelt werden, meist in einem sogenannten Fat JAR oder auch Uber JAR genannt.¹³ Sollen z. B. Groovy- oder Scala-Funktionen in einer Java-Umgebung ausgeführt werden, da diese Sprachen ebenfalls in einer JRE laufen, so müssen die jeweiligen Laufzeitbibliotheken zusammen mit dem Funktionscode in ein Uber JAR gepackt werden.

Metrics and logging are a universal right.

Wenn die Ausführung von serverlosen Services zustandslos, transient und für den Nutzer transparent ist, so muss er dennoch Details über die Ausführung selbst kennen, um ggf. Fehler feststellen und beheben zu können, die Leistung zu kontrollieren und optimieren und weitere Nutzungszahlen (Metriken) zu analysieren. Aus diesem Grund muss der Serviceanbieter Möglichkeiten zur Verfügung stellen, um Logs schreiben und auswerten und Metriken messen und nutzen zu können. Jede Ausführung einer Funktion sollte per se vom Anbieter selbst bereits geloggt werden. Inhalte der Funktion müssen von der Funktion selbst geloggt werden (siehe vorheriger Punkt „BYOC" – der Anbieter weißt ja nicht, wie die Funktion aufgebaut ist, ggf. bis auf ein einheitlich zu nutzendes Interface). Metriken wie Ausführungsdauer, Speicherallokation, CPU-Verwendung etc. müssen vom Cloud-Provider meist sowieso gemessen werden, um die Servicenutzung entsprechend abrechnen zu können. Diese Daten stellt er dann auch dem Servicenutzer zur Verfügung.

1.4 Der Weg hin zu Serverless

1.4.1 Blech

Vor rund 25 Jahren – ein Viertel Jahrhundert, Welten in Zeiten der IT – betrieben die meisten Unternehmen noch (größtenteils eigene) physische Server in ihren Rechenzentren: das sogenannte Blech. Skalierung war nicht einfach möglich und nur durch das Aufrüsten des Blechs oder durch den Kauf von neuen Servern möglich. Hardware war noch teuer und die zur Verfügung stehenden Ressourcen mussten bestmöglich genutzt werden. Dass man sich damals mal eben schnell einen Testserver hinstellte, um seine aktuelle Entwicklung zu testen, war schier unvorstellbar.

1.4.2 Virtualisierung …

Nach und nach entwickelten sich Virtualisierungstechnologien. Plötzlich war es möglich, auf einem physischen Server einen oder mehrere virtuelle Server laufen zu lassen. Die vorhandenen Ressourcen wurden besser ausgenutzt und potenzielle (und teure) Leerlaufzeiten auf einer Hardware konnte durch geschickte Platzierung von virtuellen Servern vermieden werden. Da ein virtueller Server nur aus Software bestand (bzw. immer noch besteht, das Konzept nutzen wir ja heute noch), konnte dieser Server auch leicht gesichert und im Fehlerfalle wieder hergestellt werden (sofern das Back-up funktioniert). Die Deployment-Einheiten haben sich mit den Möglichkeiten der Virtualisierung von Hardware (ganze Server, Blech) auf Software (virtuelle Instanzen) gewandelt.

1.4.3 … in der Cloud

Durch die Möglichkeit, virtuelle Server nicht nur mehr auf einem dedizierten Rechner laufen lassen zu können, und die Entwicklung der verteilten Rechnernetzwerke, der heutigen Cloud, kam man recht schnell auf die Idee, die virtuellen Server nicht mehr im eigenen Rechenzentrum auf eigener Hardware auszuführen, sondern diese in die Cloud auszulagern. Birgt der Betrieb auf eigener Hardware doch immer noch die Gefahr eines Hardwarefehlers, der nicht schnell genug behoben, bzw. der Rechner nicht schnell genug ersetzt werden kann, und so finanzielle Verluste drohen. Die Möglichkeit, öffentlich von anderen Unternehmen angebotene Rechnernetzwerke und -ressourcen nutzen zu können, vermindert dieses Risiko deutlich. Unsere Deployment-Einheiten selbst verändern sich jetzt zwar nicht unbedingt, jedoch finden sie ihren Einsatzzweck an einem anderen Ort.

Es gibt keine Cloud

Dadurch, dass nach wie vor Rechner irgendwo betrieben werden, es nur nicht mehr die eigenen