Kapitel 1. Einführung
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Cloud Run ist eine Plattform auf Google Cloud, mit der du skalierbare und zuverlässige webbasierte Anwendungen erstellen kannst. Als Entwickler kannst du ganz einfach deinen Code schreiben und ihn veröffentlichen, während die Plattform deine Anwendung für dich bereitstellt, ausführt und skaliert.
Die öffentliche Cloud bietet Entwicklern und Unternehmen die Möglichkeit, physische Server und Rechenzentren in virtuelle umzuwandeln, was die Vorlaufzeit erheblich verkürzt und die hohen Anfangsinvestitionen in physische Server und Rechenzentren in laufende Betriebskosten verwandelt. Für die meisten Unternehmen ist dies bereits ein großer Schritt nach vorn.
Virtuelle Maschinen und virtuelle Netzwerke sind jedoch immer noch eine relativ niedrige Abstraktionsebene. Du kannst einen noch größeren Sprung machen, wenn du deine Anwendung so gestaltest, dass sie die Vorteile der modernen Cloud-Plattform voll ausnutzt. Cloud Run bietet eine höhere Abstraktionsebene als die eigentliche Serverinfrastruktur und ermöglicht es dir, dich auf den Code und nicht auf die Infrastruktur zu konzentrieren.
Die Nutzung der höheren Abstraktionsebene, die Cloud Run bietet, bedeutet nicht, dass du dich für immer an Google Cloud bindest. Erstens erfordert Cloud Run, dass deine Anwendung in einem Container verpackt ist - eine portable Möglichkeit, deine Anwendung einzusetzen und auszuführen. Wenn dein Container auf Cloud Run läuft, kannst du ihn auch auf deinem eigenen Server ausführen, z. B. mit Docker. Zweitens basiert die Cloud Run-Plattform auf der offenen Knative-Spezifikation, was bedeutet, dass du deine Anwendungen mit wenig Aufwand auf einen anderen Anbieter oder deine eigene Hardware migrieren kannst.
Serverlose Anwendungen
Wahrscheinlich hast du dieses Buch gekauft, weil du dich für die Entwicklung einer serverlosen Anwendung interessierst. Es ist sinnvoll, genau zu wissen, was Anwendung bedeutet, denn der Begriff ist sehr weit gefasst; dein Telefon führt Anwendungen aus, genauso wie ein Server. In diesem Buch geht es um webbasierte Anwendungen, die Anfragen (oder Ereignisse) über HTTPS empfangen und darauf antworten.
Beispiele für webbasierte Anwendungen sind die Websites, mit denen du über einen Webbrowser interagierst, und APIs, gegen die du programmieren kannst. Das sind die beiden wichtigsten Anwendungsfälle, auf die ich mich in diesem Buch konzentriere. Mit Cloud Run kannst du auch Pipelines zur Ereignisverarbeitung und Workflow-Automatisierung erstellen.
Ich möchte betonen, dass ich mit HTTP die gesamte Familie der HTTP-Protokolle meine, einschließlich HTTP/2 (die fortschrittlichere und leistungsfähigere Version). Wenn du mehr über die Entwicklung von HTTP erfahren möchtest, empfehle ich dir diesen gut geschriebenen Überblick bei MDN.
Nachdem ich nun eingegrenzt habe, was "Anwendung" im Kontext dieses Buches bedeutet, werfen wir einen Blick auf serverless. Wenn du Serverless-Komponenten verwendest, um deine Anwendung zu erstellen, ist deine Anwendung Serverless. Aber was bedeutet "serverlos"? Es ist ein abstrakter und überladener Begriff, der für verschiedene Menschen unterschiedliche Bedeutungen hat.
Wenn du versuchst, Serverless zu verstehen, solltest du dich nicht zu sehr auf den Teil "keine Server" konzentrieren - es ist mehr als das. Ich glaube, das ist es, was die Leute meinen, wenn sie etwas als serverlos bezeichnen, und warum sie so begeistert davon sind:
Es vereinfacht die Arbeit von Entwicklern, da sie sich nicht mehr um die Infrastruktur kümmern müssen .
Es ist von Anfang an skalierbar.
Sein Kostenmodell ist "Pay-per-Use": Du zahlst genau für das, was du nutzt, und nicht für Kapazitäten, die du im Voraus reservierst. Wenn du nichts nutzt, zahlst du auch nichts.
In den nächsten Abschnitten werde ich diese drei Aspekte von Serverless näher beleuchten.
Eine einfache Erfahrung für Entwickler
Durch den Wegfall der Infrastrukturverwaltung kannst du dich auf das Schreiben deines Codes konzentrieren und jemand anderes kümmert sich um die Bereitstellung, den Betrieb und die Skalierung deiner Anwendung. Die Plattform kümmert sich um all die wichtigen und scheinbar einfachen Details, die überraschend schwer zu bewerkstelligen sind, wie Autoskalierung, Fehlertoleranz, Protokollierung, Überwachung, Upgrades, Bereitstellung und Failover.
Eine Sache, um die du dich im Serverless-Kontext nicht kümmern musst, ist das Infrastrukturmanagement. Die Plattform bietet eine Abstraktionsschicht. Das ist der Hauptgrund, warum wir es serverlos nennen.
Wenn du ein kleines System betreibst, mag die Verwaltung der Infrastruktur keine große Sache sein, aber Leser, die mehr als 10 Server verwalten, wissen, dass dies eine große Verantwortung sein kann, die viel Arbeit erfordert, um sie richtig zu erledigen. Hier ist eine unvollständige Liste von Aufgaben, die du nicht mehr erledigen musst, wenn du deine Anwendungslogik auf einer serverlosen Plattform ausführst:
Bereitstellen und Konfigurieren von Servern (oder Einrichten von Automatisierung)
Einspielen von Sicherheitspatches auf deinen Servern
Konfigurieren von Netzwerken und Firewalls
SSL/TLS-Zertifikate einrichten, sie jährlich aktualisieren und einen Webserver konfigurieren
Automatisierung der Anwendungsbereitstellung auf einem Server-Cluster
Gebäudeautomatisierung, die transparent mit Hardware-Ausfällen umgehen kann
Einrichten von Logging und Metriküberwachung, um Einblicke in die Systemleistung zu erhalten
Und das sind nur die Server! Die meisten Unternehmen haben immer höhere Erwartungen an die Systemverfügbarkeit. Mehr als 30 Minuten Ausfallzeit pro Monat sind in der Regel inakzeptabel. Um dieses Niveau der Verfügbarkeit zu erreichen, musst du jeden Ausfall automatisieren - für eine manuelle Fehlerbehebung bleibt keine Zeit. Wie du dir vorstellen kannst, ist das eine Menge Arbeit und führt zu mehr Komplexität in deiner Infrastruktur. Wenn du Software in einer Unternehmensumgebung entwickelst, hast du es leichter, die Zustimmung der Sicherheits- und Betriebsteams einzuholen, da ein Großteil ihrer Aufgaben auf den Anbieter übertragen wird.
Die Verfügbarkeit hängt auch mit der Softwareverteilung zusammen, da neue Softwareversionen immer häufiger täglich statt monatlich verteilt werden. Wenn du deine Anwendung bereitstellst, möchtest du keine Ausfallzeiten haben, selbst wenn die Bereitstellung fehlschlägt.
Serverlose Technologie hilft dir, dich auf die Lösung deiner Geschäftsprobleme und die Entwicklung eines großartigen Produkts zu konzentrieren, während sich jemand anderes um die Grundlagen des Betriebs deiner App kümmert. Das klingt sehr bequem, aber du solltest das nicht so verstehen, dass damit alle deine Pflichten verschwinden. Am wichtigsten ist, dass du immer noch deinen Code schreiben und patchen und sicherstellen musst, dass er sicher und korrekt ist. Außerdem musst du immer noch einige Konfigurationen vornehmen, z. B. Ressourcenanforderungen festlegen, Skalierungsgrenzen hinzufügen und Zugriffsrichtlinien konfigurieren.
Automatisch skalierbar Out of the Box
Serverlose Produkte sind so konzipiert, dass sie ihre Kapazität automatisch erhöhen und verringern, und sich eng an die Nachfrage anpassen. Die Skalierbarkeit der Cloud stellt sicher, dass deine Anwendung fast jede Last bewältigen kann, die du ihr aufbürdest. Ein Hauptmerkmal von Serverless ist die stabile und gleichbleibende Leistung, unabhängig von der Skalierung.
Einer unserer Kunden betreibt eine ziemlich beliebte Fußball-Website in den Niederlanden. Die Seite hat einen Bereich, in dem Live-Ergebnisse angezeigt werden, was bedeutet, dass sie während der Spiele Spitzenbelastungen erfährt. Wenn ein beliebtes Spiel ansteht, werden mehr Server bereitgestellt und dem Instance-Pool hinzugefügt. Wenn das Spiel vorbei ist, werden die virtuellen Maschinen wieder entfernt, um Kosten zu sparen. Das hat im Allgemeinen gut funktioniert, und sie sahen wenig Grund, etwas zu ändern.
Sie waren jedoch nicht darauf vorbereitet, als einer unserer nationalen Vereine plötzlich sehr gut in der UEFA Champions League abschnitt. Entgegen aller Erwartungen erreichte dieser Verein das Halbfinale. Während alle Fußballfans in den Niederlanden die Mannschaft unterstützten, kam es bei unserem Kunden zu mehreren Ausfällen, die auch durch das Hinzufügen weiterer Server nicht behoben werden konnten.
Der Punkt ist, dass du die Nachteile eines servervollen Systems im Moment vielleicht noch nicht spürst, aber in Zukunft die Skalierbarkeitsvorteile von Serverless brauchen könntest, wenn du mit unvorhergesehenen Umständen umgehen musst. Die meisten Systeme lassen sich gut skalieren, bis sie auf einen Engpass stoßen und die Leistung plötzlich nachlässt. Die Architektur von Cloud Run bietet dir Leitplanken, die dir helfen, häufige Fehler zu vermeiden und standardmäßig skalierbare Anwendungen zu erstellen.
Ein anderes Kostenmodell
Das Kostenmodell von Serverless ist anders: Du zahlst nur für die tatsächliche Nutzung, nicht für die Vorabzuweisung von Kapazitäten. Wenn du auf einer serverlosen Plattform keine Anfragen bearbeitest, zahlst du nichts. Bei Cloud Run zahlst du für die Systemressourcen, die du zur Bearbeitung einer Anfrage nutzt, mit einer Granularität von 100 ms und einer kleinen Gebühr für jede Million Anfragen. Pay-per-Use kann auch für andere Arten von Produkten gelten. Bei einer serverlosen Datenbank zahlst du für jede Anfrage und für die Daten, die du speicherst.
Ich möchte dies mit einem Vorbehalt versehen: Ich behaupte nicht, dass Serverless billig ist. Während die meisten Early Adopters eine Kostenreduzierung zu spüren bekommen, kann sich Serverless in manchen Fällen als teurer erweisen. Einer dieser Fälle ist, wenn du es schaffst, deine Serverkapazitäten die ganze Zeit über zu fast 100 % auszulasten. Ich denke, das ist sehr selten; Auslastungsraten von 20 bis 40 % sind viel häufiger. Das sind eine Menge ungenutzte Server, für die du zahlst.
Das serverlose Kostenmodell bietet dem Anbieter einen Anreiz, dafür zu sorgen, dass deine Anwendung schnell skaliert und immer verfügbar ist. Er hat ein eigenes Interesse an der Sache.
Das funktioniert so: Du bezahlst für die Ressourcen, die du tatsächlich nutzt. Das bedeutet, dass dein Anbieter sicherstellen will, dass deine Anwendung jede Anfrage bearbeitet, die eingeht. Sobald dein Anbieter eine Anfrage auslässt, schlägt er möglicherweise fehl, um seine Serverressourcen zu monetarisieren.
Serverlos ist nicht Functions as a Service
Oft wird Serverless mit Functions as a Service (FaaS) Produkten wie Cloud Functions oder AWS Lambda in Verbindung gebracht. Bei FaaS verwendest du in der Regel eine Funktion als "Glue Code", um bestehende Google Cloud Services zu verbinden und zu erweitern. Funktionen verwenden ein Laufzeit-Framework: Du ein kleines Codeschnipsel, keinen Container. In dem Codeschnipsel implementierst du nur eine Funktion oder überschreibst eine Methode, die eine eingehende Anfrage oder ein Ereignis verarbeitet. Du startest nicht selbst einen HTTP-Server.
FaaS ist serverlos, weil es ein einfaches Entwicklererlebnis bietet - du musst dich nicht um die Laufzeit deines Codes kümmern (außer um die Konfiguration der Programmiersprache) oder um die Erstellung und Verwaltung des HTTPS-Endpunkts. Die Skalierung ist integriert, und du zahlst eine geringe Gebühr pro eine Million Anfragen.
Wie du in diesem Buch entdecken wirst, ist Cloud Run serverlos, aber es hat mehr Möglichkeiten als eine FaaS-Plattform. Serverless ist auch nicht auf die Bearbeitung von HTTPS-Anfragen beschränkt. Auch die anderen Primitive, die du zum Aufbau deiner Anwendung verwendest, können serverlos sein. Bevor ich einen Überblick über die anderen serverlosen Produkte von Google Cloud gebe, ist es nun an der Zeit, Google Cloud selbst vorzustellen.
Google Cloud
Google Cloud begann 2008, als Google App Engine, eine serverlose Anwendungsplattform, veröffentlichte. App Engine war schon serverlos, bevor wir das Wort " serverlos" verwendet haben. Damals hatte die App-Engine-Laufzeitumgebung jedoch eine Menge Einschränkungen, was in der Praxis bedeutete, dass sie nur für neue Projekte geeignet war. Einige Leute liebten es, andere nicht. Bemerkenswerte Erfolgsgeschichten von Kunden sind Snapchat und Spotify. App Engine hat sich auf dem Markt nur begrenzt durchgesetzt.
Aufgrund dieser lauwarmen Reaktion auf App Engine und der großen Nachfrage nach virtueller Serverinfrastruktur brachte Google Cloud 2012 Compute Engine auf den Markt. (Das ist gut sechs Jahre nach der Einführung von Amazon EC2, dem Produkt, mit dem virtuelle Maschinen bei AWS betrieben werden). Das lässt mich vermuten, dass Google schon immer auf Serverless gesetzt hat .
Hier ist eine andere Perspektive: Vor ein paar Jahren veröffentlichte Google einen Artikel über Borg, die globale Container-Infrastruktur, auf der der Großteil der Software des Unternehmens läuft, darunter die Google-Suche, Gmail und Compute Engine (so werden virtuelle Maschinen betrieben).1 So wird es hier beschrieben (Hervorhebung von mir):
Borg bietet drei Hauptvorteile: (1) Es verbirgt die Details des Ressourcenmanagements und der Fehlerbehandlung, so dass sich die Benutzer stattdessen auf die Anwendungsentwicklung konzentrieren können; (2) es arbeitet mit sehr hoher Zuverlässigkeit und Verfügbarkeit und unterstützt Anwendungen, die das Gleiche tun; und (3) es ermöglicht uns, Arbeitslasten auf Zehntausenden von Rechnern effektiv auszuführen.
Lass das erst einmal sacken: Google arbeitet seit mindestens 2005 an einer Container-Infrastruktur im Weltmaßstab, wenn man die wenigen öffentlichen Berichte über Borg zugrunde legt. Ein Hauptziel des Borg-Systems ist es, dass sich Entwickler/innen auf die Anwendungsentwicklung konzentrieren können, anstatt sich mit den betrieblichen Details der Software zu befassen, und dass es auf Zehntausende von Rechnern skalierbar ist. Das ist nicht nur skalierbar, es ist hyper-skalierbar.
Wenn du Software in der Größenordnung von Google entwickelst und betreibst, würdest du dir dann die Mühe machen wollen, eine Server-Infrastruktur zu unterhalten, ganz zu schweigen von den grundlegenden Bausteinen wie IP-Adressen, Netzwerke und Server?
Inzwischen sollte klar sein, dass ich gerne mit Google Cloud arbeite. Deshalb schreibe ich ein Buch über die Entwicklung serverloser Anwendungen mit Google Cloud Run. Ich werde es nicht mit anderen Cloud-Anbietern wie Amazon und Microsoft vergleichen, weil ich nicht über das nötige Fachwissen über andere Cloud-Plattformen verfüge, um einen solchen Vergleich lesenswert zu machen. Du kannst dir aber sicher sein, dass sich die allgemeinen Prinzipien für das Anwendungsdesign, die du in diesem Buch lernst, auch auf andere Plattformen übertragen lassen .
Serverless auf Google Cloud
In Tabelle 1-1 findest du eine Übersicht über die serverlosen Produkte von Google Cloud , die sich auf die Anwendungsentwicklung beziehen. Ich habe auch Informationen über die Open-Source-Kompatibilität der einzelnen Produkte notiert, damit du weißt, ob es Open-Source-Alternativen gibt, die du bei einem anderen Anbieter hosten kannst. Das ist wichtig, denn die Bindung an einen Anbieter ist das größte Problem bei serverlosen Anwendungen. Cloud Run schneidet in diesem Punkt gut ab, weil es API-kompatibel mit einem Open-Source-Produkt ist.
| Produkt | Zweck | Open-Source-Kompatibilität |
|---|---|---|
Nachrichtenübermittlung |
||
Veranstaltungen |
Proprietär1 |
|
Aufgeschobene Aufgaben |
Proprietär1 |
|
Geplante Aufgaben |
Proprietär1 |
|
Veranstaltungen |
OSS-kompatibel |
|
Berechne |
||
Containerplattform |
OSS-kompatibel |
|
Anwendungsplattform |
Eigenständig2 |
|
Vorhandene Google Cloud-Dienste miteinander verbinden |
Eigenständig2 |
|
Speicherung von Daten |
||
Blob Speicherung |
Proprietär3 |
|
Schlüssel-Wert-Speicher |
Proprietär |
|
|
||
Im serverlosen Angebot der Google Cloud fehlt eine relationale Datenbank. Ich denke, es gibt viele Anwendungen, für die der Einsatz einer relationalen Datenbank sehr sinnvoll ist, und die meisten Leser sind mit dieser Form der Anwendungsarchitektur bereits vertraut. Deshalb zeige ich dir in Kapitel 4, wie du Cloud SQL, eine verwaltete relationale Datenbank, nutzen kannst. Als verwalteter Dienst bietet sie viele der Vorteile von Serverless, skaliert aber nicht automatisch. Außerdem zahlst du für die zugewiesene Kapazität, auch wenn du sie nicht nutzt.
Wolkenlauf
Cloud Run ist eine serverlose Plattform, die deine Container-basierte Anwendung ausführt und skaliert. Sie wurde direkt auf Borg implementiert, der hyper-skalierbaren Container-Infrastruktur, die Google für die Google-Suche, Maps, Gmail und App Engine nutzt.
Der Entwicklungsworkflow ist ein unkomplizierter dreistufiger Prozess. Zuerst schreibst du deine Anwendung in deiner bevorzugten Programmiersprache. Deine Anwendung sollte einen HTTP-Server starten. Zweitens erstellst und verpackst du deine Anwendung in ein Container-Image. Der dritte und letzte Schritt besteht darin, das Container-Image bei Cloud Run einzusetzen. Cloud Run erstellt eine Service-Ressource und gibt einen aufrufbaren HTTPS-Endpunkt an dich zurück(Abbildung 1-1).
Abbildung 1-1. Entwicklungsworkflow für Cloud Run
Service
Ich möchte hier eine Pause einlegen und deine Aufmerksamkeit auf das Wort Service lenken, denn dies ist ein Schlüsselkonzept in Cloud Run. Jeder Dienst hat einen eindeutigen Namen und einen zugehörigen HTTPS-Endpunkt. Du wirst in erster Linie mit einer Service-Ressource interagieren, um deine Aufgaben zu erledigen, z. B. ein neues Container-Image bereitstellen, zu einer zuvor bereitgestellten Version zurückkehren und Konfigurationseinstellungen wie Umgebungsvariablen und Skalierungsgrenzen ändern.
Container-Image
Je nachdem, wie weit du in deinem Lernprozess bist, weißt du vielleicht nicht, was ein Container-Image ist. Wenn du weißt, was es ist, assoziierst du die Container-Technologie vielleicht mit einer Menge Low-Level-Infrastruktur-Overhead, den du nicht im Entferntesten lernen willst. Ich möchte dich beruhigen: Du musst kein Containerexperte werden, um mit Cloud Run produktiv zu sein. Je nach Anwendungsfall wirst du vielleicht nie selbst ein Container-Image erstellen müssen. Dennoch ist es hilfreich zu wissen, was Container sind und wie sie funktionieren. In Kapitel 3 werde ich Container von Grund auf behandeln.
Für den Moment reicht es, wenn du verstehst, dass ein Container-Image ein Paket ist, das deine Anwendung und alles, was sie zum Laufen braucht, enthält. Das mentale Modell, dass ein Container-Image ein Programm enthält, das du starten kannst, eignet sich gut für das Verständnis dieses Kapitels.
Cloud Run ist nicht nur eine bequeme Möglichkeit, einen Container zu starten. Die Plattform verfügt über zusätzliche Funktionen, die sie zu einer geeigneten Plattform für den Betrieb eines großen Produktionssystems machen. Der Rest dieses Abschnitts gibt dir einen Überblick über diese Funktionen und hilft dir, einige der wichtigsten Aspekte von Cloud Run zu verstehen. In Kapitel 2 gehe ich dann näher auf Cloud Run ein.
Skalierbarkeit und Selbstheilung
Eingehende Anfragen an deinen Cloud Run-Dienst werden von deinem Container bedient. Falls nötig, wird Cloud Run zusätzliche Instanzen deines Containers hinzufügen, um alle eingehenden Anfragen zu bearbeiten. Wenn ein einzelner Container fehlschlägt, wird er von Cloud Run durch eine neue Instanz ersetzt. Standardmäßig kann Cloud Run bis zu tausend Container-Instanzen pro Dienst hinzufügen, und du kannst dieses Limit durch eine Quotenerhöhung weiter erhöhen. Die Skalierung der Cloud arbeitet hier wirklich mit dir zusammen. Wenn du Zehntausende von Containern brauchst, ist das möglich - die Architektur von Cloud Run ist so konzipiert, dass sie nur durch die verfügbare Kapazität in einer bestimmten Google Cloud-Region (einem physischen Rechenzentrum) begrenzt wird.
HTTPS Serving
Standardmäßig erstellt Cloud Run automatisch einen eindeutigen HTTPS-Endpunkt , über den du deinen Container erreichen kannst. Du kannst auch deine eigene Domain verwenden oder deinen Dienst in den virtuellen Netzwerkstack von Google Cloud einbinden, wenn du fortschrittlichere Integrationen mit bestehenden Anwendungen brauchst, die vor Ort oder auf virtuellen Maschinen in Google Cloud laufen, oder mit Funktionen wie DDoS-Abwehr und einer Web Application Firewall.
Du kannst auch interne Cloud Run-Dienste erstellen, die nicht öffentlich zugänglich sind. Diese eignen sich hervorragend, um Ereignisse von anderen Google Cloud-Produkten zu empfangen, z. B. wenn eine Datei in einen Cloud Storage Bucket hochgeladen wird.
Microservices Unterstützung
Cloud Run unterstützt das Microservices-Modell, bei dem du deine Anwendung in kleinere Dienste aufteilst, die über API-Aufrufe oder Ereigniswarteschlangen kommunizieren. Das kann dir helfen, deine technische Organisation zu skalieren, und führt möglicherweise zu einer besseren Skalierbarkeit. Ein Beispiel für die Zusammenarbeit mehrerer Dienste behandle ich in Kapitel 6.
Identitäts-, Authentifizierungs- und Zugangsmanagement
Jedem Cloud Run-Dienst ist eine Identität zugewiesen, mit der du Cloud APIs und andere Cloud Run-Dienste aus dem Container heraus aufrufen kannst. Du kannst Zugriffsrichtlinien einrichten, die festlegen, welche Identitäten deinen Dienst aufrufen können.
Vor allem wenn du eine ernsthafte Anwendung entwickelst, ist ein Identitätssystem wichtig. Du musst sicherstellen, dass jeder Cloud Run-Dienst nur die Berechtigung hat, das zu tun, was er tun soll (Prinzip der geringsten Berechtigung) und dass der Dienst nur von den Identitäten aufgerufen werden kann, die ihn aufrufen sollen.
Wenn dein Zahlungsdienst zum Beispiel eine Anfrage zur Bestätigung einer Zahlung erhält, willst du wissen, wer diese Anfrage gesendet hat, und du willst sicher sein, dass nur der Zahlungsdienst auf die Datenbank zugreifen kann, in der die Zahlungsdaten gespeichert sind. In Kapitel 6 gehe ich näher auf die Identität und Authentifizierung von Diensten ein.
Überwachung und Protokollierung
Cloud Run erfasst standardmäßige Container- und Anfragemetriken, wie die Anfragedauer und CPU-Auslastung, und deine Anwendungsprotokolle werden an Cloud Logging weitergeleitet. Wenn du strukturierte Logs verwendest, kannst du Metadaten hinzufügen, die dir bei der Fehlersuche in der Produktion helfen. In Kapitel 9 werde ich strukturierten Protokollen anhand eines praktischen Beispiels auf den Grund gehen.
Transparente Einsätze
Ich weiß nicht, wie es dir geht, aber ich persönlich habe Angst, wenn ich langsame oder komplizierte Einsätze erlebe. Ich würde sagen, einen Thriller zu sehen, ist vergleichbar. Und wenn ich auf meinem lokalen Rechner viel orchestrieren muss, um alles richtig zu machen, ist das doppelt so schlimm. Bei Cloud Run sind für die Bereitstellung und Konfigurationsänderungen nicht viele Handgriffe erforderlich, und fortgeschrittene Bereitstellungsstrategien wie ein schrittweiser Rollout oder blau-grüne Bereitstellungen werden von Anfang an unterstützt. Wenn du dafür sorgst, dass deine App innerhalb von Sekunden nach dem Start des Containers für neue Anfragen bereit ist, verkürzt du die Zeit, die du für die Bereitstellung einer neuen Version brauchst.
Pay-Per-Use
Cloud Run berechnet dir die Ressourcen (CPU und Speicher), die deine Container nutzen, wenn sie Anfragen bedienen. Selbst wenn Cloud Run aus irgendeinem Grund beschließt, deinen Container weiterlaufen zu lassen, wenn er keine Anfragen bedient, zahlst du nicht dafür. Überraschenderweise lässt Cloud Run diese Container im Leerlauf viel länger laufen, als du erwarten würdest. Das erkläre ich dir in Kapitel 2 genauer.
Bedenken über Serverless
Bisher habe ich nur die Gründe aufgezeigt, warum du Serverless einsetzen solltest. Du solltest dir aber bewusst sein, dass Serverless zwar bestimmte Probleme löst, aber auch neue schafft. Lass uns darüber sprechen, worüber du dir Sorgen machen solltest. Welche Risiken gehst du ein, wenn du Serverless einführst, und was kannst du dagegen tun?
Unvorhersehbare Kosten
Das Kostenmodell ist bei Serverless anders, und das bedeutet, dass die Architektur deines Systems einen direkteren und sichtbareren Einfluss auf die laufenden Kosten deines Systems hat. Außerdem birgt die schnelle Autoskalierung das Risiko einer unvorhersehbaren Abrechnung. Wenn du ein serverloses System betreibst, das elastisch skaliert, wird die große Nachfrage bedient, und du wirst dafür bezahlen. Genau wie Leistung, Sicherheit und Skalierbarkeit sind auch die Kosten jetzt ein Qualitätsaspekt deines Codes, den du als Entwickler/in im Blick haben musst und kontrollieren kannst.
Lass dich von diesem Absatz nicht abschrecken: Du kannst Grenzen für das Skalierungsverhalten setzen und die Menge der Ressourcen, die deinen Containern zur Verfügung stehen, fein abstimmen. Du kannst auch Lasttests durchführen, um die Kosten vorherzusagen.
Hyper-Skalierbarkeit
Cloud Run kann sehr schnell auf eine große Anzahl von Container-Instanzen skalieren. Das kann zu Problemen für nachgelagerte Systeme führen, die ihre Kapazität nicht so schnell erhöhen können oder die Schwierigkeiten haben, eine hochgradig gleichzeitige Arbeitslast zu bedienen, wie z. B. traditionelle relationale Datenbanken und externe APIs mit erzwungenen Ratenbeschränkungen. In Kapitel 4 werde ich untersuchen, wie du deine relationale Datenbank vor zu viel Gleichzeitigkeit schützen kannst.
Wenn die Dinge wirklich schief laufen
Wenn du deine Software auf einer Plattform laufen lässt, die dir nicht gehört und die du nicht kontrollierst, bist du der Gnade deines Anbieters ausgeliefert, wenn etwas wirklich schief läuft. Damit meine ich nicht, wenn dein Code einen alltäglichen Fehler hat, den du leicht erkennen und beheben kannst. Mit "wirklich schief" meine ich zum Beispiel, wenn deine Software in der Produktion versagt und du keine Möglichkeit hast, den Fehler zu reproduzieren, wenn du sie lokal ausführst, weil der Fehler wirklich in der vom Anbieter kontrollierten Plattform liegt.
Wenn du in einer herkömmlichen serverbasierten Infrastruktur mit einem Fehler oder Leistungsproblem konfrontiert wirst, das du dir nicht erklären kannst, kannst du einen Blick unter die Haube werfen, weil du den gesamten Stack kontrollierst. Es gibt eine Fülle von Tools, die dir helfen können, herauszufinden, was passiert, sogar in der Produktion. Bei einer Plattform, die vom Anbieter kontrolliert wird, kannst du nur ein Support-Ticket einreichen.
Trennung von Datenverarbeitung und Speicherung
Wenn du Cloud Run verwendest, musst du Daten, die extern aufbewahrt werden müssen, in einer Datenbank oder in einer Blob-Speicherung speichern. Dies wird als Trennung von Rechenleistung und Speicherung bezeichnet, . Auf diese Weise erreicht Cloud Run Skalierbarkeit. Bei Workloads, die von einem schnellen, zufälligen Zugriff auf viele Daten profitieren (die nicht in den RAM passen), kann dies jedoch zu Verzögerungen bei der Verarbeitung von Anfragen führen. Dies wird zum Teil durch das interne Netzwerk in einem Google Cloud-Rechenzentrum gemildert, das in der Regel sehr schnell ist und nur geringe Latenzzeiten aufweist.
Open-Source-Kompatibilität
Portabilität ist wichtig - du willst deine Anwendung von einem Anbieter zu einem anderen migrieren können, ohne mit großen Herausforderungen konfrontiert zu werden. Während ich dieses Kapitel schrieb, schlugen die CIOs von hundert großen Unternehmen in den Niederlanden Alarm, weil ihre Software-Lieferanten die Geschäftsbedingungen einseitig änderten und dann Audits und erhebliche Zusatzkosten von den Unternehmen verlangten. Ich denke, das zeigt deutlich, warum es wichtig ist, einen "Ausweg" zu haben und sicherzustellen, dass ein Anbieter niemals einen solchen Einfluss bekommt. Auch wenn du Google heute vertraust, weißt du nie, was die Zukunft bringt.
Es gibt zwei Gründe, warum Cloud Run portabel ist. Erstens ist es containerbasiert. Wenn ein Container auf Cloud Run läuft, kann er auf jeder Container-Engine laufen, egal wo. Zweitens: Wenn du eine komplexe verteilte Anwendung mit vielen Cloud Run-Diensten gebaut hast, die zusammenarbeiten, machst du dir vielleicht Sorgen über die Portabilität der Plattform selbst. Cloud Run ist API-kompatibel mit dem Open-Source-Produkt Knative. Das bedeutet, dass du mit geringem Aufwand von Cloud Run zu einem selbst gehosteten Kubernetes-Cluster (der Open-Source-Container-Plattform) mit installiertem Knative migrieren kannst.2 Kubernetes ist der De-facto-Standard, wenn du Container auf einem Cluster von Servern einsetzen willst.
In deinem eigenen Rechenzentrum hast du die volle Kontrolle über deine Infrastruktur, aber deine Entwickler haben trotzdem ein "serverloses" Entwicklererlebnis, wenn du Knative einsetzt. In Kapitel 10 gehe ich näher auf Knative ein.
Zusammenfassung
In diesem ersten Kapitel hast du gelernt, was Serverless eigentlich bedeutet und was seine wichtigsten Merkmale sind. Außerdem hast du einen Überblick über Google Cloud bekommen und gesehen, dass Serverless nicht auf Anwendungen beschränkt ist, die HTTPS-Anfragen verarbeiten. Auch Datenbanken und Aufgabenwarteschlangen können serverlos sein.
Serverless ist ideal für dich, wenn du Wert auf ein einfaches und schnelles Entwicklererlebnis legst und keine traditionelle Serverinfrastruktur aufbauen und warten willst. Die Server sind immer noch da - du musst sie nur nicht mehr verwalten.
Wenn du dich für Cloud Run entscheidest, ist deine Anwendung trotzdem portabel. Sie ist containerbasiert und die Cloud Run-Plattform selbst basiert auf der offenen Knative-Spezifikation.
Vielleicht hast du nach dem Lesen dieses ersten Kapitels noch viele Fragen. Das ist auch gut so! Wenn du dich mit mir auf diese serverlose Reise begibst, ermutige ich dich, alles zu vergessen, was du bisher über die Verwaltung von Serverinfrastrukturen gelernt hast.
1 Verma Abhishek et al., "Large-scale cluster management at Google with Borg", Proceedings of EuroSys (2015).
2 Achte darauf, dass du den Quellcode deiner Anwendung nicht zu eng an die Google Cloud-Dienste bindest, ohne dass es OSS-Alternativen gibt, sonst könntest du den Vorteil der Portabilität verlieren.
Get Serverlose Anwendungen mit Google Cloud Run erstellen now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
