Serverlose Anwendungen auf Knative aufbauen

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Serverless ist zu einem wichtigen Verkaufsargument von Cloud-Providern geworden. In den letzten vier Jahren wurden Hunderte von Diensten sowohl von großen Cloud-Providern als auch von kleineren Anbietern als "serverlos" bezeichnet oder umbenannt. Serverlos hat eindeutig etwas mit Diensten zu tun, die über ein Netzwerk bereitgestellt werden, aber was ist serverlos und warum ist es wichtig? Wie unterscheidet es sich von Containern, Funktionen oder Cloud-nativen Technologien? Während sich die Terminologie und die Definitionen ständig weiterentwickeln, möchte dieses Buch die wesentlichen Merkmale der serverlosen Technologien aufzeigen und erklären, warum der Begriff "serverlos" immer beliebter wird.

Dieses Buch konzentriert sich in erster Linie auf serverlose Rechensysteme, d.h. Systeme, die benutzerdefinierte Software ausführen, anstatt ein System mit festen Funktionen wie Speicherung, Indexierung oder Message Queuing zu betreiben. (Serverlose Systeme zur Speicherung gibt es auch, aber sie stehen nicht im Mittelpunkt dieses Buches! Allerdings ist die Grenze zwischen der Speicherung von Daten mit fester Funktion und der allgemeinen Datenverarbeitung nie so scharf und klar, wie es die Theoriegerne hätte. So kombinieren beispielsweise Datenbanksysteme, die die SQL-Abfragesyntax unterstützen, Speicherung, Indexierung und die Ausführung von deklarativen, in SQL geschriebenen Abfrageprogrammen. Auch wenn die Architektur von Systemen mit festen Funktionen faszinierend und für die Leistungsoptimierung wichtig ist, konzentriert sich dieses Buch vor allem auf Serverless Compute, weil es die Schnittstelle mit den meisten Freiheitsgraden für Anwendungsautoren ist und das System, mit dem sie am ehesten täglich interagieren.

Wenn du immer noch nicht genau weißt, was Serverless ist, brauchst du dir keine Sorgen zu machen. Angesichts der vielen verschiedenen Produkte auf dem Markt ist es klar, dass die meisten Leute im selben Boot sitzen. Wir werden die Entwicklung des Begriffs "serverlos" imAbschnitt "Hintergrund" des Vorworts darstellen und dann in Kapitel 1 eine genaue Definition geben.

Für wen ist dieses Buch?

Dieses Buch richtet sich in erster Linie an Softwareentwickler¹ und Technologen, die entweder noch nicht mit Serverless vertraut sind oder ihr Verständnis für die Prinzipien und bewährten Methoden im Zusammenhang mit Serverless-Architekturen vertiefen möchten.

Neue Praktiker, die sofort mit dem Schreiben von serverlosen Anwendungen beginnen wollen, können mit Kapitel 2 beginnen, obwohl ich Kapitel 1 für eine zusätzliche Orientierung darüber empfehle, was vor sich geht und warum Serverless wichtig ist.Kapitel 3 bietet zusätzliches praktisches Material, um ein tieferes Verständnis für die Architektur der in den Beispielen verwendeten Knative-Plattform zu entwickeln.

Die Reihenfolge der Kapitel sollte für Leser, die mit Serverless vertraut sind, selbstverständlich sein. Die Kapitel 5 und 6 enthalten eine Checkliste mit Standardmustern für die Anwendung von Serverless, während ab Kapitel 8 eine Art "Bingo-Karte" mit Serverless-Warnzeichen und Lösungsskizzen zu finden ist, die im Alltag nützlich sein können. Der historische Kontext in Kapitel 11bietet außerdem eine Übersicht über frühere Technologiegemeinschaften, die du nach Mustern und Lösungen untersuchen kannst.

Für Leser, die eher daran interessiert sind, die Ideen von Serverless im Großen und Ganzen zu erfassen, bieten die Kapitel 1, 4 und 7 einige interessante Perlen, die zu einem tieferen Verständnis und neuen Ideen anregen. Der historische Kontext und die Zukunftsprognosen in Kapitel 11können ebenfalls von Interesse sein, um die Entwicklung von Softwaresystemen zu verstehen, die zu den aktuellen Implementierungen von skalierbaren serverlosen Angeboten geführt haben.

Für Leserinnen und Leser, die nicht nur neu im Serverless Computing, sondern auch in der Backend- oder Cloud-Native-Entwicklung sind, bietet der Rest dieses Vorworts einige Hintergrundinformationen, um den Einstieg zu erleichtern. Wie vieles in der Softwareentwicklung sind auch diese Bereiche schnelllebig, so dass sich die Definitionen, die ich hier anführe, vielleicht schon etwas geändert haben, wenn du dieses Buch liest. Im Zweifelsfall können diese Schlüsselwörter und Beschreibungen bei der Suche nach entsprechenden Diensten in der Umgebung deiner Wahl etwas Zeit sparen.

Hintergrund

In den letzten sechs Jahren haben die Begriffe "Cloud Native", "Serverless" und "Container" einen Hype erlebt und wurden immer wieder neu definiert, so dass selbst viele Praktiker Schwierigkeiten haben, mit den Definitionen dieser Begriffe Schritt zu halten oder sie vollständig zu verstehen. In den folgenden Abschnitten werden einige wichtige Bezugspunkte für den Rest des Buches definiert, aber viele dieser Definitionen werden sich wahrscheinlich weiterentwickeln - betrachte sie als allgemeinen Referenzkontext für den Rest des Buches, aber nicht als das einzig wahre Evangelium des serverlosen Computings. Definitionen ändern sich, wenn Ideen aufkeimen und wachsen, und die Gärten von Cloud Native und Serverless sind in den letzten sechs Jahren wie Pilze aus dem Boden geschossen.

Beachte auch, dass dieser Hintergrund so aufgebaut ist, dass er Sinn macht, wenn man ihn von Anfang bis Ende liest, und nicht als historische Aufzeichnung dessen, was zuerst kam. Viele dieser Bereiche entwickelten sich unabhängig voneinander und trafen nach ihrer ersten Blütezeit aufeinander (und pflanzten dabei Ideen von einem Garten in den anderen).

Container

Container - entweder im Docker- oder im Open Container Initiative (OCI)-Format - bieten einen Mechanismus, um einen Host-Rechner in mehrere unabhängige Laufzeitumgebungen zu unterteilen. Im Gegensatz zu virtuellen Maschinen (VMs) teilen sich Container-Umgebungen einen einzigen Betriebssystem-Kernel, was einige Vorteile mit sich bringt:

Geringerer OS-Overhead, da nur ein OS ausgeführt wird

Dies beschränkt Container auf das gleiche Betriebssystem wie den Host, normalerweise Linux. (Es gibt auch Windows-Container, die aber viel seltener genutzt werden.)

Vereinfachte Anwendungspakete, die unabhängig von Betriebssystemtreibern und Hardware laufen

Diese Pakete reichen aus, um verschiedene Linux-Distributionen auf demselben Kernel mit konsistentem Verhalten über alle Linux-Versionen hinweg auszuführen.

Größere Transparenz der Anwendung

Der gemeinsam genutzte Kernel ermöglicht die Überwachung von Anwendungsdetails wie z.B. offene Datei-Handles, die in einer vollständigen VM nur schwer zu extrahieren wären.

Ein Standardverteilungsmechanismus für die Speicherung eines Containers in einer OCI-Registrierung

Ein Teil der Containerspezifikation beschreibt, wie ein Container in einer Registry gespeichert und abgerufen werden kann. Der Container wird als eine Reihe von Dateisystemschichten gespeichert, die als komprimiertes TAR (Bandarchiv) gespeichert werden, so dass neue Schichten Dateien aus den darunter liegenden unveränderlichen Schichten hinzufügen und löschen können.

Im Gegensatz zu den folgenden Technologien begünstigen Container-Technologien allein die Ausführung von Anwendungen auf einem einzigen Rechner, nicht aber die Verteilung einer Anwendung auf mehr als einen Rechner. Im Kontext dieses Buches dienen Container als gemeinsames Substrat für die einfache Verteilung einer Anwendung, die konsistent auf einem oder mehreren Computern ausgeführt werden kann.

Cloud-Provider

Cloud-Provider sind Unternehmen, die Fernzugriff auf Rechen- und Speicherdienste anbieten. Bekannte Beispiele sind Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP). Zu den Rechen- und Speicherdiensten gehören VMs, Blob-Storage, Datenbanken, Nachrichtenwarteschlangen und weitere benutzerdefinierte Dienste. Diese Unternehmen vermieten den Zugang zu den Diensten stundenweise oder sogar auf einer feiner abgestuften Basis, so dass Unternehmen bei Bedarf ganz einfach auf die Rechenleistung zugreifen können, ohne im Voraus Investitionen in Rechenzentren, Hardware und Netzwerke tätigen und planen zu müssen.

Cloud-Provider Wirtschaft

Die großen Cloud-Provider verdienen einen Großteil ihres Geldes mit dem Verkauf oder dem Multiplexing des Zugangs zu der zugrunde liegenden physischen Hardware - zum Beispiel können sie einen Server für (abgeschriebene) 5.000 USD/Jahr kaufen, ihn dann aber in 20 Slots aufteilen, die sie für 0,05 USD/Stunde verkaufen. Für ein Unternehmen, das einen halben Server für ein paar Stunden zu Testzwecken mieten möchte, bedeutet das, dass es Zugang zu Hardware im Wert von über 2.500 USD für weniger als 1 USD erhält.

Cloud-Provider sind daher für viele Arten von Unternehmen attraktiv, bei denen die Nachfrage nicht von Tag zu Tag oder von Stunde zu Stunde gleichbleibend ist und bei denen der Zugang über das Internet akzeptabel ist. Wenn der Cloud-Provider drei Viertel der Maschine verkaufen kann (15 Slots × 0,05 $ = 0,75 $/Stunde Einnahmen), kann er 0,75 $ × 24 × 365 = 6.570 $/Jahr an Einnahmen erzielen - keine schlechte Rendite.

Während einige Cloud-Computing-Dienste im Grunde genommen "ein Stück Hardware mieten", konkurrieren die Cloud-Provider auch bei der Entwicklung von komplexeren verwaltetenDiensten, die entweder auf einzelnen VMs pro Kunde gehostet werden oder einenmandantenfähigen Ansatz verwenden, bei dem die Server selbst in der Lage sind, die Arbeit und die von verschiedenen Kunden verbrauchten Ressourcen innerhalb eines einzigen Anwendungsprozesses zu trennen. Es ist schwieriger, eine mandantenfähige Anwendung oder einen mandantenfähigen Dienst zu entwickeln, aber der Vorteil ist, dass es viel einfacher wird, die Serverressourcen zu verwalten und unter den Kunden aufzuteilen - und die Senkung der Kosten für den Betrieb des Dienstes bedeutet bessere Margen für Cloud-Provider.

Die in diesem Buch beschriebenen Muster für serverloses Computing wurden größtenteils entweder von den Cloud-Providern selbst oder von Kunden entwickelt, die Hinweise und Feedback dazu gaben, was die Dienste noch attraktiver machen würde (und somit einen höheren Preisaufschlag wert ist). Unabhängig davon, ob du einen proprietären Single-Cloud-Dienst nutzt oder selbst eine Lösung hostest (mehr dazu in den nächsten Abschnitten sowie in Kapitel 3), können Cloud-Provider eine attraktive Umgebung für die Bereitstellung und den Betrieb von serverlosen Anwendungen bieten.

Kubernetes und Cloud Native

Die Cloud-Provider von boten zunächst Rechenleistung als virtualisierte Version physischer Hardware an (so genannte Infrastruktur als Service oder IaaS). Doch schon bald wurde klar, dass ein Großteil der Arbeit, die mit der Sicherung und Wartung von Netzwerken und Betriebssystemen verbunden ist, repetitiv ist und sich gut für eine Automatisierung eignet. Eine ideale Lösung wäre die Verwendung von Containern als wiederholbare Methode zur Bereitstellung von Software, die auf in großen Mengen verwalteten Linux-Betriebssystemen mit "gerade genug" Netzwerken läuft, um die Container privat zu verbinden, ohne sie dem Internet auszuliefern. Ich gehe auf die Anforderungen für diese Art von System in"Infrastrukturvoraussetzungen" näher ein.

Eine Reihe von Start-ups hat versucht, Lösungen in diesem Bereich zu entwickeln - mit mäßigem Erfolg: Docker Swarm, Apache Mesos und andere. Am Ende setzte sich eine Technologie durch, die von Google eingeführt und von Red Hat, IBM und anderen mitentwickelt wurde - Kubernetes. Auch wenn Kubernetes einige technische Vorteile gegenüber den konkurrierenden Systemen hatte, ist ein Großteil seines Erfolgs auf das Ökosystem zurückzuführen, das sich um das Projekt herum gebildet hat.

Kubernetes wurde nicht nur an eine neutrale Stiftung (die Cloud Native Computing Foundation oder CNCF) gespendet, sondern es kamen bald weitere grundlegende Projekte hinzu, darunter gRPC- und Observability-Frameworks, Container-Paketierung, Datenbanken, Reverse-Proxy- und Service-Mesh-Projekte. Obwohl es sich um eine herstellerneutrale Stiftung handelt, haben die CNCF und ihre Mitglieder dieses Technologiepaket effektiv beworben und vermarktet, um die Aufmerksamkeit und das Interesse der Entwickler zu gewinnen. 2019 war weitgehend klar, dass die Kombination aus Kubernetes und Linux für viele Unternehmen die bevorzugte Infrastruktur-Container-Plattform sein würde.

Seitdem hat sich Kubernetes zu einem Allzwecksystem für die Steuerung von Infrastruktursystemen mithilfe eines standardisierten und erweiterbaren API-Modells entwickelt. Das Kubernetes-API-Modell basiert auf benutzerdefinierten Ressourcendefinitionen(CRDs) und Infrastruktur-Controllern, die den Zustand der Welt beobachten und versuchen, die Welt an einen gewünschten, in der Kubernetes-API gespeicherten Zustand anzupassen. Dieser Prozess wird als Reconciliation bezeichnet und kann, wenn er richtig umgesetzt wird, zu widerstandsfähigen und selbstheilenden Systemen führen, die einfacher zu implementieren sind als ein zentral orchestriertes Modell.

Die Technologien im Zusammenhang mit Kubernetes und anderen CNCF-Projekten werden als "cloud-native" Technologien bezeichnet, unabhängig davon, ob sie auf VMs eines Cloud-Providers oder auf physischer oder virtueller Hardware im eigenen Unternehmen implementiert sind. Die wichtigsten Merkmale dieser Technologien sind, dass sie explizit darauf ausgelegt sind, auf Clustern von halbwegs zuverlässigen Computern und Netzwerken zu laufen und einzelne Hardwareausfälle zu bewältigen, während sie für die Nutzer/innen verfügbar bleiben. Im Gegensatz dazu basierten viele Cloud-native Technologien auf hochverfügbaren und redundanten einzelnen Hardwareknoten, bei denen die Wartung in der Regel zu einer geplanten Ausfallzeit oder einem Ausfall führen würde.

Cloud-gehosteter Serverless

Während in den letzten fünf Jahren viele Cloud-Provider-Technologien in "serverless" umbenannt hat, bezog sich der Begriff ursprünglich auf eine Reihe von in der Cloud gehosteten Technologien, die die Bereitstellung von Diensten für Entwickler vereinfachten. Insbesondere ermöglichte serverless Entwicklern, die sich auf mobile oder Web-Anwendungen konzentrieren, eine kleine Menge an serverseitiger Logik zu implementieren, ohne dass sie Anwendungsserver verstehen, verwalten oder bereitstellen müssen (daher der Name). Diese Technologien teilen sich in zwei Hauptgruppen auf:

Backend as a Service (BaaS)

Strukturierte Speicherung mit einer umfangreichen und konfigurierbaren API für die Verwaltung des gespeicherten Zustands in einem Client. Im Allgemeinen umfasste diese API einen Mechanismus zur Speicherung kleiner bis mittelgroßer JSON-Objekte (JavaScript Object Notation) in einem Key-Value-Store mit der Möglichkeit, Push-Benachrichtigungen an Geräte zu senden, wenn ein Objekt auf dem Server geändert wurde. Die APIs unterstützten auch die serverseitige Validierung von Objekten, die automatische Authentifizierung und Benutzerverwaltung sowie Sicherheitsregeln für mobile Clients. Die bekanntesten Beispiele waren Parse (2013 von Facebook, jetzt Meta, übernommen und 2017 als Open Source veröffentlicht) und Firebase (2014 von Google übernommen).

BaaS war zwar praktisch, um ein Projekt mit einem kleinen Team zu starten, aber es gab einige Probleme, die dazu führten, dass es an Beliebtheit verlor:

• Die meisten Anwendungen wuchsen mit der Zeit über die festen Funktionen hinaus. Die Einführung von BaaS mag zwar einen anfänglichen Produktivitätsschub mit sich bringen, garantiert aber mit ziemlicher Sicherheit, dass die Speicherung migriert und neu geschrieben werden muss, wenn die Anwendung populär wird.

• Im Vergleich zu anderen Speicheroptionen war sie sowohl teuer als auch nur begrenzt skalierbar. Die Anwendungsentwickler mussten zwar keine Server verwalten, aber viele der Implementierungsarchitekturen erforderten einen einzigen Frontend-Server, um komplexe Objekt-Locking-Modelle zu vermeiden.

Funktion als Service (FaaS)

In diesem Modell schrieben Anwendungsentwickler einzelne Funktionen, die aufgerufen wurden, wenn bestimmte Bedingungen erfüllt waren. In einigen Fällen wurde dieses Modell mit BaaS kombiniert, um einige der Probleme mit festen Funktionen zu lösen, aber es kann auch mit skalierbaren Speicherdiensten von Cloud-Providern kombiniert werden, um wesentlich skalierbarere Architekturen zu erreichen. Im FaaS-Modell ist jeder Funktionsaufruf unabhängig und kann parallel erfolgen, sogar auf verschiedenen Computern. Die Koordinierung der Funktionsaufrufe muss explizit über Transaktionen oder Sperren erfolgen und nicht wie bei BaaS implizit über die API der Speicherung. Die erste weit verbreitete Implementierung von FaaS war AWS Lambda, die 2014 eingeführt wurde. Innerhalb weniger Jahre boten die meisten Cloud-Provider ähnliche konkurrierende Dienste an, allerdings ohne eine Form von Standard-APIs.

Im Gegensatz zu IaaS werden FaaS-Angebote von Cloud-Providern in der Regel pro Aufruf oder pro Sekunde der Funktionsausführung abgerechnet, mit einer maximalen Dauer von 5 bis 15 Minuten pro Aufruf. Die Abrechnung pro Aufruf kann zu sehr niedrigen Kosten für selten genutzte Funktionen führen, aber auch zu einer günstigen Abrechnung für stoßartige Arbeitslasten, die Tausende von Anfragen erhalten und dann für Minuten oder Stunden nicht genutzt werden. Um dieses Abrechnungsmodell zu ermöglichen, betreiben Cloud-Provider mandantenfähige Plattformen, die die Funktionen jedes Nutzers voneinander isolieren, obwohl sie nur wenige Sekunden voneinander entfernt auf derselben physischen Hardware laufen.

Um 2019 herum wurde "serverless" hauptsächlich mit FaaS in Verbindung gebracht, da BaaS in Ungnade gefallen war. Von diesem Zeitpunkt an wurde der Begriff "serverless" für rechenunabhängige Dienste verwendet, die gut zum FaaS-Abrechnungsmodell passten: Es werden nur die Zugriffe und die genutzte Speicherung in Rechnung gestellt, nicht aber langlaufende Servereinheiten. Die Unterschiede zwischen traditionellem Serverful und Serverless Computing werden in Kapitel 1 erläutert, aber mit dieser neuen Definition lässt sich der Begriff Serverless auch auf Speichersysteme und spezialisierte Dienste wie Videotranskodierung oder KI-Bilderkennung ausweiten.

Während die Definitionen von "Cloud-Provider" oder "Cloud Native Software" im Laufe der Zeit etwas fließend waren, war der Begriff "Serverless" besonders fließend - ein Serverless-Enthusiast aus dem Jahr 2014 wäre acht Jahre später ziemlich verwirrt von den meisten Diensten, die unter diesem Namen angeboten werden.

Eine letzte Anmerkung zur Disambiguierung: Die 5G-Telekommunikationsnetze haben den verwirrenden Begriff "Network Function as a Service" (Netzwerkfunktion als Dienst) eingeführt. Dahinter verbirgt sich die Idee, dass langlebiges Netzwerk-Routing-Verhalten wie Firewalls als Dienst auf einer virtualisierten Plattform laufen könnte, die nicht mit einem bestimmten physischen Rechner verbunden ist. In diesem Fall impliziert der Begriff "Netzwerkfunktion" eine völlig andere Architektur mit langlebigen, aber mobilen Servern und nicht eine serverlose verteilte Architektur.

Wie dieses Buch organisiert ist

Dieses Buch ist in vier Hauptteile unterteilt.² Ich neige dazu, zu lernen, indem ich ein mentales Modell von dem entwickle, was vor sich geht, dann Dinge ausprobiere, um zu sehen, wo mein mentales Modell nicht ganz richtig ist, und schließlich nach längerem Gebrauch tiefes Fachwissen entwickle. Die Teile entsprechen diesem Modell - sie sind in Tabelle P-1 aufgeführt.

Tabelle P-1. Teile des Buches

Teil	Kapitel	Beschreibung
Teil I, "Die Theorie des Serverless"	Kapitel 1	Definitionen und Beschreibungen dessen, was serverlose Plattformen bieten.
	Kapitel 2	Bauen durch Lernen: eine zustandslose serverlose Anwendung auf Knative.
	Kapitel 3	Ein tiefer Einblick in die Implementierung von Knative, einem serverlosen Rechensystem.
	Kapitel 4	In diesem Kapitel wird die Serverless-Bewegung in Bezug auf den geschäftlichen Nutzen betrachtet.
Teil II, "Entwerfen mit Serverless"	Kapitel 5	Nachdem wir nun ein Verständnis für Serverless haben, erklärt dieses Kapitel, wie wir die Muster aus Kapitel 2 auf bestehende Anwendungen anwenden können.
	Kapitel 6	Ereignisse sind ein gängiges Muster für die Orchestrierung von zustandslosen Anwendungen. In diesem Kapitel werden verschiedene Muster der ereignisgesteuerten Architektur erklärt.
	Kapitel 7	Während Kapitel 6 die Verbindung von Ereignissen mit einer Anwendung behandelt, konzentriert sich dieses Kapitel speziell auf die Entwicklung einer serverlosen Anwendung, die Ereignisse nativ nutzt.
	Kapitel 8	Nach vier Kapiteln, in denen Serverless angepriesen wurde, konzentriert sich dieses Kapitel auf Muster, die eine serverlose Anwendungsarchitektur vereiteln können.
Teil III, "Leben mit Serverless"	Kapitel 9	Nach den Warnungen in Kapitel 8vor Serverless-Antipatterns beschreibt dieses Kapitel die operativen Hindernisse auf dem Weg ins Serverless-Nirwana.
	Kapitel 10	Während sich Kapitel 9 auf die spektakulären Kernschmelzen konzentriert, befasst sich dieses Kapitel mit den Debugging-Tools, die für die Behebung von normalen, alltäglichen Anwendungsfehlern benötigt werden.
Teil IV, "Eine kurze Geschichte von Serverless"	Kapitel 11	Historischer Kontext für die Entwicklung der Serverless Compute Abstractions.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Tipp

Dieses Element steht für einen Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

Code-Beispiele verwenden

Zusätzliches Material (Code-Beispiele, Übungen usw.) steht unter https://oreil.ly/BSAK-supp zum Download bereit .

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, darfst du ihn in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Der Verkauf oder die Verbreitung von Beispielen aus O'Reilly-Büchern erfordert jedoch eine Genehmigung. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eineGenehmigung erforderlich.

Wir freuen uns über eine Namensnennung, verlangen sie aber in der Regel nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Zum Beispiel: "Building Serverless Applications on Knative von Evan Anderson (O'Reilly). Copyright 2024 Evan Anderson, 978-1-098-14207-0."

Wenn du der Meinung bist, dass die Verwendung von Code-Beispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter [e-mail] kontaktieren .

O'Reilly Online Learning

Hinweis

Seit mehr als 40 Jahren bietet O'Reilly Media Schulungen, Wissen und Einblicke in Technologie und Wirtschaft, um Unternehmen zum Erfolg zu verhelfen.

Unser einzigartiges Netzwerk von Experten und Innovatoren teilt sein Wissen und seine Erfahrung durch Bücher, Artikel und unsere Online-Lernplattform. Die Online-Lernplattform von O'Reilly bietet dir On-Demand-Zugang zu Live-Trainingskursen, ausführlichen Lernpfaden, interaktiven Programmierumgebungen und einer umfangreichen Text- und Videosammlung von O'Reilly und über 200 anderen Verlagen. Weitere Informationen erhältst du unterhttps://oreilly.com.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Nord
• Sebastopol, CA 95472
• 800-889-8969 (in den Vereinigten Staaten oder Kanada)
• 707-829-7019 (international oder lokal)
• 707-829-0104 (Fax)
• [e-mail]
• https://www.oreilly.com/about/contact.html

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du findest diese Seite unter https://oreil.ly/BuildingServerlessAppsKnative.

Neuigkeiten und Informationen über unsere Bücher und Kurse findest du unter https://oreilly.com.

Du findest uns auf LinkedIn: https://linkedin.com/company/oreilly-media.

Folge uns auf Twitter: https://twitter.com/oreillymedia.

Sieh uns auf YouTube: https://youtube.com/oreillymedia.

Danksagungen

An diesem Buch habe ich mindestens drei Jahre gearbeitet.³ In vielerlei Hinsicht ist es auch das Ergebnis meiner Interaktionen mit Serverless-Benutzern und -Entwicklern, darunter AutorenverschiedenerServerless-Plattformen sowie die breite und aufgeschlossene Knative-Community. Das ist das Dorf, aus dem dieses Buch hervorgegangen ist. Ohne die Hilfe der vielen Menschen, die zu diesem fertigen Produkt beigetragen haben, wäre dieses Buch immer noch ein Spross.

Da sind zunächst meine Redakteure bei O'Reilly, die mir geholfen haben, ein Buch zu veröffentlichen. John Devins sprach mich im April 2022 zum ersten Mal auf die Möglichkeit an, ein Buch zu schreiben, und half mir in der Anfangsphase beim Schreiben und Polieren des ersten Entwurfs. Shira Evans war eine geduldige und hartnäckige Partnerin als meine Entwicklungsredakteurin: Sie half mir, die Motivation zum Schreiben zu finden und mich wieder aufzurappeln, wenn ich mit dem Zeitplan in Verzug geriet, sie empfahl mir zusätzliche Inhalte, auch wenn sich dadurch der Zeitplan verschob, und sie war stets optimistisch, dass das Buch fertig werden würde. Schließlich war Clare Laylock meine Produktionsredakteurin, die mir half, das Buch bis zur Fertigstellung durchzuziehen, selbst nachdem ich es schon ein Dutzend Mal gelesen hatte.

Meine technischen Prüferinnen und Prüfer haben mir ein scharfes (und freundliches!) Feedback zu frühen Entwürfen dieses Buches gegeben. Ohne ihre Sichtweise wäre dieses Buch langweiliger und weniger genau. Selbst wenn die Einsicht bedeutete, dass ich einen weiteren Abschnitt schreiben musste, hatte ich die Gewissheit, dass diese Worte von Bedeutung waren. Celeste Stinger hat eine Reihe von Sicherheitserkenntnissen hervorgehoben, die in meinem ursprünglichen Text zu kurz gekommen waren. Jess Males brachte einen starken Sinn für Dringlichkeit und praktisches Zuverlässigkeitsdenken in die Überarbeitung meiner ersten Entwürfe ein. Und dieses Buch verdankt Joe Beda viel, weil er mich auf den Cloud Native-Pfad gebracht hat, der mich hierher geführt hat, und weil er mich gezwungen hat, die Kompromisse einer Reihe von spannenden Ideen klarer zu formulieren und die Teile hervorzuheben, die mehr gefeiert werden sollten.

Während die genannten Autoren dazu beigetragen haben, dieses Buch zu verbessern, hat meine Familie die nötige Unterstützung und Motivation gegeben, um an diesem Projekt festzuhalten. Die Idee, ein Buch über meine eigenen Erfahrungen zu schreiben, wurde durch die Arbeit meines Vaters an einem Lehrbuch für lineare Algebra angeregt, mit dem er gerne unterrichtete. Mein Sohn Erik und meine Tochter Eleanor waren außerordentlich geduldig, wenn es darum ging, ihre eigene Unterhaltung zu finden, während ich in Gemeinschaftsräumen auf dem Laptop saß und "an dem Buch arbeitete", und sie machten anerkennende Geräusche, wenn ich die PDF-Vorschau betrachtete. Vor allem aber wäre dieses Buch ohne Emily, meine Frau und Partnerin, nicht zustande gekommen. Sie war mein erster Gesprächspartner, eine hilfreiche Ablenkung für die Kinder, wenn ich Zeit für mich brauchte, und eine realistische Einschätzung dessen, was ich schaffen kann, wenn ich sage, dass ich alles machen will. Und hier ist noch eine Sache, die ich geschafft habe.

¹ Einschließlich operativ orientierter Ingenieure wie Site Reliability Engineers (SREs) oder DevOps-Praktiker.

² Der letzte Teil ist ein Kapitel, weil ich nicht widerstehen konnte, in Kapitel 11 einige historische Fußnoten hinzuzufügen.

³ Oder sechs Jahre, wenn du den Beginn meiner Arbeit an Knative mitzählst. Oder vierzehn, wenn wir meine erste Nutzung der Google App Engine im Zorn mitzählen.