Clouds 20.05.2019

Die Evolution geht weiter! Serverless Computing verändert das Application Development nachhaltig.

Es ist so eine Sache mit Trends: Kaum hat man verstanden, was sich hinter einem Buzzword verbirgt, ist der Hype auch schon wieder verflogen. Gerade in Zeiten eines Umbruchs, wie ihn die IT-Branche derzeit erlebt, verliert man leicht den Überblick und das Gefühl für das wirklich Wichtige. Gutes Beispiel: Serverless Computing. Wir erklären, was das eigentlich ist.

Artikel teilen

Als neues Paradigma in der Softwareentwicklung sorgt der eventgetriebene Programmieransatz gerade für viel Aufmerksamkeit in der Branche. Die steigende Akzeptanz für agile Arbeitweisen bereitet diesem sehr offenen Ansatz einen fruchtbaren Boden. Hat dieser Hype das Potenzial zum Game Changer? Fest steht: Nie zuvor war eine Technologie näher am realen Kundenverhalten. Das macht eine sehr schnelle Reaktion auf neue Marktanforderungen möglich. Und nur selten zeichnete sich ein größeres Sparpotenzial für Unternehmen ab – nicht nur bei Entwicklern, sondern auch bei deren Kunden, die darauf basierende Lösungen später im Einsatz haben werden.

 

Serverless Computing revolutioniert die Software-Entwicklung.

 

Doch wo liegen die großen Sparpotenziale und wie sehen die damit verbundenen Herausforderungen aus? Um sich darüber einen Überblick zu verschaffen, lohnt der Blick auf die vergangenen vier bis fünf Jahre:  Im Serverbereich gab es lange keine Alternative zur On-Premise-Lösung. Teure Server wurden für die unterschiedlichsten Aufgabenbereiche einzeln angeschafft, mussten konfiguriert und gewartet werden. In den aufwändig gekühlten Serverräumen und Rechenzentren standen sie oft zu Dutzenden und verrichteten mehr oder weniger zuverlässig ihren Dienst. Anschaffungskosten, laufende Kosten und administrativer Aufwand waren immens.

 

Mit der Entwicklung der Cloud-Dienste wurden die klassischen Anwendungen wie File-Server und Netzwerkinfrastruktur nach und nach aus den internen Rechenzentren zu externen Dienstleistern ausgelagert: Infrastructure as a Service (IaaS) war geboren. Seitdem folgt man diesem Ansatz konsequent und erreichte mit Platform as a Service (PaaS) und Backend as a Service (BaaS) eine weitgehende Rationalisierung im Rechenzentrum. Das revolutionierte auch die Art, wie Anwendungen heute entwickelt werden. Leichtgewichtige Virtualisierungstechniken – wie etwa die Containerisierung aufgesetzt auf PaaS – ermöglichten das einfache Kopieren und Wiederverwenden von Anwendungen. Docker-Container zum Beispiel beinhalten die komplette Applikation. Man schiebt sie einfach von Maschine zu Maschine, ohne dabei das Betriebssystem oder die Hardware berücksichtigen zu müssen. PaaS macht es möglich. Der administrative Aufwand für die Entwickler wird so zunehmend geringer.

 

Serverless Computing, auch Function as a Service (FaaS) genannt, ist der nächste Schritt in dieser Entwicklung. Es ist nur im Zusammenspiel von agilen Entwicklungswerkzeugen und der Flexibilität der Cloud möglich.

 

Zwei Ansätze lösen ein Problem.

 

Sowohl auf PaaS-Lösungen basierende Virtualisierungen – zum Beispiel mit Docker – als auch die Virtualisierung einzelner Funktionen im serverlosen Ansatz lösen zunächst einmal die gleichen Probleme: Infrastruktureller Overhead wird durch die Virtualisierung in Containern oder Funktionen abgebaut. Energie- und Kosteneinsparungen sind die Folge. Das erhöht die Skalierbarkeit einzelner Anwendungsbestandteile und verbessert die Wiederverwendbarkeit bereits funktionierender Codes in anderen Projekten. So werden Redundanzen abgebaut und die Entwicklung künftiger Projekte begünstigt, da man einmal geschriebenen Code mit nur wenig oder keinen Anpassungen in andere integrieren kann.

 

Viele Ähnlichkeiten, große Unterschiede.

 

Bei allen Gemeinsamkeiten unterscheiden sich die beiden Techniken aber auch grundlegend beim Anwendungsgebiet, bei der Nutzung selbst und auch bei den Abrechungsmodalitäten. Während bei PaaS-Lösungen eine Instanz noch rund um die Uhr laufen muss, um die Dienste bereitzustellen, werden in Serverless-Umgebungen Instanzen einer Funktion durch einen sogenannten Event gestartet. Die Funktion wird abgearbeitet und im Anschluss wird die Instanz wieder heruntergefahren. Diese Vorgehensweise hat natürlich Einfluss auf die Abrechnung der Leistung. Denn im Gegensatz zum plattformgetriebenen „Always-On“-Ansatz bei PaaS-Lösungen wird bei der eventgetriebenen Verwendung von Funktionen beim FaaS die Zeit abgerechnet, in der die einzelnen Funktionen tatsächlich auf die Rechenleistung des Servers zugegriffen haben.

 

Unterschiede bestehen auch in der Nutzung der beiden Techniken: Bei PaaS-Lösungen erzeugt man zum Beispiel mit Docker virtuelle Container. Sie enthalten alles, was die Applikation in der Anwendung benötigt, inklusive aller Abhängigkeiten, jedoch nicht das Betriebssystem selbst. Gespeichert wird dieser Container im sogenannten Docker Image. Durch einfaches Kopieren kann dieses Image auf einem beliebigen anderen Server installiert und ausgeführt werden. Dieser Vorgang dauert nur wenige Sekunden und macht das Deployment neuer Versionen sehr schnell. Innerhalb dieses Images können theoretisch beliebig viele Container, auch Microservices genannt, gestartet werden. Limitiert wird die Skalierbarkeit nur durch das Betriebssystem des gemieteten Servers.

 

Anders als bei PaaS und Docker, muss der Entwickler mit FaaS nicht erst das Image schreiben, bevor man es auf den Server hochlädt. Funktionen sind sehr einfache kleine Konstrukte, die theoretisch direkt nach dem Upload einsatzbereit sind. Das reduziert die benötigte Zeit für das Deployment gegenüber zum Beispiel Docker noch einmal dramatisch auf wenige Millisekunden. Der Programmierer muss sich keine Gedanken mehr über Abhängigkeiten machen. Das komplette Management erledigt der Hoster. Sollten mehrere Zugriffe auf die gleiche Funktion erfolgen, werden einfach so viele Instanzen der gleichen Funktion gestartet, wie tatsächlich benötigt werden. Auch für FaaS gilt, dass theoretisch eine unendliche Zahl an Instanzen einer Funktion möglich sind. Werden für die Ausführung dieser Instanzen zusätzliche Ressourcen benötigt, fügt der Hoster sie dynamisch hinzu oder schiebt die Funktion auf einen anderen, leistungsfähigeren Server. Auch hier erfolgt das Deployment innerhalb weniger Millisekunden und der Anwender bekommt davon im Idealfall nichts mit. Dadurch wird die Anwendung nicht nur beinahe unendlich skalierbar, sondern auch zu einem sehr hohen Grad ausfallsicher: Versagt ein Server den Dienst, wird die Funktion einfach auf einen anderen übertragen und die Anwendung ist wieder erreichbar.

 

Der größte Unterschied zwischen einer Funktion und einem Microservice, wie er zum Beispiel mit Docker realisiert werden kann, ist aber die maximale Serverkapazität und Ausführungsdauer, die einer einzelnen Funktion zur Verfügung gestellt wird. Da bei PaaS die Serverinstanz dauerhaft aktiviert ist, kann eine Anwendung auch theoretisch langfristig oder dauerhaft laufen. FaaS hingegen berechnet die anfallenden Kosten nach der Ausführungszeit der Funktion. Lang andauernde Operationen sind daher natürlich nicht erwünscht. Die einzelnen Anbieter haben jeweils unterschiedliche Limits für die maximale Dauer einzelner Funktionen. In der Regel sind es fünf bis fünfzehn Minuten. Eine für Serverless Computing ideale Funktion wird demnach innerhalb weniger Millisekunden ausgeführt und nur sehr selten aufgerufen. Aber nicht nur die Zeit, sondern auch die weiteren Systemressourcen sind für einzelne Funktionen zumeist stark limitiert. Häufig stehen nur wenige Gigabyte Arbeitsspeicher oder nur wenige Hundert Megabyte Festplattenspeicher zur Verfügung. Für Anwendungen, die darüber hinaus mehr Ressourcen benötigen, muss auf PaaS-, oder IaaS-Lösungen zurückgegriffen werden.

 

Wie funktioniert Serverless Computing oder FaaS?

 

Serverless Computing schließt sich nahtlos an die bestehenden Cloud-Technologien an und integriert Techniken in das Leistungsspektrum des Hosters, die Entwickler beim PaaS noch manuell umsetzen mussten. Die Ähnlichkeit von FaaS und PaaS kommt also nicht von ungefähr. Neu im Vergleich zu den bereits bekannten Lösungen ist jedoch der ereignisgetriebene Ansatz. Der Anwendung liegt ein sehr einfaches Programmiermodell zugrunde: Tritt ein bestimmtes Ereignis ein, führe die Anweisungen aus. Theoretisch vergleichbar ist das Prinzip mit den Regeln in einem E-Mail-Client. Es wird geprüft, ob eine bestimmte Vorgabe erfüllt ist („Wenn der Betreff das Wort Information enthält“). Wenn ja, wird eine Funktion gestartet und eine Reaktion ausgeführt („Verschiebe die E-Mail in den Ordner Informationen“).

 

Funktionen in Apache OpenWisk bestehen beispielhaft aus drei Komponenten: ein Auslöser, eine Aktion, eine Regel.

 

  • Ein Auslöser ist eine Klasse von Ereignissen, sogenannte Trigger, auf die die Funktion reagieren soll (Der Betreff enthält das Wort „Information“).
  • Eine Aktion ist ein Event Handler, der eine funktionale Logik beinhaltet und dessen Code als Reaktion auf das Ereignis ausgeführt wird (Verschiebe die E-Mail in den Ordner Informationen).
  • Eine Regel verbindet die Auslöser mit der Aktion (Wenn der Auslöser wahr ist, dann führe die Aktion aus).

 

Dieses einfache Wenn-Dann-Konstrukt definiert bereits eine Funktion. Je nach Plattform kann man diese über eine REST-API in der Befehlszeile oder mit Hilfe eines Funktions-Designers im Web erstellen. Dazu stehen unterschiedliche Programmiersprachen zur Verfügung. Der Entwickler kann so in der von ihm gewohnten Umgebung bleiben und dennoch von den Vorzügen profitieren. JavaScript, Java, Python und PHP sind nur einige gängige Vertreter. Darüber hinaus enthalten die Plattformen allesamt auch weitere Tools zur Unterstützung von Paketierung, Katalogdiensten und den gängigen Container-Bereitstellungsdiensten.

 

Serverless Computing hat viele Vorteile – und einige gravierende Nachteile.

 

Zu den Vorteilen des serverlosen Ansatzes zählt ganz klar das Abrechnungsmodell: Weil kein Server kontinuierlich vorgehalten werden muss, erfolgt die Abrechnung nach Nutzungszeit. Das reduziert nicht nur signifikant die Kosten, die im tatsächlichen Einsatz entstehen, sondern auch die Kosten, die bisher für Administration und Anschaffung angefallen sind. Viele Hoster bieten zudem kostenlose Einstiegskontingente an, mit denen sich kleine Anwendungen mit wenig Zugriffen sehr schnell und einfach umsetzen lassen. Eine anfangs sehr flache Lernkurve und eine sehr aktive Community erleichtern den Einstieg. Der ereignisgetriebene Entwicklungsansatz ist überdies sehr nah am tatsächlichen Nutzerverhalten: Ein Nutzer löst mit einer Aktion eine Funktion aus. Neue Nutzerereignisse sind schnell implementiert und auf Veränderungen in der Nutzung kann schnell reagiert werden.

 

Eine Besonderheit der serverlosen Software-Entwicklung sind die sogenannten Cold-Starts: Bevor eine Funktion ausgeführt werden kann, benötigt auch sie einen Container, der, ähnlich dem von Docker, sämtliche Abhängigkeiten und statischen Dateien enthält. Ist der Container nicht vorhanden, zum Beispiel weil die Funktion längere Zeit nicht mehr aufgerufen wurde, erzeugt ihn die Plattform neu. Je nach verwendeter Programmiersprache, dem Code der Funktion und der Größe der Abhängigkeiten, kann dieser Vorgang zwischen wenigen Millisekunden und mehreren Sekunden dauern. Ein Umstand, den man bei der Programmierung nicht aus den Augen verlieren darf. Für den Anwender können sich hier unter Umständen unangenehme Pausen in der Nutzung der Software ergeben. Wurde die Funktion aber vor Kurzem aufgerufen, kann jederzeit beinahe in Echtzeit eine weitere Instanz gestartet werden.

 

Aufgrund der Besonderheiten von FaaS eignet es sich nicht für jeden Anwendungsfall. Sind bereits im Vorfeld lange laufende Tasks zu erwarten, die zusätzliche Ressourcen benötigen, sollte direkt eine andere Lösung gewählt werden. Auch lassen sich bestehende Standard-Software und ältere Eigenentwicklungen häufig nicht oder nur mit sehr hohem Aufwand portieren. Eine monolithische Anwendung in die Einzelkomponenten zu zerlegen, in Microservices und Funktionen aufzuteilen und anschließend wieder zu kombinieren ist eine komplizierte und aufwändige Aufgabe. Im Besonderen der Aufwand rechtfertigt in der Regel die Neuprogrammierung mit den neuen Techniken.

 

Die Vor- und Nachteile von Serverless Computing auf einen Blick.

 

Vorteile

 

Nachteile

 

Kostenoptimiert durch Abrechnungsmodell nach Nutzung.

Vendor-Lock-In verhindert den Wechsel
zwischen Abietern Zum Beispiel von Azure
Funstions zu AWS Lambda oder anderen.

Infrastrukturunabhängig.

Einarbeitungsaufwand schwankt je
nach eingesetzten Tools.

Leicht verschiebbar in
andere Umgebungen.

Ungeeignet für Langzeit-Tasks und
Anwendungen, die häufig genutzt werden.

Nahezu endlos skalierbar.

Debugging des Codes gestaltet sich schwieriger,
weil Möglichkeiten zum Monitoring fehlen.

Fokus liegt auf Geschäftslogik.

 

Ausfallsicher und fehlertolerant.

 

Ereignisgesteuert.

 

Fokus liegt auf Geschäftslogik.

 
Verbessert die "Time to Market" 

 

Fazit.

Serverless Computing, auch als FaaS oder „Event Driven Computing“ bezeichnet, ist eine noch junge Technologie, deren große Zeit wohl gerade erst beginnt. Obwohl es der Name verspricht, kommt sie natürlich nicht komplett ohne einen Server aus. Für Entwickler und Unternehmen bedeutet serverlos, dass sie sich nicht mehr um den Betrieb, die Verwaltung und das Management kümmern müssen. Diese Aufgaben übernimmt der Cloudanbieter. Auch handelt es sich nicht um die eine große Neuentwicklung, sondern ist vielmehr das Ergebnis einer konsequenten Weiterentwicklung der bestehenden Cloud-Technologien mit Berührungspunkten in beinahe allen IT-Bereichen. Die wirkliche Neuerung ist die Verknüpfung von nahezu sofort verfügbaren Ressourcen der Cloud mit der agilen Entwicklung verteilter Anwendungen.

 

Inzwischen gibt es auch eine breite Basis an bekannten Herstellern wie Amazon (AWS Lambda), Google (Google Cloud Functions), Microsoft (Azure Functions) und IBM (public IBM Cloud), die mit ihren Angeboten den Markt dominieren und hier auch in Zukunft tonangebend sein werden. Diese aktuellen Serverless-Technologien bieten Anwendern eine hohe Abrechnungsgranularität, detaillierte Einblicke und Kontrolle sowie kostengünstige Möglichkeiten, beliebige Funktionen einer Anwendung bei Bedarf auszuführen.

jens-kaesbauer.png
Jens Käsbauer
Communications und Content Specialist