Einfache Funktionen erleichtern die Entwicklung, während die ereignisgesteuerte Ausführung den Betrieb kostengünstiger macht. Hier sind die Vor- und Nachteile von Serverless Computing! [...]
Entwickler verbringen unzählige Stunden damit, Geschäftsprobleme mit Code zu lösen. Dann ist das Ops-Team an der Reihe, unzählige Stunden damit zu verbringen, um zuerst herauszufinden, wie man den Code erhält, den die Entwickler auf allen verfügbaren Computern ausführen, und dann sicherzustellen, dass diese Computer reibungslos funktionieren. Dieser zweite Teil ist dabei wirklich eine endlose Aufgabe. Warum überlässt man diesen Teil also nicht einfach jemand anderem?
In den letzten zwei Jahrzehnten hat sich eine Menge Innovation in der IT – virtuelle Maschinen, Cloud Computing, Container – darauf konzentriert, sicherzustellen, dass Sie nicht viel über die zugrunde liegende physische Maschine nachdenken müssen, auf der Ihr Code läuft. Serverless Computing ist ein immer beliebteres Paradigma, das dieses Verlangen zu einem logischen Abschluss bringt: Mit Serverless Computing müssen Sie nichts über die Hardware oder das Betriebssystem wissen, auf dem Ihr Code läuft, denn das alles wird von einem Dienstanbieter für Sie erledigt.
Was ist Serverless Computing?
Serverless Computing ist ein Ausführungsmodell für die Cloud, bei dem ein Cloud-Provider dem Benutzer dynamisch nur die für die Ausführung eines bestimmten Codes benötigten Rechenressourcen und Speicherkapazitäten zuweist und dann in Rechnung stellt. Natürlich sind immer noch Server beteiligt, aber ihre Bereitstellung und Wartung wird vollständig vom Provider übernommen. Chris Munns, Amazon’s Anwalt für Serverless, sagte auf einer Konferenz 2017, dass es aus der Sicht des Teams, das den Code schreibt und einsetzt, „keine Server gibt, die verwaltet oder bereitgestellt werden müssen. Dazu gehört nichts, was blankes Metall, virtuell oder ein Container wäre – alles, worum es bei der Verwaltung eines Hosts, dem Patchen eines Hosts oder dem Umgang mit irgendetwas auf Betriebssystemebene geht, ist in der serverlosen Welt nicht von Belang.“
Wie der Entwickler Mike Roberts erklärt, wurde der Begriff einst für so genannte Back-End-as-a-Service-Szenarien verwendet, bei denen sich eine mobile App mit einem Back-End-Server verbinden würde, der vollständig in der Cloud gehostet wird. Aber wenn man heute von Serverless Computing oder einer Serverless-Architektur spricht, meint man damit Function-as-a-Service-Angebote, bei denen ein Kunde einen Code schreibt, der nur die Geschäftslogik anpackt und bei einem Anbieter hochlädt. Dieser Anbieter kümmert sich um die gesamte Hardwarebereitstellung, das Management virtueller Maschinen und Container und sogar um Aufgaben wie Multithreading, die oft in den Anwendungscode integriert sind.
Serverlose Funktionen sind ereignisgesteuert, d.h. der Code wird nur aufgerufen, wenn er durch eine Anfrage ausgelöst wird. Der Anbieter berechnet nur die von dieser Ausführung in Anspruch genommene Rechenzeit und nicht eine pauschale monatliche Gebühr für die Wartung eines physischen oder virtuellen Servers. Diese Funktionen können miteinander verbunden werden, um eine Verarbeitungspipeline zu erstellen, oder sie können als Komponenten einer größeren Anwendung dienen und mit anderem Code interagieren, der in Containern oder auf herkömmlichen Servern läuft.
Vor- und Nachteile von Serverless Computing
Aus dieser Beschreibung sollten zwei der größten Vorteile von Serverless Computing ersichtlich sein: Entwickler können sich in erster Linie auf die Geschäftsziele des von ihnen geschriebenen Codes konzentrieren, statt auf infrastrukturelle Fragen; und Unternehmen zahlen nur für die Rechenressourcen, die sie tatsächlich auf sehr detaillierte Weise nutzen, anstatt physische Hardware zu kaufen oder Cloud-Instanzen zu mieten, die meist im Leerlauf bleiben.
Wie Bernard Golden betont, ist dieser letzte Punkt besonders für ereignisgesteuerte Anwendungen von Vorteil. Beispielsweise kann es sein, dass eine Anwendung die meiste Zeit im Leerlauf ist, aber unter bestimmten Bedingungen viele Ereignisanforderungen auf einmal verarbeiten muss. Oder Sie haben eine Anwendung, die Daten verarbeitet, die von IoT-Geräten mit eingeschränkter oder intermittierender Internetverbindung gesendet werden. In beiden Fällen würde der traditionelle Ansatz die Bereitstellung eines robusten Servers erfordern, der Spitzenlasten bewältigen könnte – aber dieser Server wäre die meiste Zeit über nicht ausgelastet. Mit einer serverlosen Architektur zahlen Sie nur für die Serverressourcen, die Sie tatsächlich nutzen. Serverless Computing wäre auch gut für bestimmte Arten der Stapelverarbeitung. Eines der kanonischen Beispiele für einen Anwendungsfall ohne Serverarchitektur ist ein Dienst, der eine Reihe von einzelnen Bilddateien hochlädt, verarbeitet und an einen anderen Teil der Anwendung weiterleitet.
Der vielleicht offensichtlichste Nachteil von serverlosen Funktionen ist, dass sie absichtlich vergänglich und, wie AlexSoft es ausdrückt, „ungeeignet für langfristige Aufgaben“ sind. Die meisten serverlosen Anbieter lassen Ihren Code nicht länger als ein paar Minuten laufen, und wenn Sie eine Funktion starten, speichert sie keine zustandsbehafteten Daten von zuvor ausgeführten Instanzen. Ein damit zusammenhängendes Problem ist, dass serverloser Code bis zu mehreren Sekunden Zeit in Anspruch nehmen kann, um sich zu entfalten – kein Problem für viele Anwendungsfälle, aber wenn Ihre Anwendung eine geringe Latenzzeit erfordert, seien Sie hiermit gewarnt.
Viele der anderen Nachteile, wie von Rohit Akiwatkar und Gary Arora aufgezeigt, haben mit der Anbieterbindung zu tun. Obwohl es Open-Source-Optionen gibt, wird der serverlose Markt von den großen kommerziellen Cloud-Anbietern dominiert, wie wir gleich noch näher erläutern werden. Das bedeutet, dass Entwickler oft die Tools ihrer Anbieter verwenden, was es schwierig macht, diese zu wechseln, wenn sie damit nicht mehr zufrieden sind. Und da so viel von Serverless Computing per Definition auf der Infrastruktur des Herstellers stattfindet, kann es schwierig sein, Serverless Code in eigene Entwicklungs- und Testpipelines zu integrieren.
Serverlose Anbieter: AWS Lambda, Azure Functions und Google Cloud Functions
Das moderne Zeitalter des Serverless Computing begann 2014 mit der Einführung von AWS Lambda, einer Plattform, die auf Amazons Cloud-Service basiert. Microsoft folgte 2016 mit Azure Functions. Google Cloud Functions, das sich seit 2017 in der Beta-Phase befand, erreichte im Juli 2018 schließlich den Produktionsstatus. Die drei Dienste haben leicht unterschiedliche Einschränkungen, Vorteile, unterstützte Sprachen und Vorgehensweisen. Rohit Akiwatkar verfügt über eine gute und detaillierte Übersicht über die Unterschiede zwischen den drei. Ebenfalls im Einsatz ist IBM Cloud Functions, das auf der Open Source Apache OpenWhisk Plattform basiert.
Unter allen serverlosen Computerplattformen ist AWS Lambda die bekannteste und hatte offensichtlich die meiste Zeit, sich zu entwickeln und zu reifen.
Serverlose Stapel
Wie in vielen Softwarebereichen hat sich auch in der serverlosen Welt die Entwicklung von Softwarestapeln vollzogen, die verschiedene Komponenten zusammenführen, die für den Aufbau einer serverlosen Anwendung erforderlich sind. Jeder Stapel besteht aus einer Programmiersprache, in der Sie den Code schreiben möchten, einem Anwendungs-Framework, das eine Struktur für Ihren Code bereitstellt, und einer Reihe von Triggern, die die Plattform versteht und verwendet, um die Codeausführung einzuleiten.
Sie können zwar verschiedene spezifische Angebote in jeder dieser Kategorien kombinieren und abgleichen, es gibt jedoch Einschränkungen, je nachdem, welchen Anbieter Sie verwenden, mit einigen Überschneidungen. Für Sprachen können Sie beispielsweise Node.js, Java, Go, C# und Python auf AWS Lambda verwenden, aber nur JavaScript, C# und F# arbeiten nativ mit Azure-Funktionen zusammen. Wenn es um Trigger geht, hat AWS Lambda die längste Liste, aber viele von ihnen sind spezifisch für die AWS-Plattform, wie Amazon Simple Email Service und AWS CodeCommit; Google Cloud Functions können inzwischen durch generische HTTP-Anfragen ausgelöst werden. Paul Jaworski wirft einen detaillierten Blick auf die Stapel der drei großen Produkte.
Serverlose Frameworks
Es lohnt sich, ein wenig auf den Framework-Teil der Gleichung zu achten, da dieser viel darüber aussagt, wie Sie am Ende Ihre Anwendung erstellen. Amazon hat dafür sein eigenes natives Angebot, das Open Source Serverless Application Model (SAM), aber es gibt auch andere, von denen die meisten plattformübergreifend und auch Open Source sind. Als eine der beliebtesten wird allgemein Serverless bezeichnet und betont, dass es dieselbe Erfahrung für jede unterstützte Plattform bietet, d.h. AWS Lambda, Azure Functions, Google Cloud Functions und IBM OpenWhisk. Ein weiteres beliebtes Angebot ist Apex, das helfen kann, manche Sprachen, die für bestimmte Anbieter sonst nicht verfügbar sind, mit ins Spiel zu bringen.
Serverlose Datenbanken
Wie bereits erwähnt, ist eine Besonderheit beim Arbeiten mit serverlosem Code, dass es keinen persistenten Zustand gibt, was bedeutet, dass die Werte lokaler Variablen nicht über Instanzierungen hinweg bestehen bleiben. Alle persistenten Daten, auf die Ihr Code zugreifen muss, müssen an anderer Stelle gespeichert werden, und die Auslöser, die in den Stacks der großen Anbieter verfügbar sind, beinhalten alle Datenbanken, mit denen Ihre Funktionen interagieren können.
Einige dieser Datenbanken werden selbst als serverlos bezeichnet. Das bedeutet, dass sie sich ähnlich verhalten wie andere serverlose Funktionen, die wir in diesem Artikel besprochen haben, mit der offensichtlichen Ausnahme, dass Daten auf unbestimmte Zeit gespeichert werden. Aber ein Großteil des Verwaltungsaufwands für die Bereitstellung und Pflege einer Datenbank entfällt. Wie der Entwickler Jeremy Daly es ausdrückt: „Alles, was Sie tun müssen, ist, einen Cluster zu konfigurieren, und dann werden alle Wartungsarbeiten, Patches, Backups, Replikationen und Skalierungen automatisch für Sie erledigt.“ Wie bei Function-as-a-Service-Angeboten zahlen Sie nur für die Rechenzeit, die Sie tatsächlich nutzen, und die Ressourcen werden je nach Bedarf auf und ab gesplittet, um die Nachfrage zu decken.
Die drei großen serverlosen Anbieter bieten jeweils ihre eigenen serverlosen Datenbanken an: Amazon hat Aurora Serverless und DynamoDB, Microsoft hat Azure Cosmos DB und Google hat Cloud Firestore. Dies sind jedoch nicht die einzigen verfügbaren Datenbanken. Nemanja Novkovic hat Informationen über weitere Angebote.
Serverless Computing und Kubernetes
Container helfen, serverlose Technologie unter der Oberfläche zu betreiben, aber der Aufwand für ihre Verwaltung wird vom Hersteller übernommen und ist für den Benutzer unsichtbar. Viele sehen in Serverless Computing die Möglichkeit, viele der Vorteile von containerisierten Mikroservices zu nutzen, ohne sich mit deren Komplexität auseinandersetzen zu müssen, und beginnen sogar, von einer Post-Container-Welt zu sprechen.
In Wahrheit werden Container und Serverless Computing mit ziemlicher Sicherheit noch viele Jahre nebeneinander existieren, und tatsächlich können serverlose Funktionen in der gleichen Anwendung wie containerisierte Microservices existieren. Kubernetes, die beliebteste Container-Orchestrierungsplattform, kann auch serverlose Infrastrukturen verwalten. Mit Kubernetes können Sie sogar verschiedene Arten von Diensten in einem einzigen Cluster integrieren.
Serverless offline
Die Aussicht, mit dem serverlosen Computing zu beginnen, könnte Sie etwas einschüchtern, da es den Anschein hat, dass Sie sich bei einem Anbieter anmelden müssen, um zu experimentieren und zu sehen, wie es funktioniert. Aber keine Angst: Es gibt Möglichkeiten, serverlosen Code offline auf Ihrer eigenen lokalen Hardware auszuführen. So bietet beispielsweise das AWS SAM eine lokale Funktion, mit der Sie den Lambda-Code offline testen können. Und wenn Sie das serverlose Anwendungs-Framework verwenden, schauen Sie sich serverless-offline an, ein Plug-in, mit dem Sie Code lokal ausführen können. Viel Spaß beim Experimentieren!
*Josh Fruhlinger ist ein Schriftsteller und Redakteur, der in Los Angeles lebt.
Be the first to comment