Unternehmen investieren viel Zeit und Aufwand in den Betrieb und die Verwaltung ihrer IT-Infrastruktur. Das ist ein Kostenfaktor, der nicht auf ihre Unternehmensziele einzahlt. Dieses Management einem Dienstleister zu überlassen, war daher von Beginn an einer der wesentlichen Argumente, wenn es darum ging, Applikationen in die Public Cloud zu überführen. Auch die technische Entwicklung der Cloud-Infrastruktur hat dazu geführt, dass das IT-Management für Unternehmen immer einfacher wird. Angefangen hat dieser Trend mit virtuellen Maschinen, heute ist er beim Serverless Computing angekommen. Denn für Unternehmen ist die beste Infrastrukturumgebung im Grunde die, die sie gar nicht bemerken.

Serverless Computing verzichtet tatsächlich auf den direkten Einsatz von Servern. Allerdings arbeiten diese als physikalischer oder auch virtueller Host weiterhin im Hintergrund. Schließlich müssen Software, Programmcode und Daten irgendwo ihren Speicherort finden. Doch der Entwickler kann sie vernachlässigen und muss sich nicht mehr mit ihnen beschäftigen. Er schreibt Funktionen und lädt seinen Programmcode hoch. Die vollständige Administration der notwendigen Server-Infrastruktur inklusive der Server- und Betriebssystemwartung übernimmt ein Cloud-Dienst wie eine Blackbox.

Die Zielgruppe des Serverless Computings sind deshalb auch Entwickler. Sie nutzen die Cloud-Dienste immer öfter, um ­Anwendungen schnell und bequem zu entwickeln. Sie können ­ihren Programmcode ohne Hürden veröffentlichen – auch ohne den Kontakt zu System-Administratoren, Provisionierung und das Verwalten von Servern. Aus Enwicklerperspektive bedeutet dies, dass das Serverless Computing das oft propagierte DevOps-Konzept auf Dev-only herunterbricht. Denn der letzte kleine ­Ops-Anteil übernimmt hierbei der Serverless-Computing-Dienst.

Das klingt zunächst alles nach Platform-as-a-Service (PaaS). Ein PaaS abstrahiert die Infrastruktur von der Applikation, sodass sich ein Entwickler nicht mehr um ihren Aufbau und ihre Verwaltung kümmern muss. Das erleichtert zwar die Anwendungsentwicklung und das Management, dafür enthalten die meisten PaaS-Umgebungen aber nur spezifische Funktionen eines Anbieters. Infrastructure-as-a-Service (IaaS) stellt dagegen Basis-Ressourcen wie Rechenleistung, Speicherplatz und Netzwerk zur Verfügung, mit denen Entwickler eine eigene virtuelle Infrastruktur aufbauen können, 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. Im Vergleich zu Serverless Computing besitzen Cloud-Deployment-Varianten wie IaaS und PaaS spezielle Eigenschaften, die vom gewünschten Kontrollgrad abhängen sowie von der Frage, ob die für die Nutzung notwen­digen Kenntnisse vorhanden sind.

Bei einem genaueren Blick auf die Serverless-Computing-Technologien fallen jedoch eindeutige Unterschiede zu 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 ­sicherzustellen. Dazu muss er der darunterliegenden, verdeckten Server-Infrastruktur entsprechende Ressourcen hinzufügen und anschließend wieder freigeben. Bei Serverless Computing übernimmt dies der Cloud-Dienst vollständig. Der Dienst kümmert sich eigenständig um das Kapazitätsmanagement – wie die ­automatische Bereitstellung der notwendigen Server und weiterer Ressourcen – und stellt zu jeder Zeit sicher, dass die Anwendung genug Ressourcen hat, um Anfragen leistungsstark zu beantworten.

Neben dem eigenen Programmcode muss ein Entwickler beim Serverless Computing auch Funktionen erstellen. Eine Funktion enthält Anweisungen, wie ein Programm auf ein Ereignis reagieren soll – etwa, dass es beim Hochladen eines Bildes (Ereignis) automatisch einen Filter anwenden soll (Funktion). Serverless Computing heißt daher auch „Event-Driven“ oder „Function as a Service“. Unter dem Strich lässt sich Serverless Computing also auch gut als eine fertige „Event-Processing-Engine“ innerhalb einer Blackbox beschreiben. Allerdings sind Serverless-Computing-Funktionen zustandslos. Das bedeutet, dass sie keine Abhängigkeiten zur darunterliegenden Infrastruktur besitzen. Dadurch lassen sich innerhalb kürzester Zeit viele Kopien einer Funktion starten, um die notwendige Skalierbarkeit zu einem bestimmten Zeitpunkt als Reaktion auf ein Ereignis zu erreichen. Eine weitere Besonderheit des Serverless Computing liegt in seinem Abrechnungsmodell. Definierte Funktionen laufen nur dann ab, wenn das entsprechende Ereignis eintritt. Sie nutzen also nur in diesen Fällen die notwendigen Kapazitäten der darunterliegenden Infrastruktur und verursachen somit auch nur dann Kosten.

Serverless Computing bringt einige Vorteile mit sich. Dazu gehört die automatische Skalierung und Fehlertoleranz sowie das automatische Kapazitäts-Management, die flexible Ressourcenverwaltung und die schnelle Bereitstellung der Ressourcen. Daneben kann die nutzungsabhängige Abrechnung der Ressourcen ein Pluspunkt sein. Und natürlich ist die Tatsache von Vorteil, dass sich Entwickler auf den Kern ihres Programmcodes konzentrieren können.

Allerdings sollten Entwickler auch die Kompromisse bedenken, die sie dabei eingehen. So ist Serverless Computing zum Beispiel nichts für Kontrollfreaks. Wer die automatische Skalierung und das Kapazitätsmanagement einem Serverless-Computing-Dienst überlässt, muss eine Einschränkung seiner Freiheit in Kauf nehmen: Er kann nicht mehr auf die virtuellen Maschinen zugreifen oder das Betriebssystem sowie die Laufzeitumgebung ändern. Daneben gibt es die Gefahr von Verzögerungen, wenn selten genutzte Funktionen zum Einsatz kommen.

Ein weiteres Risiko ist die Gefahr eines Lock-in-Effektes. ­Die Serverless-Computing-Dienste sind proprietär und lassen sich nur in der Umgebung der Anbieter verwenden. Doch ein Lock-in muss nichts Negatives sein: Wer sich ohnehin für eine Cloud-­Umgebung wie AWS oder Microsoft Azure entschieden hat, wird auch nicht vor Serverless Computing zurückschrecken. Ein Entwickler muss sich dessen lediglich bewusst sein und sich mit den möglichen Konsequenzen auseinandersetzen. Wer also weiterhin Kontrolle behalten will oder vorsichtig mit dem Thema Lock-in umgeht, sollte eine Architektur auf Basis von Serverless Computing zunächst in einem „Proof of Concept“ testen.

Generell gilt: Komplexe und vor allem auch geschäftskritische Anwendungen, die derzeit noch auf traditionelle Systemarchitekturen setzen, sind für Serverless-Computing-Szenarien eher nicht geeignet. Dasselbe gilt für statische Workloads, deren Anfragevolumen vorhersagbar ist. Wer ins Serverless Computing einsteigt, sollte zunächst zwar wichtige, aber unkritische Projekte auswählen.
Ein gutes Beispiel für eine Anwendung, die sich für Serverless Computing eignet, ist die der Kampagne „Face of Kinder“: Ferrero suchte dabei nach dem neuen lokalen Gesicht auf der Verpackung seiner Kinderschokolade. Eltern konnten ­hierzu ein Bild ihres Kindes auf einer Plattform hochladen, auf der dann alle Nutzer abstimmen konnten. Für die zweite Phase des ­Projekt-Rollouts in die Ländermärkte Ungarn, Mexiko und ­Israel setzte der Cloud-­Dienstleister Storm Reply auf Serverless ­Computing, ­genauer gesagt auf AWS Lambda. Für das initiale Projekt in ­Brasilien kam noch eine typische Cloud-Infrastruktur-­Architektur zum Einsatz. Mit dem Wechsel auf Serverless ­Computing beschleunigte Storm Reply nicht nur den Rollout, sondern senkte auch die Gesamtkosten um 75 Prozent. Durch seine Projekt-DNA konnte die ­Kampagne die Vorteile des Serverless Computing voll ausnutzen: Sie lief nur innerhalb eines begrenzten Zeitraumes und hatte stark schwankende Zugriffszahlen. Zudem ließ sich die Nach­frage so gut wie gar nicht vorhersagen. Viele weitere Unter­nehmen – etwa ­Thomsen Reuter, Coca-Cola, Nordstrom, ­Periscope, Netflix oder Associated Press – setzen AWS Lambda auch in der Produktion ein. Die Prosieben-Tochter Glomex stellte etwa von einer ­serverzentrierten auf eine serverlose Umgebung um und verarbeitet so fünf Millionen Datensätze pro Tag.

Kein Wunder daher, dass die Zahl der Serverless-Computing-­Anbieter in den letzten Jahren stetig gewachsen ist. Hierzu gehören zum Beispiel 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 genauer Blick lohnt sich daher derzeit nur auf die Angebote der großen Public-Cloud-Anbieter Amazon Web Services, Microsoft Azure, Google Cloud und IBM Cloud, die die Serverless-Computing-Dienste schon seit längerem in ihrem Portfolio haben.

AWS gilt als Innovationstreiber und Entwickler hinter dem ­Serverless-Computing-Konzept. Lambda lässt sich als Herzstück und Zugangspunkt zu fast jedem vorhandenen AWS-­Service ­betrachten. Das macht die Entwicklungsarbeit für Kunden sehr ­bequem. Es droht aber auch die Gefahr eines Lock-in. AWS ist eine Public Cloud und unterstützt die Programmiersprachen Node.js, Python, Java, C#. Zu den Kunden zählen unter anderem so namhafte Marken wie Thomsen Reuter, Coca-Cola, Nordstrom, Periscope, Netflix, Associated Press, Ferrero, Glomex oder The ­Seattle Times.

Azure Functions ist Microsofts Gegenstück zu AWS Lambda und kam 2016, also rund zwei Jahre später, auf den Markt. Microsoft arbeitet daran, die funktionalen und auch konzeptionellen Lücken gegenüber AWS zu schließen. Allerdings ist das Cloud-Portfolio von Microsoft im Vergleich deutlich kleiner. Der Funktionsumfang von Azure Functions ist damit derzeit vergleichsweise eingeschränkt. Das Betriebsmodell ist Public Cloud oder On-Premise. An Programmiersprachen sind Node.js, Python, PHP, JS, C# oder F# möglich. Kunden, die Microsoft Azure bereits einsetzen, sind unter anderem Accuweather, Plexure, FujiFilm, FirstGlas, Quest oder Carmax.

IBM Cloud Functions kam ebenfalls 2016 unter dem Namen IBM Bluemix Openwhisk auf den Markt. 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 IBM Watson Services einsetzen. Anders als die Serverless-Computing-Dienste AWS Lambda, Microsoft Azure Functions und Google Cloud Functions kann jedes externe API-­angestoßene Ereignis eine IBM Cloud Functions auslösen. Dabei kann es sich auch einfach nur um einen neuen Eintrag in einem 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. Als Betriebsmodell kommen Public Cloud oder On-Premise zum Einsatz. Möglich sind die Programmiersprachen Node.js, Python, Java und Swift. Zu den Kunden von IBM Cloud gehören zum ­Beispiel Greenq, articoolo oder Sitespirit.

Googles Serverless-Computing-Dienst Cloud Functions erschien im Februar 2016 und befindet sich weiterhin im Beta-Status. Das erklärt auch den Funktionsumfang: So lassen sich Funktionen lediglich in Javascript schreiben und nur auf Googles internen Event-Bus auslösen. Hinzu kommt, dass Cloud Storage und Cloud Pub/Sub die einzigen Google-eigenen Cloud-Dienste sind, die Entwickler derzeit mit Cloud Functions integrieren können. Andere geschäftsbedingte Trigger sind nicht vorhanden. Google Cloud ist eine Public Cloud. Meetup und Semios sind beispielsweise bereits Kunden des Serverless-Computing-Dienstes.

Mit Serverless Computing können sich Unternehmen und ihre Programmierer – sofern sie damit leben können, gewisse ­Freiheiten aufzugeben – ganz und gar auf die Entwicklung ihrer Applikation konzentrieren. Das bringt eine Einfachheit mit sich, die dazu führt, dass sich Serverless Computing schneller ent­wickeln und etablieren wird, als alle anderen Paradigmen zuvor. Das unterstreicht die stetig steigende Adaptionsrate: Die Zahl der AWS-­Lambda-Nutzer beispielsweise hat sich von 12 Prozent (2016) auf 23 ­Prozent (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. Das dürfte dann der nächste Meilenstein sein, um Software noch bequemer zu entwickeln.