Cloud Native Go

Kapitel 1. Was ist eine "Cloud Native"-Anwendung?

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

Der gefährlichste Satz in der Sprache ist: "Das haben wir schon immer so gemacht."¹

Grace Hopper, Computerworld (Januar 1976)

Wenn du dieses Buch liest, dann hast du zweifellos schon einmal den Begriff cloud native gehört. Wahrscheinlicher ist, dass du einige der vielen, vielen Artikel gelesen hast, die von Anbietern geschrieben wurden, die vor atemloser Bewunderung und Dollarzeichen in den Augen sprudeln. Wenn das der Großteil deiner bisherigen Erfahrungen mit dem Begriff ist, kann man dir verzeihen, wenn du ihn für zweideutig und schwammig hältst, für einen weiteren von vielen marktschreierischen Ausdrücken, die vielleicht als etwas Nützliches begonnen haben, aber inzwischen von Leuten übernommen wurden, die dir etwas verkaufen wollen. Siehe auch: Agil, DevOps.

Aus ähnlichen Gründen könnte eine Websuche nach der "Cloud-Native-Definition" dazu führen, dass du denkst, dass alles, was eine Anwendung braucht, um Cloud-Native zu sein, darin besteht, dass sie in der "richtigen" Sprache² oder Framework zu schreiben oder die "richtige" Technologie zu verwenden. Sicherlich kann die Wahl der Sprache dein Leben erheblich erleichtern oder erschweren, aber sie ist weder notwendig noch ausreichend, um eine Anwendung Cloud-nativ zu machen.

Ist Cloud Native also nur eine Frage des Ortes, an dem eine Anwendung läuft? Der Begriff "Cloud Native" suggeriert das jedenfalls. Alles, was du tun musst, ist, deine klobige³ alte Anwendung in einen Container zu packen und in Kubernetes laufen zu lassen, und schon bist du Cloud-nativ, oder? Nein. Das Einzige, was du getan hast, ist, dass deine Anwendung schwieriger zu implementieren und zu verwalten ist.⁴ Eine klobige Anwendung in Kubernetes ist immer noch klobig.

Was ist also eine Cloud Native Application? In diesem Kapitel werden wir genau das beantworten. Zunächst werden wir die Geschichte der Paradigmen für Computing-Dienste bis in die Gegenwart hinein untersuchen und erörtern, wie der unerbittliche Druck zur Skalierung die Entwicklung und Einführung von Technologien vorangetrieben hat (und weiterhin vorantreibt), die ein hohes Maß an Zuverlässigkeit in oft riesigem Maßstab bieten. Abschließend werden wir die spezifischen Merkmale einer solchen Anwendung aufzeigen.

Die Geschichte bis jetzt

Die Geschichte der vernetzten Anwendungen ist die Geschichte des Drucks zur Skalierung.

In den späten 1950er Jahren wurde der Großrechner eingeführt. Damals wurden alle Programme und Daten in einer einzigen riesigen Maschine gespeichert, auf die die Benutzer mit Hilfe von stummen Terminals ohne eigene Rechenleistung zugreifen konnten. Die gesamte Logik und alle Daten lebten zusammen als ein großer glücklicher Monolith. Es war eineeinfachere Zeit.

In den 1980er Jahren änderte sich alles mit dem Aufkommen preiswerter PCs mit Netzwerkanschluss. Im Gegensatz zu stummen Terminals waren PCs in der Lage, eigene Berechnungen durchzuführen, so dass ein Teil der Anwendungslogik auf sie übertragen werden konnte. Diese neuemehrstufige Architektur - die eine Trennung von Präsentationslogik, Geschäftslogik und Daten vorsah(Abbildung 1-1) - machte es erstmals möglich, dass die Komponenten einer vernetzten Anwendung unabhängig voneinander geändert oder ersetzt werden konnten.

Abbildung 1-1. Eine traditionelle dreistufige Architektur mit klar definierten Komponenten für Präsentation, Geschäftslogik und Daten

In den 1990er Jahren wurde mit der Verbreitung des World Wide Web und dem anschließenden "Dot-Com"-Goldrausch die Welt mit Software as a Service (SaaS) bekannt gemacht. Ganze Branchen wurden auf dem SaaS-Modell aufgebaut und trieben die Entwicklung komplexerer und ressourcenintensiverer Anwendungen voran, die wiederum schwieriger zu entwickeln, zu warten und bereitzustellen waren. Plötzlich reichte die klassische mehrstufige Architektur nicht mehr aus. Als Reaktion darauf wurde die Geschäftslogik in Teilkomponenten zerlegt, die unabhängig voneinanderentwickelt, gewartet und eingesetztwerden konnten.

Im Jahr 2006 startete Amazon die Amazon Web Services (AWS), zu denen auch der Dienst Elastic Compute Cloud (EC2) gehörte. AWS war zwar nicht das erste Infrastruktur-as-a-Service (IaaS)-Angebot, aber es revolutionierte die On-Demand-Verfügbarkeit von Datenspeicherung und Rechenressourcen, indem es Cloud Computing - und die Fähigkeit, schnell zu skalieren - der breiten Masse zugänglich machte und eine massive Migration von Ressourcen in die "Cloud" auslöste.

Leider haben die Unternehmen bald gelernt, dass das Leben in großem Maßstab nicht einfach ist. Wenn du mit Hunderten oder Tausenden von Ressourcen (oder mehr!) arbeitest, passieren oft schlimme Dinge. Der Datenverkehr steigt oder fällt, wichtige Hardware schlägt fehl, vorgelagerte Abhängigkeiten werden plötzlich und unerklärlich unerreichbar. Selbst wenn eine Zeit lang nichts schiefgeht, musst du all diese Ressourcen bereitstellen und verwalten. In dieser Größenordnung ist es für Menschen unmöglich (oder zumindest äußerst unpraktisch), mit all diesen Problemen manuell umzugehen.

Vorgelagerte und nachgelagerte Abhängigkeiten

In diesem Buch werden wir manchmal die Begriffe "Upstream-Abhängigkeit" und "Downstream-Abhängigkeit" verwenden, um die relative Position von zwei Ressourcen in einer Abhängigkeitsbeziehung zu beschreiben. In der Branche gibt es keinen wirklichen Konsens über die Richtung dieser Begriffe, deshalb werden sie in diesem Buch wie folgt verwendet:

Stell dir vor, wir haben drei Dienste: A, B und C, wie in der folgenden Abbildung dargestellt:

In diesem Szenario stellt Dienst A Anfragen an Dienst B (und ist daher von diesem abhängig), der wiederum von Dienst C abhängt.

Da Service B von Service C abhängt, können wir sagen, dass Service C eine nachgelagerte Abhängigkeit von Service B ist. Da Service A von Service B abhängt, der wiederum von Service C abhängt, ist Service C ebenfalls eine transitive nachgelagerte Abhängigkeit vonService A.

Da Service C von Service B abhängig ist, können wir umgekehrt sagen, dass Service B eine vorgelagerte Abhängigkeit von Service C ist, und dass Service A eine transitive vorgelagerte Abhängigkeit von Service A ist.

Was ist Cloud Native?

Im Grunde genommen beinhaltet eine wirklich Cloud-native Anwendung alles, was wir in den letzten 60 Jahren über den Betrieb vernetzter Anwendungen in großem Maßstab gelernt haben. Sie sind skalierbar bei stark schwankender Last, widerstandsfähig bei unsicheren Umgebungsbedingungen und verwaltbar bei sich ständig ändernden Anforderungen. Mit anderen Worten: Eine Cloud-native Anwendung ist für das Leben in einem grausamen, ungewissen Universum gebaut.

Aber wie definieren wir den Begriff Cloud Native? Zum Glück für uns alle,⁵ müssen wir das nicht. Die Cloud Native Computing Foundation - eineUnterstiftung der renommierten Linux Foundation und so etwas wie eine anerkannte Autorität auf diesem Gebiet - hat das bereits für uns getan:

Cloud-native Technologien ermöglichen es Unternehmen, skalierbare Anwendungen in modernen, dynamischen Umgebungen wie öffentlichen, privaten und hybriden Clouds zu entwickeln und zu betreiben....

Diese Techniken ermöglichen lose gekoppelte Systeme, die widerstandsfähig, verwaltbar und beobachtbar sind. In Kombination mit robuster Automatisierung ermöglichen sie es Ingenieuren, mit minimalem Aufwand häufig und vorhersehbar Änderungen vorzunehmen.⁶

Cloud Native Computing Foundation, CNCF Cloud Native Definition v1.0

Nach dieser Definition sind Cloud Native Applications mehr als nur Anwendungen, die in einer Cloud laufen. Sie sind auch skalierbar, lose gekoppelt, widerstandsfähig, verwaltbar und beobachtbar. Zusammengenommen bilden diese "Cloud Native Attribute" die Grundlage dafür, was ein System als Cloud Native bezeichnet.

Wie sich herausstellt, hat jedes dieser Wörter eine ganz eigene Bedeutung, also lass uns mal nachschauen.

Skalierbarkeit

Im Zusammenhang mit Cloud Computing kann Skalierbarkeit als die Fähigkeit eines Systems definiert werden, sich auch bei starkem Anstieg oder Rückgang der Nachfrage weiterhin wie erwartet zu verhalten. Ein System gilt als skalierbar, wenn es während oder nach einem starken Anstieg der Nachfrage nicht umstrukturiert werden muss, um seine beabsichtigte Funktion zu erfüllen.

Da nicht skalierbare Dienste unter den anfänglichen Bedingungen perfekt zu funktionieren scheinen, wird die Skalierbarkeit bei der Entwicklung von Diensten nicht immer in den Vordergrund gestellt. Kurzfristig mag das in Ordnung sein, aber Dienste, die nicht in der Lage sind, über ihre ursprünglichen Erwartungen hinaus zu wachsen, haben auch einen begrenzten Lebenszeitwert. Außerdem ist es oft verdammt schwierig, einen Dienst für die Skalierbarkeit zu überarbeiten.

Es gibt zwei verschiedene Möglichkeiten, wie ein Dienst skaliert werden kann, jede mit ihren eigenen Vor- und Nachteilen:

Vertikale Skalierung

Ein System kann vertikal skaliert werden, indem die ihm bereits zugewiesenen Hardwareressourcen vergrößert (oder verkleinert) werden. Zum Beispiel durch Hinzufügen von Arbeitsspeicher oder CPU zu einer Datenbank, die auf einer dedizierten Recheninstanz läuft. Vertikale Skalierung hat den Vorteil, dass sie technisch relativ einfach ist, aber jede Instanz kann nur bis zu einem bestimmten Grad vergrößert werden.

Horizontale Skalierung

Ein System kann horizontal skaliert (oder verkleinert) werden, indem Service-Instanzen hinzugefügt (oder entfernt) werden. Dies kann zum Beispiel durch die Erhöhung der Anzahl der Service-Knoten hinter einem Load Balancer oder Containern in Kubernetes oder einem anderen Container-Orchestrierungssystem geschehen. Diese Strategie hat eine Reihe von Vorteilen, z. B. Redundanz und Unabhängigkeit von den Grenzen der verfügbaren Instanzgrößen. Mehr Replikate bedeuten jedoch eine höhere Komplexität bei Design und Management, und nicht alle Dienste können horizontal skaliert werden.

Da es zwei Möglichkeiten gibt, einen Dienst nach oben oder nach unten zu skalieren - bedeutet das, dass jeder Dienst, dessen Hardware nach oben skaliert werden kann (und der in der Lage ist, die Vorteile der größeren Hardware-Ressourcen zu nutzen), "skalierbar" ist? Wenn du Haarspalterei betreiben willst, dann ja, bis zu einem gewissen Punkt. Aber wie skalierbar ist er? Die vertikale Skalierung ist naturgemäß durch die Größe der verfügbaren Rechenressourcen begrenzt, so dass ein Dienst, der nur nach oben skaliert werden kann, nicht sehr skalierbar ist. Wenn du das Zehnfache, Hundertfache oder Tausendfache erreichen willst, muss dein Dienst wirklich horizontal skalierbar sein.

Was ist also der Unterschied zwischen einem horizontal skalierbaren und einem nicht skalierbaren Dienst? Es läuft alles auf eine Sache hinaus: den Zustand. Ein Dienst, der keinen Anwendungsstatus verwaltet - oder der sehr sorgfältig darauf ausgelegt ist, seinen Status zwischen den Replikaten des Dienstes zu verteilen -, lässt sich relativ einfach skalieren. Für jede andere Anwendung wird es schwierig. So einfach ist das.

Die Konzepte der Skalierbarkeit, des Zustands und der Redundanz werden in Kapitel 7 noch ausführlicher behandelt.

Lose Kopplung

Lose Kopplung ist eine Systemeigenschaft und Entwurfsstrategie, bei der die Komponenten eines Systems nur minimale Kenntnisse über andere Komponenten haben. Zwei Systeme gelten als lose gekoppelt, wenn Änderungen an einer Komponente im Allgemeinen keine Änderungen an der anderen erfordern.

Webserver und Webbrowser können zum Beispiel als lose gekoppelt betrachtet werden: Server können aktualisiert oder sogar komplett ersetzt werden, ohne dass sich dies auf unsere Browser auswirkt. In ihrem Fall ist das möglich, weil Standard-Webserver vereinbart haben, dass sie über eine Reihe von Standardprotokollen kommunizieren.⁷ Mit anderen Worten: Sie bieten einen Dienstleistungsvertrag an. Stell dir das Chaos vor, wenn alle Webbrowser der Welt jedes Mal aktualisiert werden müssten, wenn es eine neue Version von NGINX oder httpd gibt!⁸

Man könnte sagen, dass "lose Kopplung" nur eine Umformulierung des Sinns von Microservice-Architekturen ist: Komponenten so aufzuteilen, dass Änderungen an einer Komponente nicht unbedingt Auswirkungen auf andere haben. Das mag sogar wahr sein. Dieses Prinzip wird jedoch oft vernachlässigt und sollte daher wiederholt werden. Die Vorteile der losen Kopplung - und die Konsequenzen, wenn sie vernachlässigt wird - können nicht hoch genug eingeschätzt werden. Es ist sehr einfach, ein System zu schaffen, das den Verwaltungs- und Komplexitätsaufwand mehrerer Dienste mit den Abhängigkeiten und Verstrickungen eines monolithischen Systems kombiniert: den gefürchteten verteilten Monolithen.

Leider gibt es keine magische Technologie oder ein Protokoll, das verhindern kann, dass deine Dienste eng miteinander gekoppelt sind. Jedes Datenaustauschformat kann missbraucht werden. Es gibt jedoch einige, die hilfreich sind und - zusammen mit Praktiken wie deklarativen APIs und guter Versionskontrolle - dazu beitragen, Dienste zu erstellen, die sowohl lose gekoppelt als auch veränderbar sind.

Diese Technologien und Praktiken werden in Kapitel 8 im Detail besprochen und demonstriert.

Resilienz

Resilienz (ungefähr gleichbedeutend mit Fehlertoleranz) ist ein Maß dafür, wie gut ein System Fehlern und Störungen standhält und sich davon erholt. Ein System gilt alsresilient, wenn es weiterhin ordnungsgemäß funktionieren kann - möglicherweise auf einem reduzierten Niveau - und nicht komplett ausfällt, wenn ein Teil des Systems fehlschlägt.

Wenn wir über Resilienz sprechen (und auch über die anderen "Cloud-nativen Attribute", aber vor allem, wenn wir über Resilienz sprechen), verwenden wir sehr oft das Wort "System". Je nachdem, wie es verwendet wird, kann ein System ein komplexes Netz von miteinander verbundenen Diensten (z. B. eine ganze verteilte Anwendung), eine Sammlung eng miteinander verbundener Komponenten (z. B. die Replikate einer einzelnen Funktion oder Dienstinstanz) oder einen einzelnen Prozess auf einem einzelnen Rechner bezeichnen. Jedes System besteht aus mehreren Subsystemen, die wiederum aus Sub-Subsystemen bestehen, die wiederum aus Sub-Sub-Subsystemen zusammengesetzt sind. Das sind alles Schildkröten, die den ganzen Weg nach unten gehen.

In der Sprache der Systemtechnik kann jedes System Defekte oder Fehler enthalten, die wir in der Softwarewelt liebevoll als Bugs bezeichnen. Wie wir alle nur zu gut wissen, kann jeder Fehler unter bestimmten Bedingungen zu einem Fehler führen. So nennen wir jede Abweichung zwischen dem beabsichtigten Verhalten eines Systems und seinem tatsächlichen Verhalten. Fehler können dazu führen, dass ein System die gewünschte Funktion nicht erfüllt: ein Fehlschlag. Das ist aber noch nicht alles: Ein Fehler in einem Teilsystem oder einer Komponente wird zu einem Fehler im Gesamtsystem; jeder Fehler, der nicht richtig eingedämmt wird, kann sich kaskadenartig ausbreiten, bis er zu einem Totalausfall des Systems führt.

In einer idealen Welt wäre jedes System so konzipiert, dass Fehler gar nicht erst auftreten, aber das ist ein unrealistisches Ziel. Man kann nicht jeden möglichen Fehler verhindern, und es ist verschwenderisch und unproduktiv, das zu versuchen. Wenn man jedoch davon ausgeht, dass alle Komponenten eines Systems fehlschlagen können - was der Fall ist - und sie so konzipiert, dass sie auf potenzielle Fehler reagieren und die Auswirkungen von Fehlern begrenzen, kann man ein System schaffen, das auch dann noch funktioniert, wenn einige seiner Komponenten nicht funktionieren.

Es gibt viele Möglichkeiten, ein System so zu gestalten, dass es widerstandsfähig ist. Der Einsatz von redundanten Komponenten ist vielleicht der gängigste Ansatz, aber das setzt auch voraus, dass ein Fehler nicht alle Komponenten desselben Typs beeinträchtigt. Stromkreisunterbrecher und Wiederholungslogik können eingebaut werden, um zu verhindern, dass sich Fehler zwischen den Komponenten ausbreiten. Fehlerhafte Komponenten können sogar wiederhergestellt werden - oder absichtlich fehlschlagen, um das Gesamtsystem zu verbessern.

Wir werden all diese Ansätze (und noch mehr) in Kapitel 9 ausführlicher besprechen.

Resilienz ist keine Zuverlässigkeit

Die Begriffe Resilienz und Zuverlässigkeit beschreiben eng verwandte Konzepte und werden oft verwechselt. Aber wie wir in Kapitel 9 erläutern werden, sind sie nicht ganz dasselbe:⁹

• Die Ausfallsicherheit eines Systems ist der Grad, in dem es bei Fehlern und Störungen weiterhin korrekt funktionieren kann. Die Ausfallsicherheit ist neben den anderen vier Cloud-Eigenschaften nur ein Faktor, der zur Zuverlässigkeit beiträgt.

• Die Zuverlässigkeit eines Systems ist seine Fähigkeit, sich über einen bestimmten Zeitraum hinweg wie erwartet zu verhalten. In Verbindung mit Attributen wie Verfügbarkeit und Wartbarkeit trägt die Zuverlässigkeit zur Gesamtzuverlässigkeit eines Systems bei.

Verwaltbarkeit

Die Verwaltbarkeit eines Systems ist die Leichtigkeit (oder das Fehlen einer solchen), mit der sein Verhalten geändert werden kann, damit es sicher ist, reibungslos funktioniert und mit den sich ändernden Anforderungen übereinstimmt. Ein System gilt als verwaltbar, wenn es möglich ist, sein Verhalten ausreichend zu ändern, ohne den Code zu verändern.

Als Systemeigenschaft wird der Verwaltbarkeit viel weniger Aufmerksamkeit geschenkt als einigen der auffälligeren Eigenschaften wie Skalierbarkeit oder Beobachtbarkeit. Dabei ist sie genauso wichtig, vor allem in komplexen, verteilten Systemen.

Stell dir z.B. ein hypothetisches System vor, das einen Dienst und eine Datenbank enthält, und dass der Dienst über eine URL auf die Datenbank verweist. Was wäre, wenn du diesen Dienst aktualisieren müsstest, damit er auf eine andere Datenbank verweist? Wenn die URL fest kodiert ist, müsstest du den Code aktualisieren und neu bereitstellen, was je nach System aus verschiedenen Gründen umständlich sein kann. Natürlich könntest du den DNS-Eintrag aktualisieren, um auf den neuen Standort zu verweisen, aber was ist, wenn du eine Entwicklungsversion des Dienstes mit einer eigenen Entwicklungsdatenbank neu bereitstellen musst?

Ein überschaubares System könnte diesen Wert zum Beispiel als leicht zu ändernde Umgebungsvariable darstellen; wenn der Dienst, der ihn nutzt, in Kubernetes eingesetzt wird, könnte die Anpassung seines Verhaltens eine Frage der Aktualisierung eines Wertes in einer ConfigMap sein. Ein komplexeres System könnte sogar eine deklarative API bereitstellen, mit der ein Entwickler dem System mitteilen kann, welches Verhalten er erwartet. Es gibt keine einzig richtige Antwort.¹⁰

Verwaltbarkeit ist nicht auf Konfigurationsänderungen beschränkt. Sie umfasst alle möglichen Dimensionen des Systemverhaltens, z. B. die Möglichkeit, Feature-Flags zu aktivieren, Anmeldeinformationen oder TLS-Zertifikate zu ändern oder sogar (und vielleicht vor allem) Systemkomponenten bereitzustellen oder zu aktualisieren (oder herunterzustufen).

Verwaltbare Systeme sind auf Anpassungsfähigkeit ausgelegt und können leicht an sich ändernde Funktions-, Umwelt- oder Sicherheitsanforderungen angepasst werden. Nicht verwaltbare Systeme hingegen sind in der Regel sehr viel instabiler und müssen häufig ad hoc - oft manuell - geändert werden. Der mit der Verwaltung solcher Systeme verbundene Aufwand setzt ihrer Skalierbarkeit, Verfügbarkeit und Zuverlässigkeit grundlegende Grenzen.

Das Konzept der Verwaltbarkeit - und einige bevorzugte Praktiken, um sie in Go umzusetzen - werden in Kapitel 10 ausführlicher behandelt.

Verwaltbarkeit ist nicht Wartbarkeit

Man kann sagen, dass sich Verwaltbarkeit und Wartbarkeit in gewisser Weise überschneiden, da es bei beiden darum geht, wie leicht ein System geändert werden kann,¹¹ aber eigentlich sind sie ziemlich unterschiedlich:

• Verwaltbarkeit beschreibt die Leichtigkeit, mit der Änderungen am Verhalten eines laufenden Systems vorgenommen werden können, bis hin zur Bereitstellung (und Neubereitstellung) von Komponenten dieses Systems. Es geht darum, wie einfach es ist, Änderungen von außen vorzunehmen.

• Wartungsfreundlichkeit beschreibt die Leichtigkeit, mit der Änderungen an der zugrundeliegenden Funktionalität eines Systems, meist am Code, vorgenommen werden können. Es geht darum, wie einfach es ist, Änderungen von innen heraus vorzunehmen.

Beobachtbarkeit

Die Beobachtbarkeit eines Systems ist ein Maß dafür, wie gut seine internen Zustände aus dem Wissen über seine externen Ausgaben abgeleitet werden können. Ein System gilt als beobachtbar, wenn es möglich ist, mit minimalem Vorwissen schnell und konsistent neue Fragen über das System zu stellen, ohne es neu instrumentieren oder programmieren zu müssen.

Auf den ersten Blick mag das einfach klingen: Du brauchst nur ein paar Logging-Funktionen und ein paar Dashboards, und schon ist dein System beobachtbar, oder? Mit ziemlicher Sicherheit nicht. Nicht bei modernen, komplexen Systemen, bei denen fast jedes Problem der Ausdruck eines Geflechts von mehreren Dingen ist, die gleichzeitig schief laufen. Das Zeitalter des LAMP-Stacks ist vorbei; die Dinge sind jetzt schwieriger.

Das soll nicht heißen, dass Metriken, Logging und Tracing nicht wichtig sind. Im Gegenteil: Sie sind die Bausteine der Beobachtbarkeit. Aber ihre bloße Existenz ist nicht genug: Daten sind keine Informationen. Sie müssen auf die richtige Weise genutzt werden. Sie müssen reichhaltig sein. Zusammen müssen sie in der Lage sein, Fragen zu beantworten, an die du bisher noch nicht einmal gedacht hast.

Die Fähigkeit, Probleme zu erkennen und zu beheben, ist eine grundlegende Voraussetzung für die Wartung und Weiterentwicklung eines robusten Systems. Aber in einem verteilten System ist es oft schon schwer genug, herauszufinden, wo ein Problem liegt. Komplexe Systeme sind einfach zu...komplex. Die Anzahl der möglichen Fehlerzustände eines Systems ist proportional zum Produkt aus der Anzahl der möglichen Teil- und Komplettausfälle der einzelnen Komponenten, und es ist unmöglich, sie alle vorherzusagen. Der traditionelle Ansatz, sich auf die Dinge zu konzentrieren, von denen wir erwarten, dass sie fehlschlagen, reicht einfach nicht aus.

Die aufkommenden Praktiken der Beobachtbarkeit können als die Evolution des Monitorings angesehen werden. Die jahrelange Erfahrung mit der Entwicklung, dem Aufbau und der Wartung komplexer Systeme hat uns gelehrt, dass die traditionellen Methoden der Instrumentierung - einschließlich, aber nicht beschränkt auf Dashboards, unstrukturierte Protokolle oder Alarme bei verschiedenen "bekannten Unbekannten" - den Herausforderungen moderner verteilter Systeme einfach nicht gewachsen sind.

Beobachtbarkeit ist ein komplexes und subtiles Thema, aber im Grunde genommen läuft es darauf hinaus, dass du deine Systeme ausreichend mit Instrumenten ausstatten und in realen Szenarien testen solltest, damit du in Zukunft Fragen beantworten kannst, an die du bisher noch nicht gedacht hast.

Das Konzept der Beobachtbarkeit - und einige Vorschläge zu seiner Umsetzung - werden in Kapitel 11 ausführlicher behandelt.

Warum ist Cloud Native eine Sache?

Die Entwicklung hin zu "Cloud Native" ist ein Beispiel für architektonische und technische Anpassung, die durch Umweltdruck und Selektion angetrieben wird. Es ist die Evolution - das Überleben des Stärkeren. Ich bin von Haus aus Biologe.

Vor Äonen, in den Anfängen der Zeit,¹² wurden Anwendungen entwickelt und (in der Regel von Hand) auf einem oder wenigen Servern installiert, wo sie sorgfältig gepflegt und gehegt wurden. Wenn sie krank wurden, wurden sie liebevoll gepflegt und wieder gesund gemacht. Wenn ein Dienst ausfiel, konnte man ihn oft mit einem Neustart reparieren. Beobachtbarkeit bedeutete, dass man sich in einen Server einklinken musste, um top auszuführen und die Protokolle zu überprüfen. Es war eine einfachere Zeit.

Im Jahr 1997 nutzten nur 11% der Menschen in den Industrieländern und 2% weltweit regelmäßig das Internet. In den darauffolgenden Jahren stiegen der Internetzugang und die Internetnutzung jedoch exponentiell an. 2017 war diese Zahl in den Industrieländern auf 81 % und weltweit auf 48 % angestiegen¹³- und wächst weiter.

All diese Nutzer - und ihr Geld - setzten die Dienste unter Druck, was einen erheblichen Anreiz zur Skalierung bot. Außerdem wuchs mit der zunehmenden Komplexität und Abhängigkeit der Nutzer von Webdiensten auch die Erwartung, dass ihre bevorzugten Webanwendungen sowohl funktionsreich als auch immer verfügbar sein würden.

Das Ergebnis war und ist ein erheblicher evolutionärer Druck in Richtung Skalierung, Komplexität und Verlässlichkeit. Diese drei Attribute passen jedoch nicht gut zusammen, und die traditionellen Ansätze konnten und können damit nicht mithalten. Neue Techniken und Praktiken mussten erfunden werden.

Glücklicherweise war es mit der Einführung von Public Clouds und IaaS relativ einfach, die Infrastruktur zu erweitern. Unzulänglichkeiten bei der Zuverlässigkeit konnten oft durch die schiere Anzahl der Systeme kompensiert werden. Aber das brachte neue Probleme mit sich. Wie kann man hundert Server warten? Tausend? Zehntausend? Wie installierst du deine Anwendung auf ihnen oder aktualisierst sie? Wie behebst du Fehler, wenn sie sich nicht richtig verhält? Woher weißt du überhaupt, dass sie in Ordnung ist? Probleme, die im kleinen Maßstab nur lästig sind, werden im großen Maßstab sehr schwierig.

Cloud Native ist eine Sache, denn Skalierung ist die Ursache (und die Lösung) für all unsere Probleme. Es ist keine Magie. Es ist nichts Besonderes. Abgesehen von den hochtrabenden Worten gibt es Cloud Native-Techniken und -Technologien aus keinem anderen Grund als dem, die Vorteile einer "Wolke" (Quantität) zu nutzen und ihre Nachteile (mangelnde Zuverlässigkeit) auszugleichen.

Zusammenfassung

In diesem Kapitel haben wir viel über die Geschichte des Computing gesprochen und darüber, dass das, was wir heute als "Cloud Native" bezeichnen, kein neues Phänomen ist, sondern das unvermeidliche Ergebnis eines positiven Kreislaufs, bei dem die technologische Nachfrage zu Innovationen führt, die wiederum die Nachfrage steigern.

Letzten Endes laufen all diese hochtrabenden Begriffe jedoch auf einen einzigen Punkt hinaus: Die heutigen Anwendungen müssen zuverlässig viele Menschen bedienen. Die Techniken und Technologien, die wir als "Cloud Native" bezeichnen, sind die bewährten Methoden, um einen Dienst zu entwickeln, der skalierbar, anpassungsfähig und widerstandsfähig genug ist, um dies zu tun.

Aber was hat das alles mit Go zu tun? Es stellt sich heraus, dass eine cloud-native Infrastruktur cloud-native Tools erfordert. In Kapitel 2 werden wir darüber sprechen, was das genau bedeutet.

¹ Surden, Esther. "Privacy Laws May Usher in Defensive DP: Hopper". Computerworld, 26. Jan. 1976, S. 9.

² Das ist Go. Versteh mich nicht falsch - das ist immer noch ein Go-Buch.

³ Ein "Klotz" ist "eine ungeschickte oder unelegante Lösung". Es ist ein faszinierendes Wort mit einer faszinierenden Geschichte.

⁴ Hast du dich jemals gefragt, warum so viele Kubernetes-Migrationen fehlschlagen?

⁵ Besonders für mich. Ich darf dieses coole Buch schreiben.

⁶ Cloud Native Computing Foundation. "CNCF Cloud Native Definition v1.0", GitHub, 7. Dezember 2020. https://oreil.ly/KJuTr.

⁷ Diejenigen unter uns, die sich an die Browserkriege der 1990er Jahre erinnern, werden sich daran erinnern, dass das nicht immer so war.

⁸ Oder wenn jede Website einen anderen Browser erfordert. Das wäre doch stinkend, oder?

⁹ Wenn du an einer vollständigen akademischen Abhandlung interessiert bist, empfehle ich dir das Buch Reliability and Availability Engineering von Kishor S. Trivedi und Andrea Bobbio.

¹⁰ Es gibt aber auch einige falsche.

¹¹ Außerdem fangen sie beide mit M an. Super verwirrend.

¹² Das war in den 1990er Jahren.

¹³ International Telecommunication Union (ITU). "Internetnutzer pro 100 Einwohner 1997 bis 2007" und "Internetnutzer pro 100 Einwohner 2005 bis 2017". ICT Data and Statistics (IDS).