Alles über Serverless Computing

Mit der Einführung von AWS Lambda im Jahr 2014 läuft der Hype um das „Serverless Computing“ ungebrochen weiter. Und trotz der bereits vergangenen vier Jahre herrschen immer noch Verwirrung und Verunsicherungen im Markt. War es das also endgültig mit Servern? Dieser Artikel räumt mit den Mythen rund um das „Serverless Computing“ auf, beschreibt dessen Vorteile als auch Risiken und erläutert mögliche Einsatzszenarien.

Was ist Serverless Computing?

Im Rahmen des „Serverless Computing“ wird tatsächlich auf den direkten Einsatz von Servern verzichtet. Allerdings arbeiten diese als physikalischer bzw. virtueller Host weiterhin im Hintergrund. Schließlich müssen Software, Programmcode und Daten irgendwo gespeichert und betrieben werden. Hingegen muss sich ein Entwickler aber nicht mehr direkt mit ihnen beschäftigen und kann sie vernachlässigen. Stattdessen übernimmt ein Cloud-Dienst wie eine Blackbox die Arbeit. Der Entwickler lädt seinen Programmcode hoch und schreibt Funktionen. Die vollständige Administration der notwendigen Serverinfrastruktur inklusive der Server- und Betriebssystemwartung wird von dem Cloud-Dienst übernommen.

Das Stichwort hier ist Entwickler. Das ist die Zielgruppe des Serverless Computing, dessen Einsatz stetig populärer wird, um Anwendungen schnell und bequem zu entwickeln. Es geht im Kern also darum, Entwickler zu befähigen Programmcode „ohne Hürden“ oder besser ohne den Kontakt zu System-Administratoren auszuführen oder sich selbst nicht mehr mit der Provisionierung und dem Verwalten von Servern zu kümmern. Aus Enwickler-Perspektive bedeutet dies, dass mit Serverless das oft propagierte DevOps-Konzept auf DevOnly heruntergebrochen wird. Denn der letzte kleine Ops-Anteil wird von dem Serverless-Dienst übernommen.

Das klingt zunächst alles nach einem Platform-as-a-Service (PaaS). Schaut man sich Serverless-Technologien jedoch genauer an, fallen eindeutige Unterschiede zu einem PaaS auf. Im Falle eines PaaS muss ein Entwickler in seinem Programmcode die APIs des PaaS ansprechen, um im Bedarfsfall die notwendige Skalierbarkeit und Ausfallsicherheit der Anwendung sicherstellen, indem die darunterliegende verdeckte Serverinfrastruktur entsprechende Ressourcen hinzufügt und anschließend wieder freigibt. Beim „Serverless Computing“ wird dies vollständig von einem Cloud-Dienst übernommen. Der Dienst kümmert sich eigenständig um das Kapazitätsmanagement, wie die automatische Bereitstellung der notwendigen Server und weiterer Ressourcen und stellt jeder Zeit sicher, dass die Anwendung ständig ausreichend Ressourcen hat, um performant Anfragen zu beantworten.

Neben dem eigenen Programmcode muss ein Entwickler noch sogenannte „Funktionen“ erstellen. Eine Funktion enthält Anweisungen, wie auf ein Ereignis reagiert werden soll, dass eintritt (z.B. das Hochladen eines Bildes) und welche Aktion darauf folgt (z.B. automatisch einen bestimmten Filter darauf anwenden). Serverless Computing wird daher auch oft als „Event-Driven“ oder „Function as a Service“ genannt. Unterm Strich lässt sich Serverless Computing daher auch gut als eine fertige „Event Processing Engine“ innerhalb einer Blackbox beschreiben. Allerdings sind Serverless-Funktionen zustandslos. Das bedeutet, dass sie keine Abhängigkeiten zur darunterliegenden Infrastruktur besitzen. Dadurch können innerhalb kürzester Zeit viele Kopien einer einzelnen Funktion gestartet werden, die es benötigt, um die notwendige Skalierbarkeit zu einem bestimmten Zeitpunkt als Reaktion auf ein Ereignis zu erreichen. Eine weitere Eigenschaft des Serverless Computing liegt in seinem Abrechnungsmodell. Definierte Funktionen werden nur dann ausgeführt, wenn sie aufgerufen werden, nutzen nur dann die notwendigen Kapazitäten der darunterliegenden Infrastruktur und verursachen somit nur dann Kosten.
Vor- und Nachteile des Serverless Computing

Serverless Computing bringt Vorteile für eine einfache Nutzung mit sich. Allerdings sollten auch die Kompromisse beachtet werden, die dabei eingegangen werden. So ist Serverless Computing bspw. nichts für Kontrollfreaks. Wer also die automatische Skalierung und das Kapazitätsmanagements von dem Dienst übernehmen lassen möchte, muss einen eingeschränkten Freiheitsgrad in Kauf nehmen. Der Zugriff auf die virtuellen Maschinen entfällt und Änderungen an dem Betriebssystem oder der Laufzeitumgebung lassen sich ebenfalls nicht mehr vornehmen. Im Vergleich zu Serverless Computing besitzen andere Cloud-Deploymentvarianten wie IaaS (Infrastructure-as-a-Service) und PaaS (Platform-as-a-Service) spezielle Eigenschaften, die es zu berücksichtigen gilt und welche maßgeblich von dem gewünschten Kontroll-Level sowie für die Nutzung notwendigen Kenntnisstand abhängen.

IaaS
IaaS stellt 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.

PaaS
Ein PaaS abstrahiert die Infrastruktur von der Applikation. Dies führt dazu, dass sich nicht um den Aufbau und die Verwaltung der Infrastruktur gekümmert werden muss, die für die Applikation erforderlich ist. Diese Erleichterung im Rahmen der Anwendungsentwicklung und dem Management kommen mit dem Kompromiss einher, dass die meisten PaaS-Umgebungen nur spezifische Funktionen eines Anbieters enthalten, um Applikationen zu entwickeln und bereitzustellen.

Pro Serverless Computing

• Automatische Skalierung und Fehlertoleranz
• Automatisches Kapazitätsmanagement
• Flexible Ressourcenverwaltung
• Schnelle Bereitstellung der Ressourcen
• Exakte nutzungsabhängige Abrechnung der Ressourcen
• Konzentration auf den Kern des Programmcodes

Kontra Serverless Computing

• Kontrollverlust
• Erhöhtes Lock-in Risiko
• Latenzgefahr durch Einsatz selten genutzter Funktionen

Ein weiteres Risiko besteht in einem erhöhten Lock-in. Die Serverless-Dienste der Cloud-Anbieter sind proprietär und lassen sich nur in deren Umgebungen verwenden. Dennoch, ein Lock-in muss nichts Negatives sein. Wer sich ohnehin für eine Cloud-Umgebung wie AWS oder Microsoft Azure entschieden hat, der wird auch nicht vor Serverless Computing zurückschrecken. Ein Nutzer muss sich dessen lediglich bewusst sein und mit den möglichen Konsequenzen auseinandersetzen. Wer also weiterhin Kontrolle behalten will oder gar muss und vorsichtig mit dem Thema Lock-in umgeht, sollte eine Serverless Computing-basierende Architektur zunächst in einem Proof of Concept testen.

Szenarien für Serverless Computing

Um es vorweg zu nehmen, Serverless Computing adressiert neuartige Applikationen, die auf der grünen Wiese entwickelt werden. Komplexe und insbesondere geschäftskritische Anwendungen, die aktuell noch auf traditionelle Systemarchitekturen setzen, sind dafür nicht geeignet. Dasselbe gilt für statische Workloads, deren Anfragevolumen vorhersagbar ist. Stattdessen sollten zunächst zwar wichtige aber unkritische Projekte ausgewählt werden.

So setzt bspw. Storm Reply, der Cloud-Dienstleister hinter der Ferrero-Kampagne „Face of Kinder“, für die zweite Phase des Projekt-Rollouts in die Ländermärkte Ungarn, Mexiko und Israel auf Serverless Computing, genauer AWS Lambda. Ferrero nutzt die „Face of Kinder“ Kampagne, um über das neue lokale Gesicht auf der Kinderschokoladeverpackung abstimmen zu lassen. Hierzu laden Eltern Bilder ihrer Kinder auf eine Plattform, auf welcher dann die Abstimmung erfolgt.

Für das initiale Projekt in Brasilien kam noch eine typische Cloud-Infrastruktur-Architektur zum Einsatz. Mit dem Wechsel auf Serverless Computing wurden neben der Beschleunigung des Rollouts ebenfalls die Gesamtkosten um 75 Prozent reduziert. Dabei spielt die Projekt-DNA eine entscheidende Rolle, um die Serverless-Vorteile auszunutzen. Die Kampagne läuft nur innerhalb eines begrenzten Zeitraums und verfügt über sehr schwankende Zugriffszahlen. Zudem ist die Nachfrage so gut wie nicht vorhersagbar.

Andere Unternehmen wie Thomsen Reuter, Coca-Cola, Nordstrom, Periscope, Netflix und Associated Press setzen ebenfalls AWS Lambda in Produktion ein. Die ProSieben Tochter Glomex hat von einer Server-zentrierten auf eine Serverless-Umgebung umgestellt und verarbeitet darüber 5 Millionen Datensätze pro Tag.

Anbieter von Serverless Computing

Die Anzahl der am Markt existierender Anbieter mit Serverless Computing Diensten ist in den vergangenen Jahren stetig gewachsen. Hierzu gehören z.B. Alibaba, Databricks, Iron.io, Joyent, Oracle, PubNub, Red Hat, Serverless oder Webtask. Alle haben jedoch eines gemeinsam. Ihre Angebote spielen im weltweiten Vergleich und insbesondere bei uns Deutschland derzeit noch eine untergeordnete Rolle. Ein ernsthafter Blick lohnt sich aktuell nur auf die Angebote der großen Public Cloud-Anbieter Amazon Web Services, Microsoft Azure, Google Cloud und IBM Cloud, welche Serverless Computing Dienste bereits seit längerer Zeit im Portfolio haben.

Amazon Web Services

• Service Name: AWS Lambda
• Verfügbar seit: 2014
• Status: Generell Verfügbar
• Betriebsmodell: Public Cloud
• Programmiersprachen: Node.js, Python, Java, C#
• Kunden: Thomsen Reuter, Coca-Cola, Nordstrom, Periscope, Netflix, Associated Press, Ferrero, Glomex, The Seattle Times
• Web: https://aws.amazon.com/lambda

AWS gilt als Innovationstreiber und Entwickler hinter dem Serverless-Konzept und hat Lambda als zentralen Bestandteil seines Cloud-Portfolios integriert. Lambda kann als Herzstück und Zugangspunkt zu fast jedem vorhandenen AWS Service betrachtet werden, der sich mit Lambda integrieren lässt. Das macht es für Kunden gleichzeitig sehr bequem aber auch gefährlich, in einen Lock-in zu gelangen.

Microsoft Azure

• Service Name: Azure Functions
• Verfügbar seit: 2016
• Status: Generell Verfügbar
• Betriebsmodell: Public Cloud/ On-Premise
• Programmiersprachen: Node.js, Python, PHP, JS, C#, F#
• Kunden: Accuweather, Plexure, FujiFilm, FirstGlas, Quest, Carmax
• Web: https://azure.microsoft.com/en-us/services/functions

Azure Functions ist Microsofts Gegenstück zu AWS Lambda und wurde etwa zwei Jahre später auf den Markt gebracht. Microsoft arbeitet hart daran, die funktionalen als auch konzeptionellen Lücken gegenüber AWS zu schließen. Allerdings ist das Microsoft Cloud-Portfolio im Vergleich zu dem von AWS noch deutlich kleiner, wodurch der Funktionsumfang von Azure Functions derzeit noch eingeschränkter ist.

IBM Cloud

• Service Name: Cloud Functions
• Verfügbar seit: 2016 (ehemals: Bluemix OpenWhisk)
• Status: Generell Verfügbar
• Betriebsmodell: Public Cloud/ On-Premise
• Programmiersprachen: Node.js, Python, Java, Swift, PHP, Go. Andere Sprachen wie C, C++, Rust etc. können genutzt werden, indem eigene Binaries oder Docker-Images mitgebracht werden.
• Kunden: GreenQ, articoolo, SiteSpirit, Kone
• Web: https://www.ibm.com/cloud/functions

IBM Cloud Functions ist 2016 unter dem Namen IBM Bluemix OpenWhisk auf dem Markt erschienen. IBM setzt hier wieder einmal auf seine langjährige Open-Source-Geschichte, wodurch sich eine eigene IBM Cloud Functions Instanz (Apache OpenWhisk) auf dem eigenen Server betreiben lässt. Cloud Functions verfügt über eine integrierte Docker-Container Unterstützung und lässt sich zusammen mit IBMs Watson Services einsetzen. Anders als die Serverless-Dienste AWS Lambda, Microsoft Azure Functions und Google Cloud Functions, können IBM Cloud Functions von jedem externen API-angestoßenen Ereignis ausgelöst werden. Dabei kann es sich auch einfach nur um einen neuen Eintrag innerhalb eines RSS-Feed handeln. Weiterhin unterstützt IBM Cloud Functions Apples Programmiersprache Swift, womit der Serverless-Dienst als Backend für iPhone- und iOS-Anwendungen dienen kann.

Google Cloud

• Service Name: Cloud Functions
• Verfügbar seit: 2016
• Status: Beta Version
• Betriebsmodell: Public Cloud
• Programmiersprachen: Node.js, JavaScript
• Kunden: Meetup, Semios
• Web: https://cloud.google.com/functions

Googles Serverless-Dienst Cloud Functions erschien im Februar 2016 und befindet sich weiterhin im Beta-Status, was den Funktionsumfang erklärt. So lassen sich Funktionen lediglich in JavaScript schreiben und nur auf Google’s internen Event-Bus auslösen. Hinzu kommt, dass Cloud Storage und Cloud Pub/Sub die einzigen Google-eigenen Cloud-Dienste sind, die derzeit mit Cloud Functions integriert werden können. Andere geschäftsbedingte Trigger sind nicht vorhanden.

Fazit & Ausblick

Unternehmen investieren viel Zeit und Aufwand in den Betrieb und die Verwaltung von IT-Infrastruktur. Ein Kostenfaktor, der nicht auf Ihre Unternehmensziele einzahlt. Sich nicht länger mit dem Infrastrukturmanagement zu beschäftigen hat daher von Beginn zu einem der Vorteile gezählt, Applikationen in die Public Cloud zu überführen. Betrachtet man zudem die technologische Entwicklung von Cloud-Infrastruktur über die Zeit, sieht man einen deutlichen Trend zu mehr Einfachheit für den Kunden. Angefangen bei virtuellen Maschinen, über IaaS, zu PaaS und Containern sind wir nun bei Serverless angekommen. Denn für den Nutzer ist die beste Infrastrukturumgebung im Grunde genommen diejenigen, die für ihn nicht sichtbar ist.

Serverless Computing nimmt dem Kunden die Bürde, sich mit Infrastruktur auseinanderzusetzen und ausschließlich auf die Entwicklung und dass Verhalten der Applikation zu konzentrieren. Die Einfachheit, welche dieses Konzept innerhalb der Softwareentwicklung mit sich bringt, wird dazu führen, dass es sich schneller reifen und etablieren wird als alle anderen Paradigmen zuvor. Das unterstreicht die stetig steigende Adaptionsrate. Die Nutzung von AWS Lambda hat sich von 12 Prozent im Jahr 2016 auf 23 Prozent im Jahr 2017 fast verdoppelt.

Und mit AWS Fargate steht bereits die nächste Evolutionsstufe vor der Tür. Der Dienst ermöglicht es Kunden einen Container (Amazon ECS oder Amazon EKS) zu betreiben, ohne Server oder Cluster zu verwalten. Also im Prinzip ein „Serverless Container Service“. Der nächste Meilenstein, Software bequemer zu entwickeln.