Cloud Native Infrastruktur

Kapitel 1. Was ist eine Cloud Native Infrastructure?

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

Infrastruktur ist die gesamte Software und Hardware, die Anwendungen unterstützt.¹ Dazu gehören Rechenzentren, Betriebssysteme, Bereitstellungspipelines, Konfigurationsmanagement und alle Systeme oder Software, die zur Unterstützung des Lebenszyklus von Anwendungen benötigt werden.

Durch die jahrelange Weiterentwicklung der Technologie und die Verfeinerung der Praktiken sind einige Unternehmen in der Lage, Infrastruktur und Anwendungen in großem Umfang und mit bekannter Agilität zu betreiben. Eine effizient betriebene Infrastruktur beschleunigt das Geschäft, indem sie schnellere Iterationen und kürzere Markteinführungszeiten ermöglicht.

Eine Cloud-native Infrastruktur ist eine Voraussetzung für den effektiven Betrieb von Cloud-nativen Anwendungen. Ohne das richtige Design und die richtigen Praktiken für die Verwaltung der Infrastruktur kann selbst die beste Cloud-native Anwendung im Sande verlaufen. Eine enorme Größe ist keine Voraussetzung, um die in diesem Buch vorgestellten Praktiken zu befolgen, aber wenn du die Vorteile der Cloud nutzen willst, solltest du die Erfahrungen derjenigen beherzigen, die mit diesen Mustern Pionierarbeit geleistet haben.

Bevor wir uns damit beschäftigen, wie wir eine Infrastruktur für den Betrieb von Anwendungen in der Cloud aufbauen können, müssen wir verstehen, wie wir dorthin gekommen sind, wo wir jetzt sind. Zunächst werden wir die Vorteile der Einführung von Cloud Native Practices erörtern. Als Nächstes werfen wir einen kurzen Blick auf die Geschichte der Infrastruktur und erörtern dann die Merkmale der nächsten Stufe, die "Cloud Native" genannt wird, und wie sie sich auf deine Anwendungen, die Plattform, auf der sie laufen, und dein Unternehmen auswirkt.

Sobald du das Problem verstanden hast, zeigen wir dir die Lösung und wie du sie umsetzt.

Cloud Native Vorteile

Die Vorteile der in diesem Buch vorgestellten Muster sind zahlreich: Sie sind erfolgreichen Unternehmen wie Google, Netflix und Amazon nachempfunden - nicht, dass die Muster allein deren Erfolg garantieren würden, aber sie haben diesen Unternehmen die Skalierbarkeit und Agilität verschafft, die sie für ihren Erfolg brauchten.

Wenn du dich dafür entscheidest, deine Infrastruktur in einer öffentlichen Cloud zu betreiben, kannst du schneller Werte schaffen und dich auf deine Geschäftsziele konzentrieren. Indem du nur das baust, was du für dein Produkt brauchst, und Dienste von anderen Anbietern in Anspruch nimmst, bleiben deine Vorlaufzeiten gering und deine Flexibilität hoch. Manche Leute zögern vielleicht wegen der "Anbieterbindung", aber die schlimmste Art der Bindung ist die, die du selbst aufbaust. In Anhang B findest du weitere Informationen über die verschiedenen Arten von Lock-in und was du dagegen tun solltest.

Durch die Nutzung von Diensten kannst du auch eine maßgeschneiderte Plattform mit den von dir benötigten Diensten aufbauen (manchmal auch als Services as a Platform [SaaP] bezeichnet). Wenn du in der Cloud gehostete Dienste nutzt, brauchst du kein Fachwissen für den Betrieb aller Dienste, die deine Anwendungen benötigen. Das hat einen großen Einfluss auf deine Veränderungsfähigkeit und erhöht den Mehrwert für dein Unternehmen.

Wenn du nicht in der Lage bist, Dienste zu konsumieren, solltest du Anwendungen entwickeln, um die Infrastruktur zu verwalten. Dann hängt der Engpass für die Skalierung nicht mehr davon ab, wie viele Server pro Betriebsingenieur verwaltet werden können. Stattdessen kannst du die Skalierung deiner Infrastruktur genauso angehen wie die Skalierung deiner Anwendungen. Mit anderen Worten: Wenn du in der Lage bist, Anwendungen zu betreiben, die skalieren können, kannst du deine Infrastruktur mit Anwendungen skalieren.

Die gleichen Vorteile gelten auch für die Entwicklung einer stabilen und leicht zu debuggenden Infrastruktur. Du kannst Einblicke in deine Infrastruktur gewinnen, indem du dieselben Tools nutzt, die du auch für die Verwaltung deiner Geschäftsanwendungen verwendest.

Cloud-native Methoden können auch die Kluft zwischen den traditionellen Ingenieurrollen überbrücken (ein gemeinsames Ziel von DevOps). Systemingenieure können bewährte Methoden von den Anwendungen lernen, und Anwendungsingenieure können die Verantwortung für die Infrastruktur übernehmen, auf der ihre Anwendungen laufen.

Die Cloud Native Infrastructure ist nicht die Lösung für jedes Problem, und es liegt in deiner Verantwortung zu wissen, ob sie die richtige Lösung für deine Umgebung ist (siehe Kapitel 2). Ihr Erfolg zeigt sich jedoch an den Unternehmen, die die Praktiken entwickelt haben, und an den vielen anderen Unternehmen, die die Tools zur Förderung dieser Muster übernommen haben. In Anhang C findest du ein Beispiel.

Bevor wir uns mit der Lösung beschäftigen, müssen wir verstehen, wie diese Muster aus den Problemen entstanden sind, die sie verursacht haben.

Server

In den Anfängen des Internets wurde die Webinfrastruktur mit physischen Servern aufgebaut. Server sind groß, laut und teuer und benötigen viel Strom und Personal, um sie am Laufen zu halten. Sie werden aufwändig gepflegt und so lange wie möglich am Laufen gehalten. Im Vergleich zur Cloud-Infrastruktur sind sie auch schwieriger zu erwerben und für den Betrieb einer Anwendung vorzubereiten.

Wenn du einen Server kaufst, kannst du ihn auf Gedeih und Verderb behalten. Server gehören zu den etablierten Investitionskosten eines Unternehmens. Je länger du einen physischen Server in Betrieb halten kannst, desto mehr Wert hast du für dein ausgegebenes Geld. Es ist immer wichtig, die Kapazitäten richtig zu planen und sicherzustellen, dass du die beste Rendite für deine Investition erzielst.

Physikalische Server sind großartig, weil sie leistungsfähig sind und nach Belieben konfiguriert werden können. Sie haben eine relativ niedrige Ausfallrate und sind mit redundanten Netzteilen, Lüftern und RAID-Controllern so konzipiert, dass sie Ausfälle vermeiden. Außerdem halten sie sehr lange. Unternehmen können durch verlängerte Garantien und Ersatzteile einen zusätzlichen Wert aus der gekauften Hardware herausholen.

Physische Server führen jedoch zu Verschwendung. Die Server sind nicht nur nie voll ausgelastet, sondern verursachen auch eine Menge Overhead. Es ist schwierig, mehrere Anwendungen auf demselben Server laufen zu lassen. Softwarekonflikte, Netzwerkrouting und Benutzerzugriff werden komplizierter, wenn ein Server mit mehreren Anwendungen maximal ausgelastet ist.

Die Hardware-Virtualisierung versprach, einige dieser Probleme zu lösen.

Virtualisierung

Virtualisierung emuliert die Hardware eines physischen Servers in Software. Ein virtueller Server kann bei Bedarf erstellt werden, ist vollständig in Software programmierbar und nutzt sich nie ab, solange du die Hardware emulieren kannst.

Der Einsatz eines Hypervisors² erhöht diese Vorteile, weil du mehrere virtuelle Maschinen (VMs) auf einem physischen Server betreiben kannst. Außerdem können Anwendungen portabel sein, weil du eine VM von einem physischen Server auf einen anderen verschieben kannst.

Ein Problem beim Betrieb einer eigenen Virtualisierungsplattform ist jedoch, dass VMs nach wie vor Hardware benötigen. Unternehmen brauchen nach wie vor alle Mitarbeiter und Prozesse, die für den Betrieb physischer Server erforderlich sind, aber jetzt wird die Kapazitätsplanung schwieriger, weil sie auch den VM-Overhead berücksichtigen müssen. Zumindest war das bis zur öffentlichen Cloud der Fall.

Infrastruktur als Dienstleistung

Infrastructure as a Service (IaaS) ist eines der vielen Angebote eines Cloud-Providers. Es stellt Netzwerk-, Speicher- und Rechenleistung zur Verfügung, die der Kunde je nach Bedarf nutzen kann. Dazu gehören auch Support-Services wie Identitäts- und Zugriffsmanagement (IAM), Provisioning und Inventarisierungssysteme.

IaaS ermöglicht es Unternehmen, ihre gesamte Hardware loszuwerden und VMs oder physische Server von jemand anderem zu mieten. Dadurch werden viele Personalressourcen freigesetzt und Prozesse, die für den Einkauf, die Wartung und in einigen Fällen auch für die Kapazitätsplanung erforderlich waren, entfallen.

IaaS hat die Beziehung zwischen der Infrastruktur und den Unternehmen grundlegend verändert. Anstatt eine Investition zu sein, von der man im Laufe der Zeit profitiert, ist sie eine Betriebsausgabe für den Betrieb deines Unternehmens. Unternehmen können für ihre Infrastruktur genauso bezahlen wie für Strom und die Zeit ihrer Mitarbeiter. Durch die verbrauchsabhängige Abrechnung werden deine Betriebskosten umso geringer, je früher du die Infrastruktur loswirst.

Mit der gehosteten Infrastruktur wurden auch konsumierbare HTTP Application Programming Interfaces (APIs) geschaffen, mit denen Kunden ihre Infrastruktur nach Bedarf erstellen und verwalten können. Anstatt eine Bestellung aufzugeben und auf die Lieferung von physischen Gegenständen zu warten, können Ingenieure einen API-Aufruf tätigen, und ein Server wird erstellt. Der Server kann genauso einfach gelöscht und entsorgt werden.

Wenn du deine Infrastruktur in einer Cloud betreibst, bedeutet das nicht, dass deine Infrastruktur cloud-nativ ist. IaaS erfordert nach wie vor ein Infrastrukturmanagement. Abgesehen vom Kauf und der Verwaltung physischer Ressourcen kannst du IaaS genauso behandeln wie die herkömmliche Infrastruktur, die sie früher in ihren eigenen Rechenzentren gekauft und untergebracht haben - und viele Unternehmen tun das auch.

Auch ohne "Racking und Stacking" gibt es immer noch viele Betriebssysteme, Überwachungs-Software und Support-Tools. Automatisierungs-Tools³ haben dazu beigetragen, die Zeit zu verkürzen, die es braucht, um eine Anwendung zum Laufen zu bringen, aber oft stehen eingefahrene Prozesse dem vollen Nutzen von IaaS im Weg.

Plattform als Service

Genauso wie IaaS physische Server vor den VM-Konsumenten verbirgt, verbirgt Platform as a Service (PaaS) die Betriebssysteme vor den Anwendungen. Die Entwickler schreiben den Anwendungscode und definieren die Anwendungsabhängigkeiten, und es liegt in der Verantwortung der Plattform, die notwendige Infrastruktur zu schaffen, um sie auszuführen, zu verwalten und zu veröffentlichen. Im Gegensatz zu IaaS, das immer noch ein Infrastrukturmanagement erfordert, wird die Infrastruktur bei PaaS vom Plattformanbieter verwaltet.

Es stellte sich heraus, dass die PaaS-Beschränkungen von den Entwicklern verlangten, ihre Anwendungen anders zu schreiben, um effektiv von der Plattform verwaltet werden zu können. Die Anwendungen mussten Funktionen enthalten, die es ermöglichten, sie von der Plattform zu verwalten, ohne auf das zugrunde liegende Betriebssystem zugreifen zu müssen. Die Ingenieure konnten sich nicht mehr darauf verlassen, dass sie sich per SSH mit einem Server verbinden und die Logdateien auf der Festplatte lesen konnten. Der Lebenszyklus und die Verwaltung der Anwendung wurden nun von der PaaS gesteuert, und Ingenieure und Anwendungen mussten sich darauf einstellen.

Diese Einschränkungen brachten große Vorteile mit sich: Die Entwicklungszyklen von Anwendungen wurden verkürzt, weil die Ingenieure keine Zeit für die Verwaltung der Infrastruktur aufwenden mussten. Anwendungen, die auf einer Plattform liefen, waren der Anfang dessen, was wir heute "Cloud Native Applications" nennen. Sie nutzten die Plattformbeschränkungen in ihrem Code aus und veränderten in vielen Fällen die Art und Weise, wie Anwendungen heute geschrieben werden.

12-Faktoren-Anwendungen

Heroku war einer der frühen Pioniere, die eine öffentlich nutzbare PaaS anboten. Durch die jahrelange Erweiterung der eigenen Plattform konnte das Unternehmen Muster erkennen, die dazu beitragen, dass Anwendungen in ihrer Umgebung besser laufen. Es gibt 12 Hauptfaktoren, die Heroku definiert, die ein Entwickler versuchen sollte zu implementieren.

Bei den 12 Faktoren geht es darum, die Effizienz von Entwicklern zu steigern, indem die Codelogik von den Daten getrennt wird, so viel wie möglich automatisiert wird, getrennte Build-, Ship- und Run-Phasen bestehen und alle Abhängigkeiten der Anwendung deklariert werden.

Wenn du deine gesamte Infrastruktur über einen PaaS-Provider nutzt, hast du bereits viele der Vorteile einer Cloud-Native-Infrastruktur. Dazu gehören Plattformen wie Google App Engine, AWS Lambda und Azure Cloud Services. Jede erfolgreiche Cloud-Native-Infrastruktur bietet Anwendungsingenieuren eine Self-Service-Plattform für die Bereitstellung und Verwaltung ihres Codes.

Viele PaaS-Plattformen reichen jedoch nicht für alle Bedürfnisse eines Unternehmens aus. Sie schränken oft Sprachlaufzeiten, Bibliotheken und Funktionen ein, um ihr Versprechen zu erfüllen, die Infrastruktur von der Anwendung zu abstrahieren. Öffentliche PaaS-Anbieter schränken auch ein, welche Dienste in die Anwendungen integriert werden können und wo diese Anwendungen ausgeführt werden können.

Öffentliche Plattformen tauschen die Anwendungsflexibilität gegen das Problem der Infrastruktur ein. Abbildung 1-1 ist eine visuelle Darstellung der Komponenten, die du verwalten musst, wenn du dein eigenes Rechenzentrum betreibst, eine Infrastruktur in einem IaaS erstellst, deine Anwendungen auf einer PaaS laufen lässt oder Anwendungen über Software as a Service (SaaS) nutzt. Je weniger Infrastrukturkomponenten du betreiben musst, desto besser; aber alle deine Anwendungen bei einem öffentlichen PaaS-Anbieter laufen zu lassen, ist möglicherweise keine Option.

Abbildung 1-1. Infrastruktur-Schichten

Cloud Native Infrastruktur

"Cloud Native" ist ein belasteter Begriff. So sehr er auch von den Marketingabteilungen vereinnahmt wurde, kann er für die Technik und das Management immer noch von Bedeutung sein. Für uns ist er die Weiterentwicklung der Technologie in einer Welt, in der es öffentliche Cloud-Provider gibt.

Cloud Native Infrastructure ist eine Infrastruktur, die sich hinter nützlichen Abstraktionen verbirgt, über APIs gesteuert wird, von Software verwaltet wird und den Zweck hat, Anwendungen auszuführen. Der Betrieb einer Infrastruktur mit diesen Merkmalen führt zu einem neuen Muster für die skalierbare und effiziente Verwaltung dieser Infrastruktur.

Abstraktionen sind nützlich, wenn sie die Komplexität für den Verbraucher erfolgreich verbergen. Sie können komplexere Verwendungen der Technologie ermöglichen, aber sie schränken auch ein, wie die Technologie verwendet wird. Sie gelten für Technologien auf niedriger Ebene, z. B. wie TCP IP abstrahiert, oder auf höherer Ebene, z. B. wie VMs physische Server abstrahieren. Abstraktionen sollten es dem Verbraucher immer ermöglichen, "nach oben zu gehen" und nicht die unteren Schichten neu zu implementieren.

Die native Cloud-Infrastruktur muss die zugrundeliegenden IaaS-Angebote abstrahieren, um ihre eigenen Abstraktionen bereitzustellen. Die neue Schicht ist für die Kontrolle der darunter liegenden IaaS verantwortlich und stellt ihre eigenen APIs zur Verfügung, die von einem Verbraucher kontrolliert werden können.

Eine von Software verwaltete Infrastruktur ist ein wichtiges Unterscheidungsmerkmal in der Cloud. Eine softwaregesteuerte Infrastruktur ermöglicht die Skalierung der Infrastruktur und spielt auch eine Rolle bei der Ausfallsicherheit, der Bereitstellung und der Wartbarkeit. Die Software muss die Abstraktionen der Infrastruktur kennen und wissen, wie sie eine abstrakte Ressource in konsumierbare IaaS-Komponenten umsetzen kann.

Diese Muster beeinflussen nicht nur die Art und Weise, wie die Infrastruktur läuft. Die Arten von Anwendungen, die auf einer Cloud-nativen Infrastruktur laufen, und die Arten von Menschen, die daran arbeiten, unterscheiden sich von denen in einer traditionellen Infrastruktur.

Wenn eine cloud-native Infrastruktur einem PaaS-Angebot sehr ähnlich ist, wie können wir dann wissen, worauf wir beim Aufbau unserer eigenen Infrastruktur achten müssen? Beschreiben wir kurz einige Bereiche, die wie die Lösung aussehen, aber nicht alle Aspekte einer cloud-nativen Infrastruktur bieten.

Was ist keine Cloud Native Infrastructure?

Eine Cloud-native Infrastruktur bedeutet nicht nur, dass die Infrastruktur in einer öffentlichen Cloud betrieben wird. Nur weil du Serverzeit von jemand anderem mietest, ist deine Infrastruktur noch nicht Cloud-nativ. Die Prozesse zur Verwaltung von IaaS unterscheiden sich oft nicht vom Betrieb eines physischen Rechenzentrums, und viele Unternehmen, die ihre bestehende Infrastruktur in die Cloud migriert haben⁴ haben fehlgeschlagen, um die Früchte zu ernten.

Bei Cloud Native geht es nicht darum, Anwendungen in Containern auszuführen. Als Netflix eine Cloud-Native-Infrastruktur einführte, wurden fast alle seine Anwendungen mit Virtual-Machine-Images und nicht mit Containern bereitgestellt. Die Art und Weise, wie du deine Anwendungen verpackst, bedeutet nicht, dass du die Skalierbarkeit und die Vorteile autonomer Systeme nutzen kannst. Selbst wenn deine Anwendungen automatisch mit einer Pipeline für kontinuierliche Integration und kontinuierliche Bereitstellung erstellt und bereitgestellt werden, bedeutet das nicht, dass du von einer Infrastruktur profitierst, die API-gesteuerte Bereitstellungen ergänzen kann.

Es bedeutet auch nicht, dass du nur einen Container-Orchestrator (z.B. Kubernetes und Mesos) betreibst. Container-Orchestratoren bieten viele Plattformfunktionen, die in einer nativen Cloud-Infrastruktur benötigt werden, aber wenn du die Funktionen nicht wie vorgesehen nutzt, bedeutet das, dass deine Anwendungen dynamisch geplant werden, um auf einer Reihe von Servern zu laufen. Das ist ein sehr guter erster Schritt, aber es gibt noch einiges zu tun.

Zeitplannungsprogramm vs. Orchestrator

Die Begriffe "Zeitplannungsprogramm" und "Orchestrator" werden oft synonym verwendet.

In den meisten Fällen ist der Orchestrator für die gesamte Ressourcennutzung in einem Cluster verantwortlich (z. B. Speicherung, Netzwerk und CPU). Der Begriff wird in der Regel für Produkte verwendet, die viele Aufgaben übernehmen, wie z. B. Health Checks und Cloud-Automatisierung.

Zeitplannungsprogramme sind eine Untergruppe von Orchestrierungsplattformen und sind nur dafür zuständig, auszuwählen, welche Prozesse und Dienste auf den einzelnen Servern laufen.

Bei Cloud Native geht es nicht um Microservices oder Infrastruktur als Code. Microservices ermöglichen schnellere Entwicklungszyklen für kleinere, eigenständige Funktionen, aber auch monolithische Anwendungen können die gleichen Funktionen haben, die es ihnen ermöglichen, effektiv von Software verwaltet zu werden, und können ebenfalls von der Cloud Native-Infrastruktur profitieren.

Infrastruktur als Code definiert und automatisiert deine Infrastruktur in einer maschinenlesbaren Sprache oder einer domänenspezifischen Sprache (DSL). Zu den traditionellen Werkzeugen für die Anwendung von Code auf die Infrastruktur gehören Konfigurationsmanagement-Tools (z. B. Chef und Puppet). Diese Tools sind eine große Hilfe bei der Automatisierung von Aufgaben und der Gewährleistung von Konsistenz, aber sie bieten nicht die notwendigen Abstraktionen, um eine Infrastruktur zu beschreiben, die über einen einzelnen Server hinausgeht.

Konfigurationsmanagement-Tools automatisieren jeweils einen Server und sind auf Menschen angewiesen, um die von den Servern bereitgestellten Funktionen miteinander zu verknüpfen. Dadurch wird der Mensch zum potenziellen Engpass für die Skalierung der Infrastruktur. Diese Tools automatisieren auch nicht die zusätzlichen Teile der Cloud-Infrastruktur (z. B. Speicherung und Netzwerk), die für ein vollständiges System erforderlich sind.

Konfigurationsmanagement-Tools bieten zwar einige Abstraktionen für die Ressourcen eines Betriebssystems (z.B. Paketmanager), aber sie abstrahieren nicht genug vom zugrundeliegenden Betriebssystem, um es einfach zu verwalten. Wenn ein Ingenieur jedes Paket und jede Datei auf einem System verwalten wollte, wäre das ein sehr mühsamer Prozess und für jede Konfigurationsvariante einzigartig. Ebenso verbraucht ein Konfigurationsmanagement, das keine oder die falschen Ressourcen definiert, nur Systemressourcen und bietet keinen Nutzen.

Konfigurationsmanagement-Tools können zwar dabei helfen, Teile der Infrastruktur zu automatisieren, aber sie helfen nicht dabei, Anwendungen besser zu verwalten. Wir werden in späteren Kapiteln untersuchen, wie sich die cloud-native Infrastruktur unterscheidet, indem wir uns die Prozesse für die Bereitstellung, die Verwaltung, das Testen und den Betrieb der Infrastruktur ansehen, aber zunächst werden wir uns ansehen, welche Anwendungen erfolgreich sind und wann du die cloud-native Infrastruktur nutzen solltest.

Cloud Native Anwendungen

Genauso wie die Cloud die Beziehung zwischen Unternehmen und Infrastruktur verändert hat, haben cloud-native Anwendungen die Beziehung zwischen Anwendungen und Infrastruktur verändert. Wir müssen sehen, was bei cloud-nativen Anwendungen anders ist als bei traditionellen Anwendungen, damit wir ihre neue Beziehung zur Infrastruktur verstehen können.

Für die Zwecke dieses Buches und um ein gemeinsames Vokabular zu haben, müssen wir definieren, was wir meinen, wenn wir "Cloud Native Application" sagen. Cloud Native ist nicht dasselbe wie eine 12-Faktoren-Anwendung, auch wenn sie einige ähnliche Merkmale aufweisen. Wenn du mehr über die Unterschiede erfahren möchtest, empfehlen wir dir das Buch Beyond the Twelve-Factor App von Kevin Hoffman (O'Reilly, 2012).

Eine Cloud-native Anwendung wird für den Betrieb auf einer Plattform entwickelt und ist auf Resilienz, Agilität, Bedienbarkeit und Beobachtbarkeit ausgelegt.Resilienz nimmt Ausfälle in Kauf, anstatt sie zu verhindern; sie nutzt die dynamische Natur des Betriebs auf einer Plattform.Agilität ermöglicht schnelle Bereitstellungen und schnelle Iterationen.Bedienbarkeit bietet die Kontrolle über die Lebenszyklen der Anwendung innerhalb der Anwendung, anstatt sich auf externe Prozesse und Monitore zu verlassen.Beobachtbarkeit liefert Informationen, um Fragen zum Zustand der Anwendung zu beantworten.

Cloud Native Definition

Die Definition einer Cloud Native Application ist noch in der Entwicklung begriffen. Es gibt weitere Definitionen von Organisationen wie der CNCF.

Cloud-native Anwendungen erhalten diese Eigenschaften durch verschiedene Methoden. Es hängt oft davon ab, wo deine Anwendungen laufen und wie die Prozesse und die Kultur deines Unternehmens sind.⁵ Die folgenden Methoden sind üblich, um die gewünschten Eigenschaften einer cloud-nativen Anwendung zu implementieren:

• Microservices

• Gesundheitsberichterstattung

• Telemetriedaten

• Resilienz

• Deklarativ, nicht reaktiv

Microservices

Anwendungen, die als einzelne Einheiten verwaltet und eingesetzt werden, werden oft als Monolithen bezeichnet. Monolithen haben bei der Entwicklung von Anwendungen viele Vorteile: Sie sind einfacher zu verstehen und ermöglichen es, wichtige Funktionen zu ändern, ohne andere Dienste zu beeinträchtigen.

Mit zunehmender Komplexität der Anwendung nehmen die Vorteile von Monolithen ab: Sie werden schwieriger zu verstehen und verlieren an Agilität, weil es für Ingenieure schwieriger ist, den Code zu verstehen und zu ändern.

Eine der besten Methoden, die Komplexität zu bekämpfen, ist die Aufteilung klar definierter Funktionen in kleinere Dienste und die unabhängige Iteration jedes Dienstes. Dies erhöht die Agilität der Anwendung, da Teile davon bei Bedarf leichter geändert werden können. Jeder Microservice kann von separaten Teams verwaltet, in geeigneten Sprachen geschrieben und bei Bedarf unabhängig skaliert werden.

Solange sich jeder Dienst an feste Verträge hält, kann die Anwendung schnell verbessert und verändert werden,⁶ Es gibt natürlich noch viele andere Überlegungen, die für eine Microservice-Architektur sprechen. Dazu gehört nicht zuletzt die belastbare Kommunikation, die wir in Anhang A behandeln.

Wir können hier nicht auf alle Überlegungen zum Umstieg auf Microservices eingehen. Microservices zu haben, bedeutet nicht, dass du eine Cloud-native Infrastruktur hast. Wenn du mehr darüber lesen möchtest, empfehlen wir dir Sam Newmans Building Microservices (O'Reilly, 2015). Microservices sind zwar eine Möglichkeit, um die Agilität deiner Anwendungen zu erhöhen, aber wie bereits gesagt, sind sie keine Voraussetzung für Cloud-native Anwendungen.

Gesundheitsberichterstattung

Hör auf, Anwendungen zurückzuentwickeln und fang an, sie von innen zu überwachen.

Kelsey Hightower, Monitorama PDX 2016: healthz

Niemand weiß mehr darüber, was eine Anwendung braucht, um gesund zu laufen, als der Entwickler. Lange Zeit haben Infrastrukturadministratoren versucht, herauszufinden, was "gesund" für die Anwendungen bedeutet, für deren Betrieb sie verantwortlich sind. Wenn sie nicht wissen, was eine Anwendung wirklich gesund macht, sind ihre Versuche, Anwendungen zu überwachen und zu melden, wenn sie nicht gesund sind, oft unzureichend und unvollständig.

Um die Funktionsfähigkeit nativer Cloud-Anwendungen zu erhöhen, sollten Anwendungen einen Gesundheitscheck anbieten. Entwickler können dies als Befehl oder Prozesssignal implementieren, auf das die Anwendung nach der Durchführung von Selbsttests reagieren kann, oder, was häufiger der Fall ist, als Web-Endpunkt, der von der Anwendung bereitgestellt wird und den Gesundheitsstatus über einen HTTP-Code zurückgibt.

Google Borg Beispiel

Ein Beispiel für die Gesundheitsberichterstattung findet sich im Borg-Papier von Google:

Fast jeder Task, der unter Borg ausgeführt wird, enthält einen eingebauten HTTP-Server, der Informationen über den Zustand des Tasks und Tausende von Leistungskennzahlen (z. B. RPC-Latenzen) veröffentlicht. Borg überwacht die Health-Check-URL und startet Tasks neu, die nicht umgehend antworten oder einen HTTP-Fehlercode zurückgeben. Andere Daten werden von Überwachungs-Tools für Dashboards und Warnungen bei Verstößen gegen die Service Level Objectives (SLO) verfolgt.

Wenn die Zuständigkeiten für den Zustand der Anwendung in die Anwendung verlagert werden, lässt sich die Anwendung viel einfacher verwalten und automatisieren. Die Anwendung sollte wissen, ob sie ordnungsgemäß läuft und wovon sie abhängig ist (z. B. vom Zugriff auf eine Datenbank), um einen geschäftlichen Nutzen zu erzielen. Das bedeutet, dass die Entwickler mit den Produktmanagern zusammenarbeiten müssen, um zu definieren, welche geschäftliche Funktion die Anwendung erfüllt, und um die Tests entsprechend zu schreiben.

Beispiele für Anwendungen, die Heath-Checks anbieten, sind der Befehl ruok von Zookeeper⁷ und der HTTP /health Endpunkt von etcd.

Anwendungen haben mehr als nur einen gesunden oder ungesunden Zustand. Sie durchlaufen einen Start- und einen Beendigungsprozess, bei dem sie ihren Zustand über den Gesundheitscheck melden sollten. Wenn die Anwendung der Plattform genau mitteilen kann, in welchem Zustand sie sich befindet, ist es für die Plattform einfacher zu wissen, wie sie zu bedienen ist.

Ein gutes Beispiel ist, wenn die Plattform wissen muss, wann die Anwendung bereit ist, Datenverkehr zu empfangen. Während die Anwendung startet, kann sie den Datenverkehr nicht richtig verarbeiten und sollte sich als nicht bereit darstellen. Dieser zusätzliche Status verhindert, dass die Anwendung vorzeitig beendet wird, denn wenn die Gesundheitsprüfungen fehlschlagen, kann die Plattform davon ausgehen, dass die Anwendung nicht gesund ist und sie wiederholt anhalten oder neu starten.

Der Zustand der Anwendung ist nur ein Teil der Möglichkeit, den Lebenszyklus der Anwendung zu automatisieren. Du musst nicht nur wissen, ob die Anwendung gesund ist, sondern auch, ob sie überhaupt arbeitet. Diese Informationen stammen aus der Telemetrie Daten.

Telemetrie-Daten

Telemetriedaten sind die Informationen, die für die Entscheidungsfindung notwendig sind. Es stimmt, dass sich Telemetriedaten in gewisser Weise mit den Zustandsberichten überschneiden können, aber sie dienen unterschiedlichen Zwecken. Die Zustandsberichte informieren uns über den Zustand des Anwendungslebenszyklus, während die Telemetriedaten uns über die Geschäftsziele der Anwendung informieren.

Die Kennzahlen, die du misst, werden manchmal als Service-Level-Indikatoren (SLIs) oder Key Performance Indicators (KPIs) bezeichnet. Dabei handelt es sich um anwendungsspezifische Daten, mit denen du sicherstellen kannst, dass die Leistung der Anwendungen innerhalb eines Service-Level-Ziels (SLO) liegt. Wenn du mehr über diese Begriffe wissen willst und darüber, wie sie sich auf deine Anwendung und deine Geschäftsanforderungen beziehen, empfehlen wir dir, Kapitel 4 aus Site Reliability Engineering (O'Reilly) zu lesen.

Telemetrie und Metriken werden genutzt, um Fragen wie diese zu beantworten:

• Wie viele Anfragen erhält die Anwendung pro Minute?

• Gibt es irgendwelche Fehler?

• Wie hoch ist die Latenzzeit der Anwendung?

• Wie lange dauert es, eine Bestellung aufzugeben?

Die Daten werden oft gescannt oder zur Aggregation in eine Zeitreihendatenbank (z. B. Prometheus oder InfluxDB) übertragen. Die einzige Anforderung an die Telemetriedaten ist, dass sie für das System formatiert sind, das die Daten sammelt.

Es ist wahrscheinlich am besten, zumindest die RED-Methode für Metriken zu implementieren, die Rate, Fehler und Dauer von der Anwendung sammelt.

Bewerten Sie

Wie viele Anfragen erhalten

Fehler

Wie viele Fehler in der Anwendung

Dauer

Wie lange dauert es, eine Antwort zu erhalten

Telemetriedaten sollten eher für Warnmeldungen als für die Zustandsüberwachung verwendet werden. In einer dynamischen, selbstheilenden Umgebung sind wir weniger an den Lebenszyklen einzelner Anwendungsinstanzen interessiert als an den SLOs der gesamten Anwendung. Zustandsberichte sind zwar immer noch wichtig für das automatisierte Anwendungsmanagement, sollten aber nicht dazu verwendet werden, die Techniker auszurufen.

Ob 1 Instanz oder 50 Instanzen einer Anwendung ungesund sind, kann uns egal sein, solange die geschäftlichen Anforderungen an die Anwendung erfüllt werden. Anhand von Metriken erfährst du, ob du deine SLOs erfüllst, wie die Anwendung genutzt wird und was für deine Anwendung "normal" ist. Mit Hilfe von Alarmen kannst du deine Systeme wieder in einen bekannten guten Zustand versetzen.

Wenn es sich bewegt, verfolgen wir es. Manchmal zeichnen wir ein Diagramm von etwas, das sich noch nicht bewegt, nur für den Fall, dass es beschließt, sich zu befreien.

Ian Malpass, Measure Anything, Measure Everything

Alerting sollte auch nicht mit Logging verwechselt werden.Logging dient der Fehlersuche, der Entwicklung und der Beobachtung von Mustern. Es legt die internen Funktionen deiner Anwendung offen. Metriken können manchmal aus Logs berechnet werden (z.B. Fehlerrate), erfordern aber zusätzliche Aggregationsdienste (z.B. ElasticSearch) und Verarbeitung.

Resilienz

Sobald du über Telemetrie- und Überwachungsdaten verfügst, musst du sicherstellen, dass deine Anwendungen ausfallsicher sind. Früher war die Infrastruktur für die Ausfallsicherheit verantwortlich, aber Cloud-native Anwendungen müssen einen Teil dieser Arbeit übernehmen.

Die Infrastruktur wurde so entwickelt, dass sie gegen Ausfälle gewappnet ist. Früher waren mehrere Festplatten, Stromversorgungen und eine Rund-um-die-Uhr-Überwachung sowie der Austausch von Teilen erforderlich, um eine Anwendung verfügbar zu halten. Bei Cloud-nativen Anwendungen liegt es in der Verantwortung der Anwendung, Ausfälle in Kauf zu nehmen, anstatt sie zu vermeiden.

Bei jeder Plattform, insbesondere bei einer Cloud, ist die wichtigste Eigenschaft vor allem ihre Zuverlässigkeit.

David Rensin, Die ARCHITECHT Show: Ein Crashkurs von Google über Technik für die Cloud

Die Entwicklung robuster Anwendungen könnte ein ganzes Buch füllen. Es gibt zwei Hauptaspekte der Resilienz, die wir bei Cloud Native Applications berücksichtigen: Design for Failure und Graceful Degradation.

Design for failure

Die einzigen Systeme, die nie fehlschlagen sollten, sind die, die dich am Leben erhalten (z.B. Herzimplantate und Bremsen). Wenn deine Dienste nie ausfallen, verbringst du zu viel Zeit damit, sie so zu entwickeln, dass sie gegen Ausfälle resistent sind,⁸ verbringst du zu viel Zeit damit, sie so zu entwickeln, dass sie ausfallsicher sind, und nicht genug Zeit, um einen Mehrwert für dein Unternehmen zu schaffen. Dein SLO bestimmt, wie viel Betriebszeit für einen Dienst erforderlich ist. Alle Ressourcen, die du für die Entwicklung einer Betriebszeit aufbringst, die über den SLO hinausgeht, sind verschwendet.

Hinweis

Zwei Werte, die du für jeden Dienst messen solltest, sind die mittlere Zeit zwischen zwei Ausfällen (MTBF) und die mittlere Zeit bis zur Wiederherstellung (MTTR). Mit Hilfe von Überwachung und Metriken kannst du feststellen, ob du deine SLOs erfüllst, aber die Plattform, auf der die Anwendungen laufen, ist der Schlüssel dazu, deine MTBF hoch und deine MTTR niedrig zu halten.

In jedem komplexen System wird es Ausfälle geben. Du kannst einige Ausfälle in der Hardware (z. B. RAID und redundante Stromversorgungen) und einige in der Infrastruktur (z. B. Load Balancer) bewältigen; aber da die Anwendungen wissen, wann sie gesund sind, sollten sie auch versuchen, ihren eigenen Ausfall so gut wie möglich zu bewältigen.

Eine Anwendung, die mit der Erwartung von Fehlern entwickelt wurde, wird defensiver entwickelt als eine, die von Verfügbarkeit ausgeht. Wenn ein Fehler unvermeidlich ist, werden zusätzliche Prüfungen, Fehlermodi und Protokollierungen in die Anwendung eingebaut.

Es ist unmöglich, alle Möglichkeiten, wie eine Anwendung fehlschlagen kann, zu kennen. Bei der Entwicklung von Cloud Native Applications wird davon ausgegangen, dass alles fehlschlagen kann und wahrscheinlich auch wird.

Der beste Zustand für deine Anwendung ist gesund. Der zweitbeste Zustand ist fehlgeschlagen. Charity Majors, CEO von Honeycomb, weist in ihrem Artikel "Ops: It's Everyone's Job Now" darauf hin, dass "verteilte Systeme nie in Betrieb sind; sie befinden sich in einem ständigen Zustand teilweise eingeschränkter Leistung. Akzeptiere Ausfälle, entwickle Resilienz, schütze und verkleinere den kritischen Pfad."

Cloud-native Anwendungen sollten anpassungsfähig sein, egal was für ein Fehler vorliegt. Sie erwarten einen Fehler und passen sich an, wenn er erkannt wird.

Einige Ausfälle können und sollten nicht in die Anwendungen integriert werden (z. B. Netzwerkpartitionen und Ausfälle von Verfügbarkeitszonen). Die Plattform sollte selbstständig mit Ausfällen umgehen, die nicht in die Anwendungen integriert sind.

Anmutige Degradierung

Cloud-native Anwendungen müssen eine Möglichkeit haben, mit übermäßiger Last umzugehen, unabhängig davon, ob die Anwendung selbst oder ein abhängiger Dienst belastet wird. Eine Möglichkeit, mit der Last umzugehen, ist ein Graceful Degradation. Das Buch Site Reliability Engineering beschreibt Graceful Degradation in Anwendungen als das Anbieten von "Antworten, die nicht so genau sind oder weniger Daten enthalten als normale Antworten, die aber leichter zu berechnen sind", wenn sie übermäßig belastet werden.

Einige Aspekte der Entlastung von Anwendungen werden von der Infrastruktur übernommen. Intelligente Lastverteilung und dynamische Skalierung können helfen, aber irgendwann kann deine Anwendung mehr Last haben, als sie bewältigen kann. Cloud-native Anwendungen müssen sich dieser Tatsache bewusst sein und entsprechend reagieren.

Der Sinn von Graceful Degradation ist, dass Anwendungen immer eine Antwort auf eine Anfrage zurückgeben können. Das gilt sowohl für den Fall, dass die Anwendung nicht über genügend lokale Rechenressourcen verfügt, als auch für den Fall, dass abhängige Dienste nicht rechtzeitig Informationen zurückgeben. Dienste, die von einem oder mehreren anderen Diensten abhängig sind, sollten auch dann für die Beantwortung von Anfragen zur Verfügung stehen, wenn abhängige Dienste dies nicht tun. Die Rückgabe von Teilantworten oder Antworten mit alten Informationen aus einem lokalen Cache sind mögliche Lösungen, wenn die Dienste beeinträchtigt sind.

Während Graceful Degradation und Fehlerbehandlung beide in der Anwendung implementiert werden sollten, gibt es mehrere Schichten der Plattform, die dabei helfen sollten. Wenn Microservices eingesetzt werden, wird die Netzwerkinfrastruktur zu einer kritischen Komponente, die eine aktive Rolle bei der Gewährleistung der Ausfallsicherheit der Anwendung übernehmen muss. Weitere Informationen zum Aufbau einer belastbaren Netzwerkschicht findest du unter in Anhang A.

Verfügbarkeit Mathe

Cloud-native Anwendungen brauchen eine Plattform, die auf der Infrastruktur aufbaut, um diese widerstandsfähiger zu machen. Wenn du deine bestehenden Anwendungen in die Cloud verlagern willst, solltest du die Service-Level-Agreements (SLAs) des Cloud-Providers prüfen und überlegen, was passiert, wenn du mehrere Dienste nutzt.

Nehmen wir eine hypothetische Cloud, in der wir unsere Anwendungen betreiben.

Die typische Verfügbarkeit für Recheninfrastrukturen liegt bei 99,95 % pro Monat. Das bedeutet, dass deine Instanz jeden Tag für 43,2 Sekunden ausfallen könnte und trotzdem die SLA des Cloud-Providers mit dir erfüllt.

Außerdem hat die lokale Speicherung für die Instanz (z. B. ein EBS-Volume) eine Verfügbarkeit von 99,95 %. Wenn du Glück hast, fallen beide gleichzeitig aus, aber im schlimmsten Fall können sie zu unterschiedlichen Zeiten ausfallen, sodass deine Instanz nur noch zu 99,9 % verfügbar ist.

Wahrscheinlich braucht deine Anwendung auch eine Datenbank. Anstatt sie selbst zu installieren und eine mögliche Ausfallzeit von 1 Minute und 26 Sekunden (99,9 % Verfügbarkeit) zu berechnen, entscheidest du dich für die zuverlässigere gehostete Datenbank mit einer Verfügbarkeit von 99,95 %. Das bringt die Zuverlässigkeit deiner Anwendung auf 99,85 % oder eine mögliche tägliche Ausfallzeit von 2 Minuten und 9 Sekunden.

Wenn du die Verfügbarkeiten miteinander multiplizierst, verstehst du schnell, warum die Cloud anders behandelt werden sollte. Der wirklich schlimme Teil ist, dass der Cloud-Provider einen Prozentsatz deiner Rechnung in Form von Guthaben für seine Plattform zurückerstattet, wenn er sein SLA nicht erfüllt.

Es ist zwar schön, dass du nicht für ihre Ausfälle bezahlen musst, aber wir kennen kein einziges Unternehmen auf der Welt, das von Cloud Credits lebt. Wenn die Verfügbarkeit deiner Anwendung nicht mehr wert ist als die Gutschriften, die du bei einem Ausfall erhalten würdest, solltest du wirklich überlegen, ob du die Anwendung überhaupt betreiben solltest.

Deklarativ, nicht reaktiv

Da Cloud-native Anwendungen für die Ausführung in einer Cloud-Umgebung konzipiert sind, interagieren sie mit der Infrastruktur und den unterstützenden Anwendungen anders als herkömmliche Anwendungen. Bei einer Cloud-nativen Anwendung erfolgt die Kommunikation mit allem über das Netzwerk. Häufig erfolgt die Netzwerkkommunikation über RESTful HTTP-Aufrufe, sie kann aber auch über andere Schnittstellen wie Remote Procedure Calls (RPC) implementiert werden.

Herkömmliche Anwendungen automatisierten Aufgaben über Nachrichtenwarteschlangen, Dateien auf einer gemeinsamen Speicherung oder lokale Skripte, die Shell-Befehle auslösten. Die Kommunikationsmethode reagierte auf ein Ereignis (z. B. wenn der Benutzer auf "Submit" klickt, wird das Submit-Skript ausgeführt) und benötigte oft Informationen, die auf demselben physischen oder virtuellen Server vorhanden waren.

Serverlos

Serverlose Plattformen sind Cloud-nativ und reagieren von vornherein auf Ereignisse. Sie funktionieren deshalb so gut in der Cloud, weil sie über HTTP-APIs kommunizieren, Einzweckfunktionen sind und deklarativ sind, was sie aufrufen. Die Plattform hilft auch, indem sie sie skalierbar und von der Cloud aus zugänglich macht.

Reaktive Kommunikation in traditionellen Anwendungen ist oft ein Versuch, Ausfallsicherheit zu schaffen. Wenn die Anwendung eine Datei auf die Festplatte oder in eine Nachrichtenwarteschlange schreibt und dann stirbt, kann das Ergebnis der Nachricht oder Datei immer noch fertiggestellt werden.

Das soll nicht heißen, dass Technologien wie Message Queues nicht verwendet werden sollten, sondern dass man sich nicht auf sie als einzige Ausfallsicherheitsschicht in einem dynamischen und ständig fehlschlagenden System verlassen kann. Grundsätzlich sollte sich die Kommunikation zwischen den Anwendungen in einer nativen Cloud-Umgebung ändern - nicht nur, weil es andere Methoden gibt, um Kommunikationsausfallsicherheit aufzubauen (siehe Anhang A), sondern auch, weil es oft mehr Arbeit ist, traditionelle Kommunikationsmethoden in der Cloud zu replizieren.

Wenn Anwendungen auf die Ausfallsicherheit der Kommunikation vertrauen können, sollten sie aufhören zu reagieren und anfangen zu deklarieren. Bei der deklarativen Kommunikation wird darauf vertraut, dass das Netzwerk die Nachricht zustellen wird. Sie verlässt sich auch darauf, dass die Anwendung einen Erfolg oder einen Fehler zurückgibt. Das soll nicht heißen, dass es nicht wichtig ist, dass Anwendungen auf Veränderungen achten. Die Kubernetes-Controller tun genau das mit dem API-Server. Sobald jedoch eine Veränderung festgestellt wird, deklarieren sie einen neuen Zustand und vertrauen darauf, dass der API-Server und die Kubelets das Notwendige tun.

Das deklarative Kommunikationsmodell erweist sich aus vielen Gründen als robuster. Am wichtigsten ist, dass es ein Kommunikationsmodell standardisiert und die funktionale Implementierung, wie etwas in einen gewünschten Zustand gelangt, von der Anwendung zu einem entfernten API- oder Service-Endpunkt verlagert. Dies trägt zur Vereinfachung der Anwendungen bei und ermöglicht ein vorhersehbareres Verhalten der Anwendungen untereinander .

Wie wirken sich Cloud Native Anwendungen auf die Infrastruktur aus?

Du kannst hoffentlich erkennen, dass Cloud Native Applications anders sind als herkömmliche Anwendungen. Cloud Native Applications profitieren nicht davon, direkt auf IaaS zu laufen oder eng an das Betriebssystem eines Servers gekoppelt zu sein. Sie erwarten, dass sie in einer dynamischen Umgebung mit meist autonomen Systemen laufen.

Die Cloud-Native-Infrastruktur schafft eine Plattform auf IaaS, die ein autonomes Anwendungsmanagement ermöglicht. Die Plattform baut auf einer dynamisch erstellten Infrastruktur auf, um einzelne Server zu abstrahieren und eine dynamische Planung der Ressourcenzuweisung zu fördern.

Hinweis

Automatisierung ist nicht dasselbe wie Autonomie. Automatisierung ermöglicht es Menschen, einen größeren Einfluss auf ihre Handlungen zu haben.

Bei Cloud Native handelt es sich um autonome Systeme, die keine menschlichen Entscheidungen erfordern. Es wird zwar immer noch automatisiert, aber erst nach der Entscheidung über die erforderliche Aktion. Nur wenn das System nicht automatisch das Richtige tun kann, sollte es einen Menschen benachrichtigen.

Anwendungen mit diesen Merkmalen brauchen eine Plattform, die pragmatisch überwachen, Metriken sammeln und dann reagieren kann, wenn Fehler auftreten. Cloud-native Anwendungen verlassen sich nicht darauf, dass Menschen Ping-Prüfungen einrichten oder Syslog-Regeln erstellen. Sie benötigen Self-Service-Ressourcen, die von der Auswahl eines Basis-Betriebssystems oder Paketmanagers abstrahiert sind, und sie verlassen sich auf Service Discovery und robuste Netzwerkkommunikation, um ein funktionsreiches Erlebnis zu bieten.

Fazit

Die Infrastruktur, die für den Betrieb von Cloud-nativen Anwendungen erforderlich ist, unterscheidet sich von der herkömmlicher Anwendungen. Viele Aufgaben, die früher von der Infrastruktur übernommen wurden, sind jetzt von den Anwendungen übernommen worden.

Cloud-native Anwendungen vereinfachen die Komplexität ihres Codes, indem sie in kleinere Dienste zerlegt werden. Diese Dienste bieten Überwachung, Metriken und Ausfallsicherheit direkt in der Anwendung. Es werden neue Tools benötigt, um die Verwaltung der Dienstvermehrung und das Lebenszyklusmanagement zu automatisieren.

Die Infrastruktur ist nun für das ganzheitliche Ressourcenmanagement, die dynamische Orchestrierung, die Erkennung von Diensten und vieles mehr verantwortlich. Sie muss eine Plattform bereitstellen, bei der die Dienste nicht auf einzelne Komponenten, sondern auf APIs und autonome Systeme angewiesen sind.In Kapitel 2 werden die Funktionen der nativen Cloud-Infrastruktur näher erläutert.

¹ Einige dieser Dinge können als eigenständige Anwendungen betrachtet werden; in diesem Buch betrachten wir Anwendungen als die Software, die Einnahmen generiert, um ein Unternehmen zu erhalten.

² Hypervisoren des Typs 1 laufen auf Hardware-Servern mit dem alleinigen Zweck, virtuelle Maschinen auszuführen.

³ Auch "Infrastruktur als Code" genannt.

⁴ Wird "Heben und Schieben" genannt.

⁵ Der Betrieb einer Anwendung in einer Cloud ist unabhängig davon, ob diese Cloud von einem öffentlichen Anbieter gehostet oder vor Ort betrieben wird.

⁶ Die Versionierung von APIs ist ein wichtiger Aspekt bei der Pflege von Serviceverträgen. Siehe https://cloud.google.com/appengine/docs/standard/go/designing-microservice-api für weitere Informationen.

⁷ Nur weil eine Anwendung einen Gesundheitscheck anbietet, heißt das nicht, dass die Anwendung gesund ist. Ein Beispiel dafür ist der Befehl ruok von Zookeeper, mit dem der Zustand des Clusters überprüft wird. Die Anwendung gibt zwar imok zurück, wenn der Health-Befehl ausgeführt werden kann, führt aber über die Beantwortung der Anfrage hinaus keine weiteren Tests für den Zustand der Anwendung durch.

⁸ Wie bei einem Service-Ausfall, nicht bei einem Komponenten- oder Instanzausfall.