Serverless lernen

Einführung in Serverless

Abbildung I-1. "Ancient Wisdom", aus dem Webcomic FaaS and Furious von Forrest Brazeal, 2019

Anfangen... Anfangen... Wie fange ich an? Ich bin hungrig. Ich sollte mir einen Kaffee holen. Kaffee würde mir beim Nachdenken helfen. Vielleicht sollte ich erst etwas schreiben und mich dann mit Kaffee belohnen. Kaffee und ein Muffin. Okay, ich muss also die Themen festlegen. Vielleicht einen Bananen-Nuss-Muffin. Das ist ein guter Muffin.

Charlie Kaufman, Adaption

Was ist Serverless?

Serverless ist die Idee, dass du eine serverbasierte Anwendung ausführen kannst, ohne einen Server verwalten zu müssen. Wenn du diesen Text vor dir hast, ist es gut möglich, dass du mit Serverless bereits vertraut bist. Aber wie erklärst du es anderen? Konzentrierst du dich auf das, was es ist: eine neue Art, Anwendungscode auszuführen, oder auf das, was es nicht ist: die Verwaltung von Servern? Erzählst du den Leuten von den Schwächen oder den Stärken? Wenn dein Weg zum Erfolg mit Serverless andere mit einbezieht, und das ist wahrscheinlich der Fall, machst du dir vielleicht Gedanken darüber, wie du die Vorteile am besten verkaufst, ohne dabei jemanden zu verschrecken. Denn Serverless steckt noch in den Kinderschuhen und wird ständig weiterentwickelt. Einige seiner Schwächen werden bleiben, aber das sind Kompromisse, die du eingehen musst, um die Vorteile und Funktionen zu nutzen, die du sicher lieben wirst.

Da die Serverless-Gemeinschaft von den schnellen Verbesserungen einer Spitzentechnologie profitiert, kann es schwierig sein, bewährte Methoden zu entwickeln und zu übernehmen. Ich hoffe, dass ich dir nicht nur die wichtigsten bewährten Methoden im Bereich Serverless vorstellen kann, sondern dass ich dir auch helfen kann, bewährte Methoden zu entwickeln und anzuwenden. Ich möchte, dass du genug über die Regeln weißt, um sie sicher zu brechen.

Das erste Angebot von Amazon Web Service (AWS) war der Simple Storage Service (S3). Mit S3 kannst du so viele Dateien speichern, wie du willst, ohne dass du eine Infrastruktur bereitstellen musst. Es ist eine serverlose Speicherung. Vielleicht erinnerst du dich daran, wie S3 die Speicherung beliebiger Dateien vereinfacht hat: Du erstellst einen Bucket (die S3-Abstraktion für eine Sammlung von Dateien), gibst jeder Datei einen eindeutigen Namen und das war's. Du musst dich nicht mehr um die Bereitstellung von Laufwerken, Backups oder die vielen anderen Probleme beim Speichern von Dateien kümmern. Sicher, S3 eignet sich nicht für alle Zwecke der Speicherung von Dateien; die maximale Dateigröße beträgt 5 GB. Zumindest galt das bis 2010, als die maximale Größe auf 5 TB erhöht wurde. Wie haben sie das gemacht? AWS nimmt dir die ganze Arbeit ab und teilt Dateien, die größer als 5 GB sind, in mehrere Chunks auf, ohne dass der Nutzer etwas davon merkt. Das ist der Vorteil eines serverlosen Systems. Die Ähnlichkeiten zum modernen serverlosen Computing sind verblüffend: eine Allzwecklösung für ein allgemeines Problem (das nicht für alle Anwendungsfälle geeignet ist), nahtlose Verbesserungen im Hintergrund (die in der Regel als Hacks von Kunden implementiert wurden) und ein Abrechnungsmodell nach Nutzung.

Der Begriff " serverlos" ist eine falsche Bezeichnung, denn es sind Server beteiligt. In Wirklichkeit gibt es keinen Serverless, sondern nur den Container von jemand anderem. Die Serverless Working Group der Cloud Native Computing Foundation fasst dies am besten in einem Whitepaper zusammen:¹

Serverloses Computing bedeutet nicht, dass wir keine Server mehr brauchen, um Code zu hosten und auszuführen, und es bedeutet auch nicht, dass Betriebsingenieure nicht mehr benötigt werden. Vielmehr geht es darum, dass die Nutzer von Serverless Computing keine Zeit und Ressourcen mehr für die Bereitstellung, Wartung, Aktualisierung, Skalierung und Kapazitätsplanung von Servern aufwenden müssen. Stattdessen werden all diese Aufgaben und Fähigkeiten von einer serverlosen Plattform übernommen und vollständig von den Entwicklern und IT-/Betriebsteams abstrahiert. So können sich die Entwickler/innen auf das Schreiben der Geschäftslogik ihrer Anwendungen konzentrieren.

Weniger Zeit für den Aufbau der Infrastruktur und mehr Zeit für die Bereitstellung von Funktionen. Aus diesem Grund steigt die Nachfrage nach Serverless. Es gibt zwar Grenzen, aber die verschwinden mit dem Fortschritt der Technologie, und es könnte sein, dass Funktionen zu den neuen Containern werden, da Cloud Compute zunehmend verwaltet wird. Aber wie sind wir zu gekommen?

Geschichte von Serverless

Googles App Engine war eines der ersten populären Anwendungsbeispiele für Serverless. Sie wurde 2008 auf den Markt gebracht und war damit zu früh für die moderne Welle der serverlosen Nutzung. Viele Entwickler/innen sahen App Engine als zu restriktiv an und hielten es eher für ein Hobbyangebot von Google. Tatsächlich wurde die App Engine, obwohl sie 2008 auf den Markt kam, erst 2011 aus der Preview genommen. Aber sie war ihrer Zeit so weit voraus, dass sie, wenn du eine Google Cloud Function erstellst (zumindest in Python), deine Funktion in ein App-Engine-kompatibles Paket verpackt (mit Flask) und sie auf diese Weise ausführt.

Der Begriff " serverless" machte erstmals 2012 in einem Artikel von Ken Fromm von Iron.io die Runde.² Fromm behauptete, dass sich Webanwendungen von monolithischen Mustern zu vollwertigen verteilten Systemen mit lose gekoppelten Komponenten entwickeln würden - worauf wir im nächsten Kapitel eingehen werden. Fromm machte seine Vorhersage mehr als zwei Jahre vor der Veröffentlichung von Lambda durch AWS. Aber mehr als sechs Jahre vor Lambda und vier Jahre vor diesem Artikel wurde möglicherweise das erste moderne serverlose System eingeführt. Serverlose Angebote sind älter als der Begriff.

Die Landschaft der Cloud-Provider

Du kannst den Cloud-Provider für das Projekt, an dem du arbeitest, vielleicht nicht auswählen. Vielleicht bist du auch so wählerisch, dass du nur bei Unternehmen arbeitest, die bestimmte Cloud-Provider nutzen. Wir leben in einer Zeit, in der der Wettbewerb unter den Anbietern groß ist. Sie finden ständig neue Dimensionen, in denen sie miteinander konkurrieren, wie z. B. Preis, Leistung, Kapazität, Skalierbarkeit usw. Diese Phase wird jedoch nicht ewig andauern, da das Geschäft natürlich von einem hohen Wachstum in einem aufstrebenden Markt in eine Phase übergeht, in der die Rentabilität der Entwicklung neuer Funktionen, die Gewinnung von Kunden über den Preis und sogar die Support- und Engineering-Ressourcen nicht mehr attraktiv sind, und diese Dinge werden so schnell gestrichen, wie man "Aktionärsrendite" sagen kann.

Denke an die Kosten für die Speicherung und das Netzwerk, insbesondere für den Datenaustausch. Und manchmal kommen diese Kosten noch hinzu, wenn du externe Anbieter für Dinge wie Logging oder Monitoring nutzt. Sogar die Übertragung von Daten zwischen Regionen oder Verfügbarkeitszonen einer bestimmten Region kann genauso viel kosten wie die Übertragung über das öffentliche Internet und kann mit einem Klick auf ein Kästchen wie "Multi-AZ-Verfügbarkeit" verschlüsselt werden.

Wie einfach ist es, auf einen Knopf zu klicken und eine Datenbank zu haben, die in Rechenzentren auf der ganzen Welt verfügbar ist? Ist das überhaupt etwas, das deine Organisation braucht oder das sie aufgrund von Datenschutzgesetzen nutzen darf? Du mietest nicht einfach ein Standardangebot. Auch wenn es so aussieht, bezahlst du für ein Produkt. Beurteile es als solches. Denke auch an die "Cloud-Dienste", die vielleicht nicht in dein mentales Modell eines Cloud-Dienstes passen. Zum Beispiel wird Google Meet als ein Google Cloud-Produkt angesehen, das sogar als telemedizinisch geeignet vermarktet wird. Das Gleiche gilt für Google Maps. Amazon bietet die Möglichkeit, mit Satelliten zu kommunizieren und alles von einem Gerät in der Größe eines gebundenen Buches bis hin zu einem ganzen Sattelschlepper zu deinem Standort zu bringen, um die Migration größerer Datensätze in die Cloud zu erleichtern. Microsoft bietet viele fortschrittliche Funktionen rund um seine Office-Produkte, die für die Integration mit der Software, die bereits von einigen in deinem Unternehmen genutzt wird, wichtig sein könnten.

Zuverlässigkeit, Verfügbarkeit, Disaster Recovery

Welche Art von SLAs/Garantien bietet der Cloud-Provider? Wie sieht seine Erfolgsbilanz aus? Welche Abhilfemaßnahmen sind vorgesehen, wenn der Anbieter seinen Verpflichtungen nicht nachkommt? Google ist dafür bekannt, dass seine Dienste zu lange in der Beta-Phase bleiben, während AWS in der Regel eine Vorschau anbietet, die zwar zuverlässiger ist, aber noch einige gut dokumentierte scharfe Kanten hat.

Überlege auch, wie einfach es ist, Zuverlässigkeit und Verfügbarkeit auf dem Fundament und den angebotenen Diensten aufzubauen.

Das Netzwerk zwischen den Präsenzpunkten könnte von Interesse sein, wenn du planst, einen wirklich globalen Dienst zu betreiben. Das liegt vielleicht außerhalb deines Fachwissens und sogar deines Wohlfühlbereichs, aber einige dieser Entscheidungen kannst du treffen, indem du einen Vertrauensvorschuss in die richtige Richtung gibst und dir bewusst machst, dass alle damit verbundenen Probleme verstanden werden. Der beste Weg, diese Probleme und Überraschungen zu vermeiden, ist eine gut gepflegte Dokumentation.

Amazon Web Services

Amazon Web Services (AWS) ist seltsamerweise nicht mehr als ein Rechenzentrum mit APIs. Der Grund dafür ist das Dienstleistungsmandat von Amazon, das besagt, dass alle Teams Dienste entwickeln müssen und diese sehr unternehmensähnlichen Systeme für die öffentliche Nutzung öffnen. Das ist die einzige Erklärung, die mir einfällt und die erklärt, warum es so viele scharfe Kanten und seltsame Macken hat. Es ist fast so, als würdest du als Ingenieur bei Amazon ein Projekt auf der grünen Wiese aufbauen, und dies ist der interne Servicekatalog. Solltest du dich für Amazon als primären Cloud-Provider entscheiden, hilft dir diese Mentalität dabei, das Beste aus der Anbieterbindung herauszuholen, um den maximalen Erfolg zu erzielen. AWS hat den größten Servicekatalog, auch wenn das manchmal zu seinem eigenen Nachteil ist.

Google Cloud Plattform

Google Cloud Platform (GCP) ist ein leistungsstarker Cloud-Konkurrent, der für Außenstehende die größte Annäherung an Googles eigene Infrastruktur darstellt. Kubernetes ist eine Neuentwicklung, die auf der internen Borg-Plattform basiert und dem Infrastruktur-as-a-Service-Angebot folgt. Zumindest war das früher der Fall. Während sich der Cloud-Krieg aufheizt, hat Google mehr konkurrenzfähige Produkte auf den Markt gebracht, die sich direkt an die Nutzer der öffentlichen Cloud richten, anstatt seine internen Angebote neu zu lancieren, nachdem sie einige Jahre lang im Einsatz waren.

Microsoft Azure

ist eine gute Wahl, wenn dein Unternehmen bereits auf Microsoft setzt. Wenn dein Unternehmen zum Beispiel Sharepoint nutzt, ist dies die einfachste Möglichkeit, um erweiterte Workflows oder benutzerdefinierte Logik als Reaktion auf das gemeinsame Dateisystem deines Unternehmens auszulösen.

Tipp

Du musst dich nicht für einen der drei großen Anbieter entscheiden, um serverlos zu arbeiten. Wenn dein Unternehmen Kubernetes verwendet, gibt es eine Reihe von Open-Source-Optionen, mit denen du Funktionen wie Container ausführen kannst. Oder noch besser: Du kannst Container so betreiben, als wären sie Funktionen. Knative, eine dieser Optionen, ist die Grundlage für Google Cloud Run. Du musst dich also nicht ausgeschlossen fühlen, wenn dein Unternehmen nicht in der Public Cloud ist oder sich ganz auf Kubernetes konzentriert hat. Der Betrieb von Kubernetes kann bereits einige Vor- und Nachteile mit sich bringen, die du in Betracht ziehen solltest, wenn du andere Optionen hast.

Die Stärken von Serverless

Einige der Stärken von Serverless liegen in der Veränderung des Fokus von einer Anwendung als Einsatzeinheit hin zu einem kleineren und feinkörnigeren Modell von einzelnen Funktionen. Du kannst dich immer noch dafür entscheiden, eine ganze monolithische Webanwendung als eine Funktion bereitzustellen und sie pro Aufruf eine API-Anfrage ausführen zu lassen, oder du kannst deine Anwendungen in einzelne Funktionen zerlegen, um die Vorteile von Serverless voll auszuschöpfen. Das sind nicht die einzigen beiden Möglichkeiten, denn du kannst dich auch in der Mitte treffen und eine Funktion pro Dienst/Mikroservice verwenden. Aber das ist dasselbe wie der Einsatz von Containern: Du bekommst nicht alle Vorteile von Serverless, aber du bekommst auch die Nachteile. Andererseits sind einige der Vorteile von Serverless solche, die du nicht willst oder brauchst, und werden daher zu Problemen. So wie jede Münze zwei Seiten hat, werden einige dieser Vorteile direkt mit einer Schwäche verbunden sein.

Erhöhte Skalierbarkeit, Sicherheit und Verlässlichkeit

Diese ist ein zentrales Merkmal der serverlosen Erfahrung. Du musst nicht für zukünftige Kapazitäten planen, abgesehen von den Service-Limits deines Cloud-Providers und der Interaktion mit nicht-serverlosen Komponenten oder Systemen. In einem Projekt, in dem ich Serverless eingesetzt habe, gab es zum Beispiel eine große Marketingkampagne für neue Nutzer. Ich erfuhr es erst am nächsten Tag, was nicht ideal ist, aber Lambda und Amazon DynamoDB übernahmen die gesamte Last, ohne dass ich etwas unternahm oder davon wusste. Du musst dich nur um die Sicherheit kümmern, die dir für die Vergabe von Berechtigungen zur Verfügung steht, sowie um deinen Anwendungscode und die gebündelten Bibliotheken. Wenn du engagierte Teams hast, die sich um die Server kümmern, auf denen dein Anwendungscode läuft, profitierst du von den Skaleneffekten, die für maximale Betriebszeit sorgen.

Du zahlst nur für das, was du nutzt

Eine der attraktivsten Eigenschaften von serverlosem Computing ist, dass du nicht für Leerlaufzeiten zahlst. Wenn dein System komplett serverlos ist und in einem bestimmten Abrechnungszeitraum nicht genutzt wird, beträgt die Gesamtrechnung für Compute 0 US-Dollar. Die Preisgestaltung ist besser vorhersehbar, wenn du für eine bestimmte Anzahl von Aufgaben statt für Instanzstunden bezahlt wirst. Wenn du eine Anwendung hast, die nur während der regulären Geschäftszeiten genutzt wird und Container oder andere Instanzen verwendet, kannst du sie am Wochenende automatisch herunterfahren, um Geld zu sparen. Aber was passiert, wenn Leute diesen Dienst am Wochenende nutzen müssen? Dann lässt du die Anwendung in einem Minimalzustand weiterlaufen und musst für jedes einzelne Wochenende bezahlen. Was ist mit Feiertagen? Was ist mit einer Betriebsversammlung? Du bezahlst für Server, die du nicht brauchst, aber wenn du sie abschaltest, ist deine Anwendung nicht verfügbar. Bei Serverless wird bei einer Anfrage automatisch die benötigte Rechenleistung bereitgestellt, wenn keine verfügbar ist. Deine Anwendung ist immer verfügbar (auch wenn sie manchmal unter einem Kaltstart leidet, auf den wir später noch eingehen werden). Andere Teile deiner Anwendung können sich auf deine Cloud-Rechnung auswirken, z. B. die Speicherung von Daten, die Überwachung und andere Unterstützungssysteme, aber der Rechenaufwand ist null.

Zeit und Geld bei der Verwaltung von Servern sparen

Natürlich wirst du wertvolle Entwicklungszeit darauf verwenden, die Kosten von nicht-serverlosen Systemen zu optimieren. Die Zeit, die du für diese Entscheidungen brauchst, ist nicht umsonst. Sie wird in den Gehältern der Ingenieure und den Kosten für ihre Einstellung und Bindung an das Unternehmen gemessen, aber auch in der Tatsache, dass du den Nutzern wertvolle Funktionen nicht zur Verfügung stellen kannst! Mühsame Aufgaben wie die Kapazitätsplanung verschwinden nicht ganz, wenn du serverlos arbeitest, aber du kannst sie um eine Größenordnung verkleinern, und das hat klare Vorteile.

Sieh es doch mal so: Wenn du es dir nicht leisten kannst, ein Vollzeit-Team für die Entwicklung deiner Plattform einzustellen, warum mietest du es nicht bei deinem Cloud-Provider? Du wirst vielleicht nicht mehr in der Lage sein, bestimmte Aufgaben auf niedriger Ebene zu erledigen, aber das ist die beste Spezialisierung und Skaleneffekte. Anstatt dass du manuell Autoscaling-Gruppen konfigurieren musst, um Rechenressourcen auf der Grundlage von Abstraktionen der von deinem System auszuführenden Arbeit bereitzustellen und zu deprovisionieren, skaliert Serverless auf der Grundlage der tatsächlich auszuführenden Arbeit. Es gibt kein Unternehmen, das in der Cloud arbeitet, in dem nicht zu jeder Zeit eine gewisse Menge an ungenutzter Rechenleistung verschwendet wird.

Verbesserte Entwicklerproduktivität

Einige Cloud-Provider schlagen vor, Funktionen als Klebstoff zu verwenden, um Logik und Prozesse zur Verbindung von Diensten hinzuzufügen. Du musst das Rad nicht neu erfinden, wenn es um die verteilte Ausführungsumgebung, Warteschlangen, Wiederholungslogik usw. für moderne serverlose Angebote geht, die mit der Zeit immer weiter wachsen.

Es gibt kein besseres Beispiel dafür als die Erstellung einer Extrahieren, Transformieren, Laden (ETL)-Pipeline mit Serverless. Eine ETL-Pipeline nimmt Daten aus einer Quelle, verarbeitet sie und lädt sie in ein neues Ziel. Du kannst eine Datenquelle einbinden, die automatisch eine Funktion für jeden einzelnen Schreibvorgang in einer Datenbank aufruft, und dieses Lambda kann die Daten umwandeln, ohne dass du dir Gedanken darüber machen musst, für wie viele Schreibvorgänge die ursprüngliche Datenbank skaliert werden kann oder nicht. Es funktioniert einfach!

Geringere Verantwortlichkeiten der Geschäftsführung

Unter habe ich bereits erwähnt, dass du deine DevOps von deinem Cloud-Provider mieten kannst, wenn dein Unternehmen sich kein eigenes Team von Plattformingenieuren leisten kann oder braucht. Dieser Vorteil wirkt sich auch auf andere Vorteile aus. Serverless bietet einen stabilen Container, auf den du zugreifen kannst, während sich jemand anderes um Sicherheitsupdates und Patches für die zugrunde liegende Infrastruktur kümmert. Es ist wichtig, sich an das Modell der geteilten Verantwortung zu erinnern, wenn du ein solches Angebot nutzt, denn du musst dich immer noch um die Sicherheit deines Codes und der Bibliotheken kümmern, die du in deiner Anwendung verwendest. (Auf die Sicherheit gehe ich in Kapitel 9 näher ein.) Aber du musst dich nicht um das Patchen des Betriebssystems, der Bibliotheken und der Version der Programmiersprache selbst kümmern. Dein Cloud-Provider beschäftigt rund um die Uhr Ingenieure, die sich um diese Entscheidungen und Aufgaben kümmern.

Bequeme Integrationen

Der größte Anreiz für die drei großen Cloud-Provider, wenn es um Serverless geht, sind die Integrationen. Alles dreht sich um die Ereignisse. Eine Nachricht in Google Cloud Pub/Sub veröffentlichen? Warum nicht in Echtzeit mit Code darauf reagieren? Du brauchst deine Worker Nodes nicht mehr zu überwachen. Füge einen Datensatz in deiner Datenbank hinzu oder aktualisiere ihn, und schon kannst du etwas anhängen, das diese Aktion überprüft. Wenn ein Kunde ein Bild direkt auf S3 hochlädt, kannst du dieses Bild in Miniaturbilder umwandeln, ohne einen einzigen Server bereitstellen zu müssen. Du verwendest AWS Cognito zur Verwaltung von Benutzerkonten und möchtest nach der Registrierung eines Benutzers eine Willkommens-E-Mail versenden? Mit Serverless kannst du all diese Anwendungsfälle und noch viele mehr bewältigen.

Die aktuellen Angebote ermöglichen es, dass dein Funktionscode Aktionen in verschiedenen Teilen deines Systems zusammenfügt, ohne dass du dich um die Bereitstellung von Warteschlangenressourcen oder die Erstellung einer eigenen Task-Ausführungs- und Hintergrundarbeitsumgebung kümmern musst. Das führt teilweise zu Undurchsichtigkeit und zeigt sich als Schwäche beim Debuggen. Das gilt besonders, wenn es einfacher wird, externe Dienste in die Architektur deiner Anwendung einzubinden.

Schwachstellen von Serverless

Der interessanteste Teil der Schwächen von Serverless ist, wie sie mit der Zeit weniger lästig werden oder zu verschwinden beginnen. Während dieses Buch geschrieben wurde, gab es in der Branche große Fortschritte bei einigen dieser Themen, und der Wandel wird auch weiterhin rasant sein. Um über die Entwicklungen auf dem Laufenden zu bleiben, vor allem in einem Bereich, der sich so schnell weiterentwickelt wie Serverless oder Cloud Native insgesamt, solltest du den Blog oder die E-Mail-Ankündigungen deiner Cloud-Provider verfolgen, dich in Mailinglisten für relevante Gruppen eintragen oder sogar die Entwicklungen auf einer Website wie Reddit verfolgen.³

Der Kalte (Start-)Krieg

Ein Kaltstart tritt auf, wenn ein Funktionsaufruf erfolgt und keine laufende Funktion zur Verfügung steht, um die Arbeit auszuführen. Stattdessen wird ein neuer Funktionscontainer gestartet, und deine Benutzer müssen eine Weile warten, bis deine Anwendung reagiert. Manche Leute halten Funktionen warm, um dieses Problem zu vermeiden, aber ich glaube daran, dass man das richtige Werkzeug für die Aufgabe verwenden sollte. Wer die Nutzung vortäuscht, um seine Funktionen für den Nutzerverkehr bereitzuhalten, nutzt Serverless nicht so, wie es gedacht war. Was sie wirklich wollen, ist die sofortige Beantwortung einer bestimmten Anzahl gleichzeitiger Anfragen, ohne darauf zu warten, dass eine zusätzliche Maschine hochgefahren und einem Cluster hinzugefügt wird. Eine serverlose Funktion ist sicherlich besser als das Hochfahren einer zusätzlichen EC2-Instanz, aber für manche Leute ist das einfach nicht genug. Im Zweifelsfall würde ich sagen, dass sie so begeistert von der Nutzung von Serverless sind, dass sie bereit sind, einige der Schwachstellen durch Hacks zu beheben. Wenn diese Form der Latenz ein Hindernis für deine Anwendung ist, dann ist Serverless vielleicht nicht das Richtige für deinen Anwendungsfall. Nutze Serverless stattdessen für Workloads, die nicht direkt mit dem Nutzer zu tun haben.

Das Problem des Kaltstarts wird mit der Zeit verschwinden, aber diese Zukunft ist bereits jetzt verfügbar. Einige Umgebungen, die Compute at the Edge oder Content Delivery Network (CDN) anbieten, wie z.B. Cloudflare Worker, haben die Beschränkungen für die Funktionen, die sie ausführen, erhöht, um die Kaltstartzeit für die Vor- oder Nachbearbeitung einer Webanfrage zu verringern. Stell dir das vor. Während die meisten Entwickler versuchen, auf API-Anfragen in weniger als 100 ms zu reagieren, fügen sie vor oder nach diesen 100 ms zusätzliche Rechenleistung hinzu. Ein häufiger Anwendungsfall für dieses Konzept ist die Personalisierung einer im Cache gespeicherten Seite, die von einem CDN bereitgestellt wird.

Viele Unternehmen bieten auch alternative Umgebungen an, um dieses Problem zu lösen. Es ist ein Wettrüsten. Wenn du die Leistung zu diesem Zeitpunkt brauchst, ist sie vielleicht noch nicht da. Aber sie wird schneller werden, bis sie den minimalen Overhead erreicht. AWS Lambda zum Beispiel hat seine Startzeit für Kaltstarts stark verbessert, indem es die Art und Weise, wie es eine Funktion mit einem privaten Netzwerk verbindet, völlig neu erfunden hat.

Zeit berechnen

Eine anerkannte Schwäche von Serverless ist die begrenzte Zeitspanne, in der ein bestimmter Workload ausgeführt werden kann. Es gibt einige Umgehungsmöglichkeiten, aber in manchen Anwendungsfällen kann es sinnvoll sein, Serverless nicht zu nutzen.

Diese Begrenzung ist jedoch in vielerlei Hinsicht willkürlich. 2018 änderte Amazon die Begrenzung für Lambda von 5 Minuten auf 15 Minuten. Für diese Änderung war es nicht nötig, Lambda neu zu architektieren. Da einige Probleme mit Serverless gelöst werden, stehen dir die Lösungen ohne zusätzlichen technischen Aufwand zur Verfügung. Möglicherweise musst du Entwicklungszeit aufwenden, um die Vorteile der sich verändernden Landschaft optimal zu nutzen, aber dein System wird auch ohne diese Änderungen funktionieren.

VPC/Netzwerk-Probleme

Wenn deine Anwendung in einem bestimmten privaten Subnetz oder Cloud-Netzwerk laufen muss, gibt es einige Einschränkungen. In einem Subnetz mit Platz für 254 IP-Adressen kannst du nicht auf 10.000 gleichzeitige Ausführungen skalieren. Je nach Unternehmen bist du vielleicht gezwungen, in einer Virtual Private Cloud (VPC) zu arbeiten, um auf private Ressourcen zuzugreifen, oder deine Anwendung muss auf eine Datenbank zugreifen, die nur in einem bestimmten Netzwerk erreichbar ist. Du musst die Kapazitäten planen, um sicherzustellen, dass deine privaten Netzwerke groß genug sind. Wenn du ein wirklich serverloses System aufbauen willst, musst du bestimmte Cloud-Angebote, Persistenzschichten oder andere Designentscheidungen vermeiden, die dich an ein bestimmtes privates Netzwerk binden.

Anwendung Größe

Beschränkungen wie die Rechenzeit sind ebenfalls willkürlich, aber wenn deine Anwendung zu groß ist, können die Kaltstartzeiten unkontrollierbar werden. Wie wirkt sich diese Begrenzung auf dich aus? Du kannst zum Beispiel eine große Java-Anwendung nicht in eine serverlose Funktion einbinden - die Verwendung von Containern oder Instanzen ist im Moment die bessere Strategie, aber behalte die Änderungen im Auge, die dies ermöglichen könnten. Möglicherweise bist du auch in der Anzahl und Größe der Abhängigkeiten deiner Anwendung eingeschränkt, obwohl es mit der Einführung von Schichten in AWS auch in diesem Bereich Fortschritte gibt.

Potenzial, teurer zu sein

Wenn deine Anwendung eine vorhersehbare und stabile Menge an Rechenleistung benötigt, wirst du durch den Einsatz von Serverless zu viel Geld ausgeben. Aber bedenke die Kosten für die Wartung und Instandhaltung, die für das Patchen von Systemen mit Sicherheits- und anderen Updates erforderlich sind. Entweder du bezahlst deine Mitarbeiter dafür oder du bezahlst zu viel für deine Rechenleistung, um einen Teil dieser Wartungskosten zu übernehmen. Ist es sinnvoller, 200.000 US-Dollar pro Jahr zusätzlich für einen DevOps-Ingenieur auszugeben oder 20.000 US-Dollar pro Jahr mehr für deine Cloud-Rechnung zu bezahlen? Gib das Geld für einen anderen Ingenieur aus, der Funktionen entwickelt, die direkt mit Einnahmen verbunden sind.

Vendor Lock-In

Jede Technologie, für die du dich entscheidest, bindet dich auf die eine oder andere Weise an einen bestimmten Anbieter: welches Docker-Basisbild du verwendest, welche Datenbank du nutzt, ob du wirklich ein zusätzliches Paket hinzufügen solltest und so weiter. Du kannst dies abmildern, indem deine Organisation selbst eine Funktionsausführungsumgebung auf Kubernetes hostet und Open-Source-Software verwendet. Es ist jedoch sehr wahrscheinlich, dass dein Unternehmen bereits in gewissem Maße an einen dieser Cloud-Provider gebunden ist. Wenn dein Unternehmen bereits einen Kompromiss in eine bestimmte Richtung geschlossen hat, ist es sinnvoll, darauf aufzusetzen. Das könnte auch bei dir der Fall sein.

Die Bindung an einen bestimmten Anbieter ist eine interessante Sorge. Manche meinen, dies sei nur eine Überreaktion auf die Kosten für einen Wechsel, die bei jeder Technologieentscheidung anfallen. Sie vergleichen das mit dem Wechsel von Java zu Python oder von Go zu Erlang. Das stimmt nur insofern, als dass jeder Entwickler die Möglichkeit hat, Optimierungen und Kompromisse nach eigenem Ermessen vorzunehmen. Sicher, du kannst eine Menge Geld bei den Hosting-Kosten sparen, indem du deine Anwendung auf einem alten Server unter deinem Schreibtisch oder auf einem Cluster von Raspberry Pis laufen lässt, aber du wirst dich wahrscheinlich für virtualisierte Instanzen eines großen Cloud-Providers entscheiden, weil du dich entscheiden musst, wie du deine Zeit verbringen willst: mit dem Schreiben von Code oder mit dem Tragen von Eimern Dieselkraftstoff nach einem Hurrikan eine Treppe hinauf (siehe "Die physische Welt").

Lock-in ist etwas, das man im Hinterkopf behalten sollte, auf das man aber nicht viel Zeit verwenden sollte. Ich werde mich vor allem auf Beispiele von AWS konzentrieren, weil es dort viele unterstützende Dienste und Integrationen gibt. Ich möchte mich nicht auf einen bestimmten Anbieter festlegen und denke, dass es am pragmatischsten ist, sich die Optionen offen zu halten.

Wenn sich dein Unternehmen für eine dieser Plattformen entschieden hat, nutze den umfangreichen Servicekatalog, der dir zur Verfügung steht, um deine Arbeit auf die beste Weise und mit den geringstmöglichen Kompromissen zu erledigen. Lerne, deinen Anbieter zu lieben, aber vertraue ihm nicht mehr, als du solltest.

Komplexe Fehlersuche

Wenn du eine dynamische Laufzeit hast, kann das Debugging kompliziert sein, um Fehler zu reproduzieren und zu beheben. Je mehr Komponenten oder Microservices dein System umfasst, desto schwieriger kann es sein, eine Benutzeraktion im gesamten System zu verfolgen. Deshalb gibt es so viele Tools und SaaS-Angebote, die sich mit diesen Problemen befassen. Meiner Meinung nach ist dies in der Regel ein Symptom für die falsche Anwendung von Serverless. Richtig eingesetzt, sollte Serverless dir mehr Einblick in die Kernfunktionen deiner Systeme geben. Einige dieser Tools entwickeln sich jedoch zu wirklich überzeugenden Methoden, um Probleme zu finden und zu filtern sowie Daten bereitzustellen, die bei der Reproduktion solcher Fehler hilfreich sind. Dein Debugging und deine Introspektion sind leistungsfähiger als je zuvor. Was für eine Zeit, in der lebendig ist!

Wann ist es sinnvoll, Serverless zu nutzen?

Viele Entwicklerinnen und Entwickler auf stellen auf Serverless um oder erkunden Serverless-Komponenten für Teile ihrer Anwendungen. sagt Werner Vogels:

Bei Amazon sind wir selbst noch nicht komplett serverlos, aber wir bewegen uns in diese Richtung. Und viele unserer Kunden tun das auch. Wir gehen sogar davon aus, dass es bald eine ganze Generation von Entwicklern geben wird, die noch nie einen Server angefasst haben und nur Geschäftslogik schreiben. Der Grund dafür ist einfach. Ganz gleich, ob du neue Anwendungen entwickelst oder alte Anwendungen migrierst: Wenn du serverlose Primitive für die Berechnung, die Datenverarbeitung und die Integration verwendest, kannst du von der größtmöglichen Agilität profitieren, die die Cloud zu bieten hat.

Er sieht serverlose Primitive (die grundlegendsten Ressourcentypen) als ihren serverbasierten Äquivalenten überlegen an, so wie die Cloud-Primitive den Rechenzentrums-Primitiven den Mainframe-Pendants überlegen waren.

Die Anwendungsfälle sind unterschiedlich, aber hier sind einige der häufigsten und besten Gründe für den Einsatz vonServerless.

Der wichtigste Faktor, der über deinen Erfolg entscheidet, ist der Anwendungsfall. Hast du gehört, wie sich Leute über Serverless beschweren? Worüber reden sie? Kaltstarts. Während Kaltstarts so weit wie möglich optimiert werden, kannst du ein System bauen, das nicht von Kaltstarts betroffen ist. Das ist das gleiche Muster wie bei den Leuten, die sich darüber beschweren, dass NoSQL keine Transaktionen hat oder dass iPads keine Mausunterstützung haben. Heutzutage ändern sich die Dinge jedoch: DynamoDB bietet NoSQL mit Transaktionen, und das neueste iPad Pro hat ein Trackpad.

Du brauchst keinen bestimmten Grund, um Serverless zu nutzen, aber hier sind einige Beispiele für die Merkmale der Rechenarbeit, die du durchführen willst und die die geringsten Reibungsverluste und den größten Nutzen mit sich bringen:

• Aufgaben, die in kleine unabhängige Arbeitseinheiten aufgeteilt werden können

• Aufgaben, die entweder seltene oder unvorhersehbare Nutzungsmuster aufweisen

• Hintergrundarbeit oder System-zu-System-Kommunikation, die nicht durch Kaltstarts beeinträchtigt wird

Schauen wir uns das mal genauer an. Eine Aufgabe ist eine Arbeitseinheit, die nicht blockiert und in kleinere Arbeitseinheiten unterteilt werden kann, die jeweils in eine Funktion passen würden.

Serverless eignet sich am besten für eine nicht vorhersehbare Last. Das heißt nicht, dass du es in diesem Fall nicht verwenden kannst, es ist nur nicht unbedingt die effizienteste Lösung und kostet mehr als die Verwendung von Containern (aber auch hier ist der Aufwand für die Verwaltung der Container nicht eingerechnet).

Aber was ist mit deiner Arbeitslast? Wenn du dein System als eine Sammlung von leicht trennbaren Teilen sehen kannst und dich nicht mit dem Overhead von Servern für einen Mangel an Ressourcen herumschlagen willst, kann es sinnvoll sein, serverlos zu arbeiten.

Einige Teile deiner Anwendung werden schnelllebig sein, zumindest wenn es um die Änderungsrate von Funktionen und Prioritäten geht. Aber dann gibt es auch die starken und beständigen Komponenten, die zu den Arbeitspferden gehören. Stell dir einige der Probleme vor, die du noch zu lösen hast. Es gibt einige Teile deiner Gesamtanwendung, die eine geringe Geschwindigkeit aufweisen, sobald die Version 1.0 ausgeliefert ist. Sie dienen nicht direkt den Nutzern, sondern nehmen den Anwendungsservern, die dies tun, Arbeit ab. Das Versenden von E-Mails an die Nutzer ist eine perfekte asynchrone Aufgabe, die im Hintergrund abläuft und für die keine großen Änderungen an der grundlegenden Architektur erforderlich sind. Die Nachfrage ist etwas unvorhersehbar. Und auch wenn du willst, dass es in Echtzeit geschieht, wird die Latenzzeit eines Kaltstarts einem Benutzer, der sein Konto gesperrt hat, nicht die Möglichkeit nehmen, sein Passwort zurückzusetzen.

Ein weiterer interessanter Anwendungsfall von Serverless ist die nahezu unendliche Skalierbarkeit, die es mit sich bringt. Nehmen wir an, es dauert 30 Sekunden, um eine Minute eines hochauflösenden Videos für das Streaming zu verarbeiten. Wie lange würde es dauern, einen 90-minütigen Film zu verarbeiten? 30 Sekunden. Weil du die Arbeit aufteilen und parallelisieren und sofort an so viele Lambda-Funktionen wie möglich weitergeben kannst, kannst du die Zeit, die du für eine Aufgabe brauchst, drastisch verkürzen. Das ist eine Möglichkeit, wie Netflix Serverless nutzt.

Ein weiterer wichtiger Anwendungsfall für serverlose ist die ereignisgesteuerte Architektur. In Kapitel 3 werden serverlose Architekturmuster im Detail behandelt.

Eine der hilfreichsten Anwendungen von Serverless Compute ist, dass es als Bindeglied zwischen den Diensten dient. Du kannst zum Beispiel die Auslastung einer Ressource überwachen, um einen Dienst hoch- oder runterzuskalieren und so Kosten zu sparen.

Willst du hochgeladene Bilder automatisch in Miniaturansichten umwandeln, ohne eine Aufgabe oder einen Warteschlangendienst einzurichten? Willst du Geld für deine Instanzen sparen, indem du Spot-Instanzen nutzt, die weniger Geld kosten als herkömmliche Instanzen? Wenn diese Spot-Instanzen wegfallen (was einer der Gründe dafür ist, dass sie günstiger sind), kannst du bei diesem Cloud-Ereignis automatisch eine Funktion aufrufen lassen, um eine reguläre Instanz zu erzeugen, die ihren Platz einnimmt. Wird später eine weitere Spot-Instanz verfügbar? Das Gleiche in umgekehrter Reihenfolge: Deine Funktion kann die Instanz, die weniger Geld kostet, hochfahren und die teurere beenden. Willst du auf Datenänderungen reagieren, sobald sie eintreten, ohne spröden analytischen Code in den Hauptkonversionstrichter deiner Anwendung einzubauen? Serverless kann bei all diesen Anwendungsfällen helfen. Das können Glue, DevOps, Automatisierung, Out-of-Band-Verarbeitung von Daten oder vollwertige Anwendungen sein.

Wann ist Serverless Compute nicht das Richtige für dich?

Serverless eignet sich nicht, wenn du rechenintensive Aufgaben hast, wenn deine Aufgaben eine lange Laufzeit haben, die nicht in kleinere Workloads aufgeteilt werden kann, oder wenn du zusätzliche Funktionen benötigst, die derzeit von den Cloud-Providern nicht unterstützt werden, um nur einige Beispiele zu nennen. Diese Aufgaben können so aussehen, dass du eine große Tabelle mit Daten liest und jede Zeile in eine API-Anfrage umwandelst, einen Film in Spielfilmlänge für das Streaming codierst oder eine dauerhafte WebSockets-Verbindung für eine Chat-Funktion aufbaust. Für einige dieser Beispiele gibt es jedoch Möglichkeiten, die Arbeit anzupassen. Du kannst einen parallelen Scan oder bestimmte Arten von Datenspeichern wie DynamoDB ausführen. Du kannst große Dateien in kleinere parallelisierte Chucks aufteilen, wie es Netflix derzeit bei der Verschlüsselung von Filmen macht. Du kannst ein API-Gateway mit WebSockets verwenden, um eine Echtzeitverbindung zu den Kunden aufrechtzuerhalten, während du für jede übergebene Nachricht ein Lambda aufrufst.

Fangen wir an

Es ist an der Zeit, deine serverlose Reise zu beginnen oder fortzusetzen. Am Ende dieses Buches wirst du viele Grundlagen und bewährte Methoden kennengelernt haben, die du brauchst, um in jeder Form von Cloud Computing erfolgreich zu sein, ob mit oder ohne Server.

Wie "full stack" bist du? Wenn du dich auf bestimmte Bereiche spezialisiert hast, wie hast du diese Bereiche ausgewählt? Hast du andere Dinge ausprobiert, bevor du dich entschieden hast, kein Experte zu sein? Du musst wissen, wie man Server verwaltet, bevor du ein System verwalten kannst, das sie für dich verwaltet.

Die Entscheidung für Serverless wird in der Regel getroffen, um die Komplexität bei der Konfiguration und Verwaltung der Infrastruktur zu reduzieren, aber du musst ein grundlegendes Verständnis für die Arbeit haben, die du abstrahierst, um ein zuverlässiges System darauf aufzubauen. Das alles wird in diesem Buch behandelt.

In Teil I dieses Buches erfährst du, was es bedeutet, ein richtiges Produktionssystem zu starten. Natürlich sind auch Server beteiligt, aber du musst sie nicht persönlich kennen. Teil II behandelt die Tools, die du brauchst, um mit Serverless erfolgreich zu sein. Teil III wird einige fortgeschrittene Themen vertiefen, z. B. die Sicherheit.

Lass uns jetzt über Produktionssysteme sprechen.

¹ Cloud Native Computing Foundation, "CNCF WG-Serverless Whitepaper v1.0", 2018, https://oreil.ly/A2ehY.

² Ken Fromm, "Why the Future of Software and Apps Is Serverless", Read/Write, https://oreil.ly/vh5ck.

³ Ich persönlich halte mich gerne mit Hacker News auf dem Laufenden.