Im Prinzip ist es nichts Besonderes, wenn Cloud-Anbieter ständig eine neue Sau durchs Dorf treiben. Die aktuelle Sau hört auf den Namen "Serverless Infrastructure" oder auch "Serverless Computing". Das Außergewöhnliche daran ist jedoch, dass sie einige Verwirrung stiftet. Ist nun das Ende der Server angebrochen? Bei weitem nicht - viel mehr verschiebt sich innerhalb des Cloud-Stacks mal wieder etwas weiter nach oben.

Serverless Infrastructure - was ist das eigentlich?

Wie der Name bereits vermuten lässt, wird im Rahmen einer "Serverless Infrastructure" tatsächlich auf den direkten Einsatz von Servern verzichtet. Diese arbeiten als physikalischer Host oder virtuelle Ressource selbstverständlich weiterhin im Hintergrund, schließlich müssen Programmcode und Daten irgendwo gespeichert und betrieben werden. Allerdings muss sich ein Entwickler nicht mehr direkt mit den Servern beschäftigen, er kann sie sogar vollständig vernachlässigen. Stattdessen übernimmt der Cloud-Service eines Anbieters in Form einer "Blackbox" die Arbeit. Der Entwickler lädt seinen Code hoch und der Cloud-Service übernimmt die vollständige Administration der dafür benötigten Serverinfrastruktur inklusive der Server- und Betriebssystemwartung.

Klingt bekannt, oder? Auf den ersten Blick erscheint das "Serverless"-Konzept wie der Ansatz des Platform-as-a-Service (PaaS). Betrachtet man es jedoch etwas genauer, fallen eindeutige Unterschiede zu einem PaaS auf.

Während der Nutzung eines PaaS muss ein Entwickler innerhalb seines Programmcodes mit den APIs des PaaS interagieren, um im Bedarfsfall die notwendige Skalierbarkeit und Ausfallsicherheit der Anwendung sicherzustellen. Konkret fügt die darunterliegende (für ihn nicht sichtbare) Serverinfrastruktur entsprechende Ressourcen hinzu und gibt diese anschließend wieder frei. Der Entwickler muss also eng mit der Plattform selbst kommunizieren. Innerhalb einer "Serverless Infrastructure" übernimmt dies vollständig eine Blackbox in Form eines Cloud-Service. Das bedeutet, dass der Serverless-Service sich um die Bereitstellung der notwendigen Server und weiterer Ressourcen kümmert und zu jeder Zeit sicherstellt, dass die Anwendung ständig ausreichend Ressourcen zur Verfügung hat, um performant Anfragen zu beantworten. Der Cloud-Service organisiert hierbei unter anderem die automatische Skalierung der Server-Infrastruktur, des Speichers, des Netzwerks und anderer Ressourcen und übernimmt somit eigenständig das Kapazitätsmanagement.

Neben dem Hochladen des eigenen Programmcodes muss ein Entwickler noch sogenannte "Funktionen" schreiben. Eine Funktion beschreibt, wie auf ein Ereignis, etwa das Hochladen eines Bildes, reagiert werden soll. Beispielsweise könnte automatisch ein bestimmter Filter darauf angewendet werden. So lassen sich etwa auch vom Anbieter bereitgestellte Microservices oder Platform-Services ansprechen sowie externe oder selbst entwickelte Services integrieren. Serverless Computing wird daher auch oft im selben Atemzug mit dem Begriff "Event-Driven" genannt.

Wer über Programmiererfahrung verfügt, dem wird diese Idee bekannt vorkommen. Prozeduren und Funktionen werden schon seit jeher geschrieben, welche dann über einen Event-Handler auf Ereignisse reagieren und entsprechende Aktionen einleiten bzw. ausführen. Eine Serverless Infrastructure lässt sich daher gut als eine fertige "Event Processing Engine" innerhalb einer Blackbox beschreiben. Allerdings muss man festhalten, dass Serverless-Funktionen zustandslos sind. Das bedeutet, dass sie keine Abhängigkeit von der darunterliegenden Infrastruktur besitzen. Damit lassen sich innerhalb kürzester Zeit viele Kopien einer einzelnen Funktion starten, die man benötigt, um die notwendige Skalierbarkeit zu einem bestimmten Zeitpunkt als Reaktion auf ein Ereignis zu erreichen. So ist es etwa kein Geheimnis, dass der Support der Amazon Web Services (AWS) für eine extreme Skalierung den AWS Load Balancer (Amazon ELB) manuell "vorwärmen" muss, damit dieser große unerwartete Lastspitzen verarbeiten kann. Mit dem AWS Serverless-Service AWS Lambda lässt sich dieses Problem automatisiert lösen.

Eine weitere Eigenschaft eines Serverless-Service liegt in dessen Abrechnungsmodell. So werden die definierten Funktionen nur dann ausgeführt, wenn sie aufgerufen werden und nutzen auch nur dann die notwendigen Kapazitäten der darunterliegenden Infrastruktur.

"Serverless": Nichts für Kontrollfreaks

Für die Entwicklung und den Betrieb von Applikationen in der Cloud eignen sich neben dem "Serverless" Konzept sowohl IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service) als auch Container-Technologien. Jede Deployment-Variante besitzt allerdings ihre speziellen Eigenschaften, die es zu berücksichtigen. Sie hängen maßgeblich vom gewünschten Kontroll-Level und vom benötigten Kenntnisstand ab. (Lesen Sie hierzu auch IaaS vs. PaaS vs. Container: Moderne Anwendungsentwicklung in der Cloud.

IaaS

IaaS stellt Entwicklern Basis-Ressourcen wie Rechenleistung, Speicherplatz und Netzwerk zur Verfügung, mit denen sich eine eigene virtuelle Infrastruktur aufbauen lässt, um Applikationen zu betreiben. Eine IaaS-Umgebung bietet insofern einen hohen Kontrollgrad, da sich auf den virtuellen Maschinen alles selbst installieren und zu 100 Prozent konfigurieren lässt. Dennoch ist für jede IaaS-Umgebung ein spezielles Wissen über die Cloud-Infrastruktur eine Grundvoraussetzung, um anhand von Tools die Umgebung und Applikationen zu verwalten. Für IaaS ist somit ein breiter Kenntnisstand erforderlich, da der gesamte Stack bedient werden muss, inklusive Installation, Konfiguration, Wartung und Betrieb der gesamten virtuellen Infrastruktur sowie der Betriebssysteme. Weiterhin ist das Thema "Infrastructure as Code" ein wesentlicher Bestandteil während der Nutzung von IaaS. Mehr hierzu kann unter "Infrastructure as Code": Der Admin 1.0 klickt - Der Admin 2.0 programmiert nachgelesen werden.

PaaS

Ein PaaS abstrahiert die darunterliegende Infrastruktur von der Applikation. Dies führt dazu, dass sich Entwickler nicht um den Aufbau und die Verwaltung der Infrastruktur kümmern müssen, die für die Applikation erforderlich ist. Hierfür stellt eine PaaS-Umgebung eine standardisierte Plattform bereit, die der Entwicklung, dem Test und dem Deployment dient und Funktionen für das Konfigurationsmanagement beinhalte. Diesen Erleichterungen bezüglich Anwendungsentwicklung und Management steht allerdings der Nachteil gegenüber, dass die meisten PaaS-Umgebungen nur spezifische Funktionen eines Anbieters enthalten, um Applikationen zu entwickeln und bereitzustellen. Trotz eines einfachen und kontrollierbaren Entwicklungsprozesses müssen Entwickler auf andere Ressourcen und Tools wie zum Beispiel externe APIs und Microservices, Middleware und native APIs zurückgreifen.

Container

Container stellen Möglichkeiten bereit, um paketierte Software-Stacks portabel einzusetzen. Ein Großteil traditioneller PaaS-Umgebungen setzt auf Container-Technologien als Basis, um Multi-Tenant Applikationen auf einer Shared-Infrastructure zu ermöglichen. Hierbei nutzen sie in den meisten Fällen Web-Container für eine bestimmte Programmiersprache wie Java, Rails, Ruby, Python, Django oder NodeJS, um darin den Programmcode zu speichern. Technologien wie Docker oder LXC kommen zum Einsatz, um die Container zu verwalten und sorgen für die Isolation zwischen den einzelnen Web-Containern. Diese Form der Architektur bietet sich gut für Web-Applikationen an, die aus einem Web-Front-End und entsprechenden Datenbanken im Backend bestehen. Aber Container können nicht nur für Web-Applikationen eingesetzt werden, sondern bieten sich ebenfalls für jede Art von Applikation wie Microservices, Big Data, Analytics und auch Legacy Anwendungen an.