How-To

Serverless Computing: Buzzword oder ernsthafte Infrastruktur-Technologie?

(Shutterstock/ Simon Bratt)

Buzzword oder ernsthafte Infrastruktur-Technologie? Es herrscht viel Verwirrung um Serverless Computing. Wir erklären, was genau sich hinter dem Begriff verbirgt – und welche Einsatzszenarien denkbar sind.


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.

Was ist Serverless Computing?

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.

Eine Serverless-Architektur – hier: AWS Lambda – besteht aus einer Menge von Eingangsparametern die, je nach Wert (Trigger), in ­Echtzeit einen oder mehrere ­Batchjobs anstoßen – deshalb wird Serverless Computing auch als „Event-Driven“ beschrieben. (Grafik: Amazon)

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.

Vor- und Nachteile des Serverless ­Computings

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.

Verschiedene Einsatzszenarien

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.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.